Re: [XMLHttpRequest] update from the editor

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

I did take your suggestion. Not having Content-Type specified now gives  
you responseXML as well. I assumed you would read the diffs you receive  
through e-mail. From now on I'll try to be more elaborate.


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

The reason is that the draft needs to be reasonably compatible with  
existing content such that it can be implemented without breaking content.


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

The user agent conformance class clearly says as long as the algorithm  
used produces the same result it doesn't matter how they do it.


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

Ok, this is now part of the open() algorithm.


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

Received on Tuesday, 8 May 2007 14:20:21 UTC