W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: IE Team's Feedback on the XHR Draft

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 07 Feb 2008 11:42:43 +0100
To: "Sunava Dutta" <sunavad@windows.microsoft.com>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>, "Gideon Cohn" <gidco@windows.microsoft.com>, "Zhenbin Xu" <zhenbinx@windows.microsoft.com>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "Marc Silbey" <marcsil@windows.microsoft.com>, "Ahmed Kamel" <Ahmed.Kamel@microsoft.com>
Message-ID: <op.t55hdh1i64w2qv@annevk-t60.oslo.opera.com>

On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta  
<sunavad@windows.microsoft.com> 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/>
Received on Thursday, 7 February 2008 10:39:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2008 10:39:04 GMT