W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: First Public WD of XMLHttpRequest released

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 14 May 2006 12:41:16 +0200
To: "Jim Ley" <jim@jibbering.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s9jem2h364w2qv@id-c0020.oslo.opera.com>

On Thu, 06 Apr 2006 11:51:17 +0200, Jim Ley <jim@jibbering.com> wrote:
>>> I don't see why responseText MUST be null other than in readyState 3  
>>> or 4, why not undefined (e.g. if the firing of the 2 is delayed for  
>>> some reason then data could be available) Equally MUST on 3 is  
>>> incompatible with existing implementations.
>>
>> It's never null. If the firing of the 2 is delayed, isn't that just a  
>> bug?
>
> No, we're not mandating that events fire in realtime - we can't as ES is  
> single threaded etc.

Another way of saying is that until you fire the event the attribute MUST  
be the empty string...


>> The "MUST on 3" is incompatible with existing implementations in what  
>> way?
>
> MS's XHR implementation throws an error on 3.

I'm in favor of leaving the specification as is and considering what IE  
does at the moment as a bug.


>>> alert( ) isn't defined anywhere, traditionally print has been used as  
>>> a dummy function in ES code.
>>
>> Any pointers of its use?
>
> The ES spec, just changing alert to print...

Used a print() function instead.


>>  by data.xmlEncoding, if specified and supported, or UTF-8 otherwise
>>
>> Makes some sense to me...
>
> I still don't see the point of the restriction at all, and inputEncoding  
> would be a better option than xmlEncoding  - if we're assuming the  
> server knows the best format for a document serialisation, but I don't  
> see the point of requiring such behaviour.

See ISSUE-83.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Sunday, 14 May 2006 10:41:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT