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: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 10:58:18 UTC