On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta
<[EMAIL PROTECTED]> wrote:
o This spec is very different from existing HTML/CSS/DOM spec where
the functionality/API specification is the focus. This spec talks about
interface specification as well as a lot of details that appear to be
internal implementation issues that cannot be verified by Web developers.
I don't think that's true, actually. In fact, the specification leaves
implementation details up to the implementation. It says so in the
conformance criteria.
Having internal implementation recommendation for UA's is nice, however
we can improve the readability by calling out implementation detail
sections or having a separate section for this detail . What we've love
is to have the spec clearly state what is external API specification,
and what is internal implementation details. This way a web developer
can read this without reading the whole spec and take away the key
points.
I think everything that is not important is not there. So I don't really
see the issue.
§ I remember Anne mentioning that the spec's target audience is only
UA's however that is not clear from the spec. Here's an instance from
the spec (Send method) that highlights this.
Authors are sometimes called out in informative notes, based on feedback
we got on this. This should aid tutorial writers, etc. I don't expect that
authors familiar with the DOM, etc. have trouble reading this
specification, btw, I just don't think this will be their primary source
of information.
§ When the XMLHttpRequest() constructor is invoked a persistent pointer
to the associated Window object must be stored on the newly created
object. This is the Window pointer. The associated Window object is the
one of which the XMLHttpRequest() constructor was invoked. This
pointer<http://www.w3.org/TR/XMLHttpRequest/#window-pointer> must
persist even if the browsing context in which the Window is located is
destroyed (by removing it from a parent browsing context, for instance).
This is not a UA detail at all. This is very important for resolving URI,
etc.
§ The DONE state has an associated error flag which can be either
"true" or "false". The initial value of the error flag is "false".
This affects how e.g., the abort() method functions.
§ <For open call> If the password argument was not omitted and is null
remove stored password.
This affects if a password provided in the URI is transmitted or not.
§ <For open call> Switch the object to the
OPENED<http://dev.w3.org/2006/webapi/XMLHttpRequest/#opened-state>
state, set the send()
flag<http://dev.w3.org/2006/webapi/XMLHttpRequest/#send-flag> to "false"
and then synchronously dispatch a
readystatechange<http://dev.w3.org/2006/webapi/XMLHttpRequest/#readystatechange>
event on the object and return the method call.
This effects which events authors can catch. Whether send() will throw an
exception later on, and what the value of readyState is.
§ <For send call> If async is true set the send()
flag<http://dev.w3.org/2006/webapi/XMLHttpRequest/#send-flag> to "true".
This affects whether send() can be invoked again in a concurrent
JavaScript thread. (From an event handler for readystatechange for
instance.)
§ <For send call> Make a request to stored url, using HTTP method
stored method, user stored user (if provided) and password stored
password (if provided), taking into account the entity body, list of
request headers and the rules listed directly after this set of steps.
Synchronously dispatch a
readystatechange<http://dev.w3.org/2006/webapi/XMLHttpRequest/#readystatechange>
event on the object.
This affects what request is made and what event authors can catch.
[...]
etc.
Please link conformance test suite to an appendix/bottom of
specification.
We don't have an official test suite yet or a test suite location on
w3.org so I can't do that now.
o The spec is very detailed and the tests are difficult to correlate
to exact sections of the spec. I think that's understandable at this
stage since the spec is in flux. We think the official test suite
deserves to be called out; linking the tests to the spec will ensure
that this is the official test.
We will probably do this in due course. Note that completing a test suite
is required during CR stage. That's two stages away from where we are now.
o As per our agreement in the tech plenary the spec will conform to
IE's implementation of XHR (with the exception of constants) and will be
changed accordingly. The tests are important for us and other UAs as
it's the guarantor of that.
We have had no such agreement. I indicated that we have followed the IE
for a lot of scenarios, but there are some deviations.
§ If there is no Content-Type header or there is a Content-Type header
which contains a MIME type that is text/xml, application/xml or ends in
+xml (ignoring any parameters) use the rules set forth in the XML
specifications to determine the character encoding. Let charset be the
determined character encoding.
I don't quite get what you mean with this.
· Other observations from the spec
o Is this included due to security concerns?
§ Scripts in the resulting document tree will not be executed,
resources referenced will not be loaded and no associated XSLT will be
applied.
It's included to get consistent behavior.
It's not clear what the end result is we're trying to achieve with the
following is. Can we clarify?
§ The associated Document object is the one returned by the document
attribute from the object on which the XMLHttpRequest() constructor was
invoked (a Window object).
This helps establishing a base URI.
o Is it:
§ When invoking a new XHR object, tie new object to the window its
associated with?
No, the Window object has a document attribute that returns a Document
object.
§ User agents should persist document pointers to the newly created XHR
object?
I don't get this question.
Why is this in the open method section of the specification? I recommend
the spec does not mention this; if it does, we should talk about "the
future" in a separate section.
o A future version or extension of this specification will most likely
define a way of doing cross-site requests.
o It is likely that a future version of the
XMLHttpRequest<http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest-object>
object will dispatch an error event here as well
o It is likely that a future version of the
XMLHttpRequest<http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest-object>
object will dispatch an abort event here as well.
These are mentioned there to guide UA implementors who are implementing
XMLHttpRequest Level 2 on top of XMLHttpRequest Level 1. Do you have a
good reason to remove these statements?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
