Re: [XHR] Status Update

On Tue, 10 Aug 2010 00:37:58 +0200, Maciej Stachowiak <mjs@apple.com>  
wrote:
> On Aug 9, 2010, at 6:05 AM, Anne van Kesteren wrote:
>> As a result of working on the test suite I found a few minor issues  
>> that would be nice to resolve (I'm not particularly interested in the  
>> solution to each of these problems, but I thought I would propose one  
>> in order to move things forward). I filed these bugs on them:
>>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322
>
> I agree with this change.
>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323
>
> I'll have to think about this one. It does seem like a feature addition,  
> and it's late in the game for that. It's not totally clear to me that  
> responseXML is the best way to expose parsing of HTML documents, since  
> there is no way to feature test for it. CR is probably too late to be  
> adding features, especially when it's not 100% clear it is the right  
> design.

Fair enough. I'm generating XMLHttpRequest and XMLHttpRequest Level 2 from  
the same source document and was trying to get rid of some of the (in my  
view) unneeded differences with some of these comments. I'll mark this bug  
as WONTFIX.


>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324
>
> Agree, assuming there is no Web compatibility issue.
>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325
>
> Agree.
>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326
>
> How do implementations currently behave in this case?

It seems most implementations actually allow it (commented in the bug). (I  
have not written tests for authorization yet.) But I believe Internet  
Explorer throws and per RFC 2616 it is not even part of http URLs.


>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327
>
> I'm not sure what the current proposal is here. I don't think a scheme  
> whitelist is right.

The current proposal is described in the last comment. Namely to allow  
everything (nothing is "unsupported" as far as open() is concerned) and  
let it be a network error in the request layer. (They will be cross-origin  
and not support CORS unless we really want them to work.)


>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328
>
> Seems ok to me, if there is no compatibility issue.

Not mentioning it at all is probably safest.


> Which of the changes above would require us to drop back to Working  
> Draft and have another Last Call? Any of them, or just a subset?

The one that changes conformance is not throwing for non same-origin URLs.  
That is also the most important. I do not think we can consider it just a  
"bug fix" but we could discuss it with the Director and see if it is ok.

Relevant URLs:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322
http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change


> If we do have another Last Call, I would prefer to go to CR again and  
> not short-circuit the process. I place more value on careful process  
> than on getting to REC quickly.

We could only go to PR if we met the CR requirements. Essentially you get  
a zero-day CR. If we actually have met the requirements (of which two  
fully compliant implementations will be the most tricky one) there is not  
much reason to issue a CR. I'm fine with doing it anyway though, but lets  
table this for then :-)


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 10 August 2010 06:14:23 UTC