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: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 Tuesday, 8 May 2007 09:59:50 UTC