On Wed, 05 Apr 2006 21:48:26 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:
The IDL should define .send() - no parameters, to match the prose
description of send.
I guess I defer this to the "what IDL to use" discussion for now.
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?
Not really. Would be a nice addition for the authoring guidelines I guess.
I don't see why responseText MUST be null other than in readyState 3 or
4, why not undefined (e.g. if the firing of the 2 is delayed for some
reason then data could be available) Equally MUST on 3 is incompatible
with existing implementations.
It's never null. If the firing of the 2 is delayed, isn't that just a bug?
The "MUST on 3" is incompatible with existing implementations in what way?
alert( ) isn't defined anywhere, traditionally print has been used as a
dummy function in ES code.
Any pointers of its use?
MUST for xmlEncoding seems unreasonably tight restriction, what's the
motivation?
So how about going from:
by data.xmlEncoding, if specified, or UTF-8 otherwise
... to:
by data.xmlEncoding, if specified and supported, or UTF-8 otherwise
Makes some sense to me...
"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?
receiving the message body
... it is...
"UAs MAY set the Accept-Charset and Accept-Encoding headers and MUST NOT
allow them to be overridden. "
No motivation has been provided for the above restriction - I have a use
case in accessibility repair tools where the error is only in a
particular encoding, I want to be able to recreate the request that
gives that encoding, thus I need to be able to change Q-values.
Responded to this one already. In addition, we now have an open issue on
it.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
