- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 06 Apr 2006 00:22:39 +0200
- To: "Robin Berjon" <robin.berjon@expway.fr>, "Jim Ley" <jim@jibbering.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
On Wed, 05 Apr 2006 23:35:10 +0200, Robin Berjon <robin.berjon@expway.fr> 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/>
Received on Wednesday, 5 April 2006 22:22:45 UTC