Re: [XMLHttpRequest] update from the editor
On Wed, 09 May 2007 00:49:56 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne: was there a reason 'text/xsl' was included other than IE does it? Or is it known to actually break sites? A Contributor from WebKit implementing XMLHttpRequest requested it to be included for compatibility with their implementation. I didn't see any harm in adding it. Internet Explorer does not appear to recognize this MIME type by the way and Opera currently doesn't check MIME types at all (oops!). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XMLHttpRequest] update from the editor
On Thu, 10 May 2007 17:21:30 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: * Anne van Kesteren wrote: If one UA treats Content-Type:text/foobar as XML and another UA does not and a site starts relying on text/foobar being treated as XML we have a problem. We have very many problems of this nature right now. If I use XML 1.1 my site won't work in Firefox, if I use CP850 as character encoding it will not work in Opera, if I use Transfer-Encoding:gzip it will not work in Internet Explorer, if I use XMLHttpRequest.responseBody it will not work (I guess) in Safari. All these are reasonable features to implement and use, and the draft does not prohibit them in any way. The draft clearly indicates that extensions should be discussed on public-webapi. So we are quite used to accept this risk. There is also a risk that by making the specification difficult to understand and prohibiting reasonable implementation decisions, that some browser vendors simply choose to ignore it. So I am afraid simply the remote possibility of a problem is not a good enough reason. I would hope that implementors channel such feedback to us. I don't believe the specification is difficult to understand, however. I was unable, by the way, to get any browser but Opera to recognize the type text/xsl as XML MIME type; Firefox from 1.5 to Minefield does not seem to recognize it, and neither do IE6 and IE7 (on different versions of Windows, and even a Linux box for Firefox); my test case works in all these browsers if I simply use application/xml instead. Could you give an example of a web page that works in IE and Firefox, yet depends on them recognizing text/xsl as XML MIME type for XHR purposes? It was added for compatibility with WebKit. I don't really feel strongly about it, but I don't see any harm in having it as a requirement for user agents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XMLHttpRequest] update from the editor
On May 14, 2007, at 9:26 AM, Bjoern Hoehrmann wrote: * Anne van Kesteren wrote: It was added for compatibility with WebKit. I don't really feel strongly about it, ... Excellent, I then look forward to a proposal that Jonas and I do not regard as inappropriate. I don't personally feel strongly about this particular issue (I don't think it is common for sites to send text/xsl as a MIME type on the wire), but since when is the fact that someone regard[s] [it] as inappropriate a valid reason to change something? Shouldn't reasoning be based on valid technical arguments, not feelings? Personally I don't think lack of registration is a particularly strong reason not to define handling for a particular MIME type. The question we should be examining is whether the MIME type is actually used in practice. If it is, then the right course of action is to get it registered with the IETF (and presumably marked deprecated). If it isn't, then we can safely require it not to be treated as XML. I personally don't have the means to do research on this MIME type but I am hoping someone on this list does. Regards, Maciej
Re: [XMLHttpRequest] update from the editor
On 5/14/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Personally I don't think lack of registration is a particularly strong reason not to define handling for a particular MIME type. At the very least, the W3C/IETF liasons should discuss this. It is exceedingly bad manners to squat a on parts of a shared namespace, such as MIME types or HTML tag names, in the first place. The W3C should not reward that behavior by standardizing unregistered types. I have to wonder why the type was suggested if no one has any usage data. If people are using it, this particular type is water under the bridge, so I personally feel that the IETF should register and document it. The registration procedures are a lot easier now. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [XMLHttpRequest] update from the editor
On 5/14/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Defining particular behavior when a type is seen is not the same as standardizing it, in my opinion. Disagree, since MIME types are used to route messages to code with particular behaviors. However, I personally don't feel too strongly about this issue. -- Robert Sayre
Re: [XMLHttpRequest] update from the editor
* Maciej Stachowiak wrote: I don't personally feel strongly about this particular issue (I don't think it is common for sites to send text/xsl as a MIME type on the wire), but since when is the fact that someone regard[s] [it] as inappropriate a valid reason to change something? Shouldn't reasoning be based on valid technical arguments, not feelings? This discussion is not about changing something, but about not changing something. The published draft does not mention `text/xsl`, Anne is pro- posing to mention it. I certainly agree valid technical arguments should be brought on the table to support the proposal. I certainly don't agree the technical arguments presented should be dismissed as emotional. I do not agree that XMLHttpRequest implementations should be considered non-conforming if they do not support an internet media type that should not be used on the Web, is undefined, unregistered, unimplemented in the major XHR implementations, and unused where cross-browser compatibility is a concern. I welcome technical arguments to the contrary. To support the requirement, it has been argued vendors want that. Jonas represents a vendor and he does not want it. Then the argument was this is necessary to be reasonably compatible with existing content. It turns out it is not necessary to achieve a reasonable level of compatibility. Then the argument was the sky will fall if browsers aren't all equal. It turns out we allow browsers to wary in very many and more severe ways. The latest argument seems to be, the requirement should be included be- cause doing so does not cause harm. It is clear that this is false in the general case; to give a simple example, the SVG specification man- dated support for `text/ecmascript` and no other types. This lead to a situation where some impplementations only support `text/ecmascript` and competing implementers refused to support the type because it's not been registered, making standards compliance and cross browser compatibility at the same time impossible. Mozilla was such an refusing implementer. Additional technical problems in that case came from the fact that there was no specification dealing with issues such as character encoding han- dling, making use of non-ASCII characters rather difficult. Problems of this nature can easily be avoided by not encouraging use of unregistered types. However, we should not even accept does not cause harm as a valid argument to introduce new requirements: if a requirement is not needed in the first place, it should not be added, regardless of whether it causes harm, or any other consideration for that matter. http://lists.w3.org/Archives/Public/public-webapi/2006Apr/thread#msg450 I've been saying all along the draft should say, if you understand the Content-Type to indicate an XML document, treat it as an XML document. For some reason the draft instead says treat app|text/xml and */*+xml as XML, and do not treat any other as XML. While that's certainly not great for reasons I have pointed out, I can live with that text for now. I do not expect that browsers will actually adhere to the requirement in the longer term, so we will change it sooner or later to what I suggested. There is however no reason to accept Anne's proposal. If Apple and Opera say they support `text/xsl` right now and don't want to change that, and don't want to have a non-conforming implementation, then there are many ways to achieve that without putting `text/xsl` into the draft. I have proposed several. I would most certainly appreciate reasoned debate of the issues, rather than wild assertions about Breaking Teh Intarwebz and about reasoning based on feelings. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XMLHttpRequest] update from the editor
On Mon, 14 May 2007, Maciej Stachowiak wrote: The question we should be examining is whether [text/xsl] is actually used in practice. If it is, then the right course of action is to get it registered with the IETF (and presumably marked deprecated). If it isn't, then we can safely require it not to be treated as XML. My research (which is biased against non-HTML files) suggests that text/xsl is seen about as often as the following types: application/x-zaurus-xls application/x-php application/vnd.adobe.xfdf application/x-autocad text/xsl application/octet-stream-dummy application/x-java-archive application/text text/texmacs model/iges application/x-dvi I think the bias against text/xsl is high. The type application/xslt+xml was present in my sample about 2.8 times more than text/xsl, and application/xslfo+xml was present about 1.5 times more. The type text/x-xslt was present about 0.1 times as much as text/xsl. I expect the data to be biased against application/xslt+xml and text/x-xslt about equally. However, I expect it to be biased quite strongly in favour of application/xslfo+xml (relatively speaking). The MIME type application/xsl+xml appeared about 0.2 times as much as text/xsl, but I don't know what the bias in favour or against that type would be. However, this data is for all intents and purposes worthless. All of the types mentioned in this study were seen so rarely (in the order of 0.04% of the multibillion document sample) that the numbers are probably swamped by the error margin. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XMLHttpRequest] update from the editor
Maciej Stachowiak wrote: On May 14, 2007, at 9:26 AM, Bjoern Hoehrmann wrote: * Anne van Kesteren wrote: It was added for compatibility with WebKit. I don't really feel strongly about it, ... Excellent, I then look forward to a proposal that Jonas and I do not regard as inappropriate. I don't personally feel strongly about this particular issue (I don't think it is common for sites to send text/xsl as a MIME type on the wire), but since when is the fact that someone regard[s] [it] as inappropriate a valid reason to change something? Shouldn't reasoning be based on valid technical arguments, not feelings? Being non-standard, unsupported by a large majority of browser installs, undefined what it means (since it's not registered) and doesn't add much value seems like valid technical arguments against including it. Do you have any valid techincal arguments for including it? / Jonas
Re: [XMLHttpRequest] update from the editor
Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating axmlb/test as XML type, which my versions of Firefox do; so it
does seeem true to me. `text/rdf` btw, does not seem to be supported as
XML type for XHR purposes in Firefox.
That's correct. The relevant firefox code is basically:
1342 if (type.Find(xml) == kNotFound) {
1343 mState = ~XML_HTTP_REQUEST_PARSEBODY;
1344 }
Wow, we suck.
/ Jonas
Re: [XMLHttpRequest] update from the editor
* Anne van Kesteren wrote: If one UA treats Content-Type:text/foobar as XML and another UA does not and a site starts relying on text/foobar being treated as XML we have a problem. We have very many problems of this nature right now. If I use XML 1.1 my site won't work in Firefox, if I use CP850 as character encoding it will not work in Opera, if I use Transfer-Encoding:gzip it will not work in Internet Explorer, if I use XMLHttpRequest.responseBody it will not work (I guess) in Safari. All these are reasonable features to implement and use, and the draft does not prohibit them in any way. So we are quite used to accept this risk. There is also a risk that by making the specification difficult to understand and prohibiting reasonable implementation decisions, that some browser vendors simply choose to ignore it. So I am afraid simply the remote possibility of a problem is not a good enough reason. I was unable, by the way, to get any browser but Opera to recognize the type text/xsl as XML MIME type; Firefox from 1.5 to Minefield does not seem to recognize it, and neither do IE6 and IE7 (on different versions of Windows, and even a Linux box for Firefox); my test case works in all these browsers if I simply use application/xml instead. Could you give an example of a web page that works in IE and Firefox, yet depends on them recognizing text/xsl as XML MIME type for XHR purposes? -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XMLHttpRequest] update from the editor
On Thursday, May 10, 2007, 2:07:48 PM, Anne wrote: AvK On Wed, 09 May 2007 07:18:32 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] AvK wrote: The reason is that the draft needs to be reasonably compatible with existing content such that it can be implemented without breaking content. If you think my suggestion would break existing content, it would be more useful if you could actually explain your reasoning to me. It is clear to me that Content-Type:text/xsl indicates the message body is an XML document, I do not understand why adopting the text I proposed would break any content. Its clear that text/xsl indicates XML content, *if* the application has a complete list of registered media types where it can look up this information. If XSL were to register, say, application/xsl+xml that would make it immediately much clearer without having to have a registry in every application. AvK If one UA treats Content-Type:text/foobar as XML and another UA does not AvK and a site starts relying on text/foobar being treated as XML we have a AvK problem. Yes. -- Chris Lilleymailto:[EMAIL PROTECTED] Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Re: [XMLHttpRequest] update from the editor
On Wednesday, May 9, 2007, 7:05:30 AM, Björn wrote: BH * Maciej Stachowiak wrote: I'm also not sure of the benefit of letting the UA treat arbitrary other types as XML besides those listed. Modern XML MIME types should all be following the +xml convention. BH It is false to assert modern XML MIME types follow the +xml convention. BH The most recent type proposal, application/vnd.fcsexpress.launchfile, BH does not, the reason being that the format uses XML now, but might not BH do so in the future. An ISO standard case whether going either way is BH sensible is application/fastinfoset, which certainly is a modern type. Björn, your conclusion does not follow from your evidence. If you see foo/bar+xml, the +xml convention licenses you to assert that this is definitely XML. If you see foo/bar, the +xml convention does not license you to conclude that it is *not* XML. The media types that you mention, which are sometimes xml and sometimes not, are thus correctly labelled. -- Chris Lilleymailto:[EMAIL PROTECTED] Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Re: [XMLHttpRequest] update from the editor
Hi! * Bjoern Hoehrmann [EMAIL PROTECTED] [Thu, 10 May 2007 17:21:30 +0200]: I was unable, by the way, to get any browser but Opera to recognize the type text/xsl as XML MIME type; Firefox from 1.5 to Minefield does not seem to recognize it, and neither do IE6 and IE7 (on different versions of Windows, and even a Linux box for Firefox); my test case works in all these browsers if I simply use application/xml instead. Here are results of my tests: 1) IE 7 seems to only recognize text/xml and application/xml. 2) Firefox 2 recognizes anything with xml in it (e.g. fooxml/bar). 3) WebKit recognizes proper XML MIME types, plus text/xsl. 4) Opera tries to parse the response as XML regardless of MIME type. Could you give an example of a web page that works in IE and Firefox, yet depends on them recognizing text/xsl as XML MIME type for XHR purposes? I think that code depending on text/xsl is most likely to be found among Dashboard widgets. - WBR, Alexey Proskuryakov.
Re: [XMLHttpRequest] update from the editor
Alexey Proskuryakov wrote: 2) Firefox 2 recognizes anything with xml in it (e.g. fooxml/bar). I really doubt that is the case. Could you provide a testcase showing this to be true? / Jonas
Re: [XMLHttpRequest] update from the editor
Bjoern Hoehrmann wrote:
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating axmlb/test as XML type, which my versions of Firefox do; so it
does seeem true to me. `text/rdf` btw, does not seem to be supported as
XML type for XHR purposes in Firefox.
That's correct. The relevant firefox code is basically:
1342 if (type.Find(xml) == kNotFound) {
1343 mState = ~XML_HTTP_REQUEST_PARSEBODY;
1344 }
-Boris
Re: [XMLHttpRequest] update from the editor
* Anne van Kesteren wrote: * For compatibility reasons the character encoding detection for decoding responseText has been changed. I find some of these changes somewhat odd. For example, if there is no Content-Type header, the encoding is detected as if the resource was a application/xml resource, but .responseXML is populated as if the re- source was non-XML (it's set to null). It would be more consistent and easier to understand if it just said, if there's no Content-Type header, assume application/xml. * text/xsl has been added as a MIME type that causes responseXML to return a Document object (if the resource can indeed be parsed according to the XML specfications.) Again, for compatibility reasons. There is no need for the draft to encourage use of unregistered media types, and there is very little need for the draft to apply non-XML treatment to media types like application/smil which are defined for use with XML documents. I believe it is entirely sufficient and more appropriate to state, for example, If the internet media type in the Content-Type header indicates the entity body is an XML document, * Most members are now defined as algorithms which makes the result of a method more clear (hopefully) and also helped me fixing several issues. Why is it necessary to make implementations non-compliant if they e.g. check for same origin restrictions before checking whether some pass- word uses proper syntax? It seems by the way the draft does not say what happens if the implementation does not support a particular scheme (say you attempt to open a 'mailto' URL, or there is no TLS support.) I don't understand why the send() implementation must dispatch a readystatechange event *after* it raised an exception. The only way to tell the difference would be an exception handler that checks that the event listener had not been invokved. The (Don't abort these steps.) note suggests this is deliberate, but if this is truly necessary, the draft needs to say why. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XMLHttpRequest] update from the editor
* Anne van Kesteren wrote: I find some of these changes somewhat odd. For example, if there is no Content-Type header, the encoding is detected as if the resource was a application/xml resource, but .responseXML is populated as if the re- source was non-XML (it's set to null). It would be more consistent and easier to understand if it just said, if there's no Content-Type header, assume application/xml. Fixed. It would be helpful if you could say what changes you have made, rather than relying on reviewers to somehow figure this out for themselves. I take it you did not use my suggestion, but I can live with the result. Vendors have indicated they would like to have defined what that would mean, which is what the draft now tries to say. This indeed excludes (now obsolete?) MIME types such as application/smil but I don't think that will cause a problem in practice. If it does, I suppose we should get implementation feedback during CR. I don't think it matters what vendors have indicated they would like. If there are technical reasons that necessitate citing unregistered media types in the draft, I would like to hear them. At the moment I cannot agree with keeping unregistered types in the draft. I could agree with not treating certain XML media types as XML media type, but this surprising fact needs to be noted in the document. That's not non-compliant. Then I must have misread the document. Could you elaborate on how to arrive at your conclusion, so I can make a suggestion for changes that would prevent my misunderstanding? To give a better example, why is an implementation prohibited to execute open() step #10 before step #1, or where does the draft says it is allowed to do that? It seems by the way the draft does not say what happens if the implementation does not support a particular scheme (say you attempt to open a 'mailto' URL, or there is no TLS support.) What would you suggest? NOT_SUPPORTED_ERR comes to mind but I'm not sure if that's appropriate... A NOT_SUPPORTED_ERR DOMException would certainly be appropriate. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XMLHttpRequest] update from the editor
On Tue, 08 May 2007 12:58:12 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: Fixed. It would be helpful if you could say what changes you have made, rather than relying on reviewers to somehow figure this out for themselves. I take it you did not use my suggestion, but I can live with the result. I did take your suggestion. Not having Content-Type specified now gives you responseXML as well. I assumed you would read the diffs you receive through e-mail. From now on I'll try to be more elaborate. Vendors have indicated they would like to have defined what that would mean, which is what the draft now tries to say. This indeed excludes (now obsolete?) MIME types such as application/smil but I don't think that will cause a problem in practice. If it does, I suppose we should get implementation feedback during CR. I don't think it matters what vendors have indicated they would like. If there are technical reasons that necessitate citing unregistered media types in the draft, I would like to hear them. At the moment I cannot agree with keeping unregistered types in the draft. I could agree with not treating certain XML media types as XML media type, but this surprising fact needs to be noted in the document. The reason is that the draft needs to be reasonably compatible with existing content such that it can be implemented without breaking content. That's not non-compliant. Then I must have misread the document. Could you elaborate on how to arrive at your conclusion, so I can make a suggestion for changes that would prevent my misunderstanding? To give a better example, why is an implementation prohibited to execute open() step #10 before step #1, or where does the draft says it is allowed to do that? The user agent conformance class clearly says as long as the algorithm used produces the same result it doesn't matter how they do it. It seems by the way the draft does not say what happens if the implementation does not support a particular scheme (say you attempt to open a 'mailto' URL, or there is no TLS support.) What would you suggest? NOT_SUPPORTED_ERR comes to mind but I'm not sure if that's appropriate... A NOT_SUPPORTED_ERR DOMException would certainly be appropriate. Ok, this is now part of the open() algorithm. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XMLHttpRequest] update from the editor
Anne van Kesteren wrote: * text/xsl has been added as a MIME type that causes responseXML to return a Document object (if the resource can indeed be parsed according to the XML specfications.) Again, for compatibility reasons. There is no need for the draft to encourage use of unregistered media types, and there is very little need for the draft to apply non-XML treatment to media types like application/smil which are defined for use with XML documents. I believe it is entirely sufficient and more appropriate to state, for example, If the internet media type in the Content-Type header indicates the entity body is an XML document, Vendors have indicated they would like to have defined what that would mean, which is what the draft now tries to say. This indeed excludes (now obsolete?) MIME types such as application/smil but I don't think that will cause a problem in practice. If it does, I suppose we should get implementation feedback during CR. I think it's inappropriate to have an absolute list like the spec has now. Ideally I'd like to use the wording Bjoern suggested, but if we absolutely have to list mimetypes why not do something like: If there is no content type, or the content type is one that the UA considers to be an XML type ... . At least the following types SHOULD[1] be considered XML types; application/xml, text/xml, text/xsl and any type ending in +xml. [1] not sure if it should be a MUST or SHOULD requirement. / Jonas
Re: [XMLHttpRequest] update from the editor
On May 8, 2007, at 1:25 PM, Jonas Sicking wrote: Anne van Kesteren wrote: * text/xsl has been added as a MIME type that causes responseXML to return a Document object (if the resource can indeed be parsed according to the XML specfications.) Again, for compatibility reasons. There is no need for the draft to encourage use of unregistered media types, and there is very little need for the draft to apply non-XML treatment to media types like application/smil which are defined for use with XML documents. I believe it is entirely sufficient and more appropriate to state, for example, If the internet media type in the Content-Type header indicates the entity body is an XML document, Vendors have indicated they would like to have defined what that would mean, which is what the draft now tries to say. This indeed excludes (now obsolete?) MIME types such as application/smil but I don't think that will cause a problem in practice. If it does, I suppose we should get implementation feedback during CR. I think it's inappropriate to have an absolute list like the spec has now. Ideally I'd like to use the wording Bjoern suggested, but if we absolutely have to list mimetypes why not do something like: If there is no content type, or the content type is one that the UA considers to be an XML type ... . At least the following types SHOULD[1] be considered XML types; application/xml, text/xml, text/ xsl and any type ending in +xml. [1] not sure if it should be a MUST or SHOULD requirement. It should be a MUST because: - We want test cases to cover it. - There's no sensible reason to let a UA to not treat any of the listed types as XML if it supports XML at all, if at least some UAs do. I'm also not sure of the benefit of letting the UA treat arbitrary other types as XML besides those listed. Modern XML MIME types should all be following the +xml convention. And clearly for interoperability we want it to be the case that the UA MUST NOT treat text/html or text/plain or image/png as XML types. What types are there where it would be acceptable for the UA to go either way? Regards, Maciej
Re: [XMLHttpRequest] update from the editor
Maciej Stachowiak wrote: On May 8, 2007, at 1:25 PM, Jonas Sicking wrote: Anne van Kesteren wrote: * text/xsl has been added as a MIME type that causes responseXML to return a Document object (if the resource can indeed be parsed according to the XML specfications.) Again, for compatibility reasons. There is no need for the draft to encourage use of unregistered media types, and there is very little need for the draft to apply non-XML treatment to media types like application/smil which are defined for use with XML documents. I believe it is entirely sufficient and more appropriate to state, for example, If the internet media type in the Content-Type header indicates the entity body is an XML document, Vendors have indicated they would like to have defined what that would mean, which is what the draft now tries to say. This indeed excludes (now obsolete?) MIME types such as application/smil but I don't think that will cause a problem in practice. If it does, I suppose we should get implementation feedback during CR. I think it's inappropriate to have an absolute list like the spec has now. Ideally I'd like to use the wording Bjoern suggested, but if we absolutely have to list mimetypes why not do something like: If there is no content type, or the content type is one that the UA considers to be an XML type ... . At least the following types SHOULD[1] be considered XML types; application/xml, text/xml, text/xsl and any type ending in +xml. [1] not sure if it should be a MUST or SHOULD requirement. It should be a MUST because: - We want test cases to cover it. - There's no sensible reason to let a UA to not treat any of the listed types as XML if it supports XML at all, if at least some UAs do. I'm also not sure of the benefit of letting the UA treat arbitrary other types as XML besides those listed. Modern XML MIME types should all be following the +xml convention. And clearly for interoperability we want it to be the case that the UA MUST NOT treat text/html or text/plain or image/png as XML types. What types are there where it would be acceptable for the UA to go either way? Currently mozilla treat 'text/rdf' as XML in addition to that list, though I don't feel strongly about including that. Don't know how much stuff out there with that mimetype. I'll check with rdf people. If we are making the list absolute, I feel weird about including things like 'text/xsl' and 'text/rdf' as neither of them are real mimetypes. Is there really a lot that would break if 'text/xsl' was not included? / Jonas
Re: [XMLHttpRequest] update from the editor
Maciej Stachowiak wrote: If we are making the list absolute, I feel weird about including things like 'text/xsl' and 'text/rdf' as neither of them are real mimetypes. Is there really a lot that would break if 'text/xsl' was not included? No clue. I don't think it's bad to make requirements for unofficial MIME types, since in theory no one should be using them for either XML or non-XML, so UA requirements for them can be considered error handling. Sure, it wouldn't be the end of the world if we did include them. But I'd rather that we default to not do stuff like this unless it is shown that it'll break a lot of content. Anne: was there a reason 'text/xsl' was included other than IE does it? Or is it known to actually break sites? / Jonas
Re: [XMLHttpRequest] update from the editor
* Maciej Stachowiak wrote: I'm also not sure of the benefit of letting the UA treat arbitrary other types as XML besides those listed. Modern XML MIME types should all be following the +xml convention. And clearly for interoperability we want it to be the case that the UA MUST NOT treat text/html or text/plain or image/png as XML types. What types are there where it would be acceptable for the UA to go either way? It is not useful to assert anyone suggests user agents treat arbitrary types as indicating XML documents; clearly image/png does not indicate an XML document, and even if a user agent would do that, parsing would fail in all but the most bizarre cases, resulting in the same behavior. It is false to assert modern XML MIME types follow the +xml convention. The most recent type proposal, application/vnd.fcsexpress.launchfile, does not, the reason being that the format uses XML now, but might not do so in the future. An ISO standard case whether going either way is sensible is application/fastinfoset, which certainly is a modern type. If you do not support application/fastinfoset, you might well treat it as non-XML type; you could also treat it as XML document and find you do not support the 'finf' character encoding. Either way you get the same behavior. Of course, if you do support it, you are not likely to honor the proposed requirement to treat it as non-XML due to benefit/ cost considerations. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
