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:bjoern@hoehrmann.de · 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/

Received on Monday, 14 May 2007 18:57:23 UTC