On Wed, 05 Apr 2006 23:35:10 +0200, Robin Berjon <[EMAIL PROTECTED]>
wrote:
The responseXML MUST be null if the document is not WF cannot currently
be relied on in implementations, do you want to highlight that fact?
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.
MUST for xmlEncoding seems unreasonably tight restriction, what's the
motivation?
Agreed.
You want to allow implementations to do some random serialization?
"Immediately before processing the message body (if any), the
readyState attribute MUST be set to to 3 (Receiving). "
Processing the message body is unclear - does that mean XML parsing it,
or does that mean loading it or what?
Actually, what we said at the f2f was "immediately after having read the
headers" (i.e. hit the \n\n) which is simpler and also means that we
have defined behaviour for HEAD and other disembodied, err, bodiless
responses.
How is that different from what the text currently says? Perhaps
"processing" should be replaced with "retrieving"? HEAD requests seem to
be covered by (if any) although HEAD requests need some explicit language
somewhere. Mostly for saying readyState goes to 3 first and after that
directly to 4. (Which should be clear more or less, but still.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
