Re: [XMLHttpRequest] update from the editor

On Tue, 08 May 2007 11:59:42 +0200, Bjoern Hoehrmann <derhoermi@gmx.net>  
wrote:
> * 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.

Fixed.


>>  * 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.


>>  * 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?

That's not non-compliant.


> 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...


> 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.

Fixed.


Thanks for reviewing!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 8 May 2007 10:25:15 UTC