"Anne van Kesteren" <[EMAIL PROTECTED]>
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.
