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
