The W3C has links to http://www.w3.org/DOM/faq as opposed to http://www.w3.org/DOM/faq.html. They also have other resources there: http://www.w3.org/DOM/faq.xml and http://www.w3.org/DOM/faq.xsl. Apparently, they also have mod_negotiation enabled. As a result, they serve the XSLT transformation sheet when Mozilla requests http://www.w3.org/DOM/faq The right thing to do would be serving the HTML file (accomplished by setting the source quality of the other files to zero or by moving/renaming them). It doesn't make sense to serve the transformation file, because the transformation is not an alternate version of the document. It does not make sense to serve the source XML file, because it uses a private vocabulary and, therefore, can not be rendered in a useful way by a user agent that does not have a priori knowledge about that vocabulary. Mozilla prefers the XML content types over text/html (in the HTTP Accept header), but only in order to receive documents marked up using vocabularies that an user agent can be can be expected to have a priori knowledge about (eg. XHTML and MathML).
Whilst serving up the xsl file is clearly wrong by the w3 (has anyone told the www-dom folks?) this is also a mozilla error, accepting text/xml or application/xml over text/html or application/xhtml+xml is clearly flawed, the first two general xml versions have no reason to be understandable by humanss. Mozilla signifies it's preference for XHTML via the correct mime-type, application/xml is not correct for specifying the preference for xhtml. The only problem is with standalone MathML which doesn't have a mime-type, and it's probably reasonable to want this over a html version, I don't yet believe that is a common enough scenario, and is really caused by the W3 not having registered a mime-type. This is also a Mozilla bug IMO, not just tech-evangelism.
I got the following mail from Philippe. Copying it here for others to see. --------------------- Subject: Bug 153685 Content negotiation sends Mozilla an XSLTtransformation instead of document Date: Wed, 24 Jul 2002 8:31 EST From: Philippe Le Hegaret <firstname.lastname@example.org> To:email@example.com Cc:firstname.lastname@example.org, email@example.com [[ The W3C has links to http://www.w3.org/DOM/faq as opposed to http://www.w3.org/DOM/faq.html. They also have other resources there: http://www.w3.org/DOM/faq.xml and http://www.w3.org/DOM/faq.xsl. Apparently, they also have mod_negotiation enabled. ]] Yes, we are using the mod_negociation. I don't understand why we are making a difference between text/xml and application/xml though. [[ Whilst serving up the xsl file is clearly wrong by the w3 (has anyone told the www-dom folks?) ]] Obviously, someone did :) I moved away the file since it is not even used by faq.xml. Philippe -- Philippe Le Hegaret - http://www.w3.org/People/LeHegaret/ World Wide Web Consortium (W3C), DOM Activity Lead
CCing Gerv (The Official Guardian of the Accept Header) and Hixie. There are two view points here: 1) Mozilla shouldn't Accept text/xml or application/xml (or at least shouldn't prefer them), because content served with those content types might use markup with no agreed-upon and known semantincs. OR 2) Mozilla should continue to prefer all the XML content types, since adding a new MIME type for each new agreed-upon application of XML isn't as feasible as serving as application/xml and detecting namespaces. Servers shouldn't serve content whose markup doesn't have widely known and agreed-upon semantics as a result of content negotiation. Opinions? (Clearly, preferring application/xhtml+xml isn't an issue here. Mozilla should continue to prefer it now that forms work again, since preferring it is required for dealing with IE's inability to do the Right Thing with XHTML + MathML without resorting to UA sniffing nor to XSLT.) For the record, the only major site that has shown problems with Accepting text/xml is www.w3.org. The only other know case has been some relatively unknown Danish golf site.
I'd plump for option 2, based on what I read so far in this bug. Adding xml MIME types individually to Accept: just won't fly. Gerv
I don't understand this "adding of mime types" issue that's a concern, what xml formats are there mozilla understands the semantics of, which do not have a mime-type I believe it's only MathML, so the issue is purely MathML. If in the future the W3 (or anyone else) develops a XML vocabulary with "widely known and agreed-upon semantics as a result of content negotiation." then the server would be fully justified in serving it up, however Mozilla wouldn't have a clue what to do with it. You're fixing the accept headers for "agreed and known semantics" at the point of mozilla being shipped, the lifetime of a mozilla browser can be 10 years, whole new formats may arise in that time where text/html is the only one mozilla 1.1 has a hope of rendering. Equally a server has to respect the accept headers of the client, if the client says they prefer text/xml over text/html, the server should give it, if contains the same semantic information there's no reason not to believe a client requesting knows what to do with it. Mozilla is not in a position to dictate what servers choose to send in a content-negotiated sitauation. Almost certainly the reason we don't have content negotiation of text/xml formats is because server users of content negotiation are clueful enough that text/xml is such a catch all as to be useless. Just like giving a preference for application/octetstream is silly, text/xml covers too much with unknown semantics. I'd vote for default to text/html with higher q value, but make the user aware of the contents of the vary header so they know of alternate representations, (and can access them obviously).
> so the issue is purely MathML. MathML, SVG, XSLT, XUL... Gerv
>> so the issue is purely MathML. > >MathML, SVG, XSLT, XUL... Is SVG on trunk? in any case image/svg+xml may not be registered, but it's what SVG is being delivered as, - What exactly is mozilla going to do with "XSLT" when there's an HTML version available - and as for XUL, if that doesn't have a mime-type give it one!
> Is SVG on trunk? Hopefully it will be soon. > in any case image/svg+xml may not be registered, but it's what > SVG is being delivered as, - What exactly is mozilla going to do with "XSLT" > when there's an HTML version available I mean, there is an argument that the Accept: header should specify that we support client-side XSLT style sheets (in the same way we currently Accept text/css). > - and as for XUL, if that doesn't have a > mime-type give it one! The MIME type for XUL is application/vnd.mozilla.xul+xml . My point is that we can't put the specific MIME types for all the XML types we understand in the Accept: header, because that would make it too long. Gerv
There's a huge can of worms here. Basically, MIME isn't good enough to cope with mixed namespace content and we don't want to baloon our Accept headers, so we're using text/xml as a catch-all for XML content. I can see an argument for making application/xhtml+xml have a higher q level than text/xml, but doing that simply starts us down the path of listing all our supported MIME types and that leads to madness. (Not to mention that there's no way to say that XHTML+MathML is better than XHTML on its own.) Basically, though, if the server has text/xml content which it knows is of a much lower quality level than the HTML alternative, then it should serve that to us, since we only say that text/html is q=0.9 compared to text/xml's q=1. I think what we are doing is fine.
Note that Henri's comments at the top of this bug ("The right thing...") exactly represent my views as well.
http://www.w3.org/DOM/faq is now fixed, it sends http://www.w3.org/DOM/faq.xml which is XML styled with CSS.