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

Re: First Public WD of XMLHttpRequest released

From: Jim Ley <jim@jibbering.com>
Date: Wed, 5 Apr 2006 23:41:17 +0100
Message-ID: <008201c65902$0fbe6360$6400a8c0@Snufkin>
To: "Web APIs WG \(public\)" <public-webapi@w3.org>

"Anne van Kesteren" <annevk@opera.com>
>> I think that we agreed that that behaviour was a bug and that we really 
>> should be encouraging null. I guess that flagging what implementations 
>> do might depend on how soon the bug is fixed.
>
> Authoring guidelines, I say.

What  are authoring guidelines?  a W3 Note aiding authors or ... ?

>>> MUST for xmlEncoding seems unreasonably tight restriction, what's the 
>>> motivation?
>>
>> Agreed.
>
> You want to allow implementations to do some random serialization?

Nope, just if they only have a serializer that works in UTF-8, then that's a 
perfectly valid encoding to serialise too - any XML parser is going to able 
to understand it.

I also don't really understand why the choice was xmlEncoding - it means the 
server could send a UTF-16BE document but then get it re-serialised back as 
UTF-8, if that's fine, I don't see why it's not also fine if the original 
Encoding was ISO-8859-1.  Also what happens if the Document contains 
characters not available in the Document.xmlEncoding (DOM 3 core may explain 
what happens in this situation and mean that it's impossible to create, but 
I don't think so)  It just seems a strange and rather arbitrary restriction.

> How is that different from what the text currently says? Perhaps 
> "processing" should be replaced with "retrieving"?

Yes, this was pretty much my point, the text just isn't clear if processing 
comes before or after downloading, nothing more, just about any language 
clarification would be fine.

Cheers,

Jim. 
Received on Wednesday, 5 April 2006 22:42:34 GMT

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