- From: Jim Ley <jim@jibbering.com>
- Date: Wed, 5 Apr 2006 23:41:17 +0100
- 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 UTC