W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [XHR] LC comments from the XForms Working Group

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 13 Jun 2008 15:19:36 +0200
To: "Mark Birbeck" <mark.birbeck@webbackplane.com>
Cc: public-webapps@w3.org, public-forms@w3.org
Message-ID: <op.ucovayll64w2qv@annevk-t60.oslo.opera.com>

On Fri, 13 Jun 2008 14:54:50 +0200, Mark Birbeck  
<mark.birbeck@webbackplane.com> wrote:
> I had suspected that there was another way to interpret the
> specification, but since I couldn't imagine why anyone working on a
> W3C specification would want to prevent it from being used by other
> specifications, I thought it best to give the spec the benefit of the
> doubt.

Interesting. The goal of this specification is to describe XMLHttpRequest  
as used on the Web in sufficient detail to get interoperable Web browser  
implementations. (The result of this is that while it is limited in scope,  
it will not always match all implementations because they are not yet  

> Anyway, this clarification means that the spec falls down on two counts.
> The first is that if you want to insist that there is a 'context
> dependency' whereby XHR objects must only exist in a world that
> supports the HTML 5 Window object, then you really need to change the
> wording of section 4. It currently says:
>   Objects implementing the Window interface must provide an  
> XMLHttpRequest()
>   constructor. [HTML5]
> This does not imply that a conforming implementation of XHR needs to
> support Window; it merely says that *if* a user agent supports Window,
> then it must also support the XHR constructor.

Section 2.1 also requires the Window object. Also, if you don't support  
it, as you found out, the rest of the specification falls apart so there  
certainly is a dependency there :-)

> However, as you can imagine, the XForms WG regards that tack is both
> unnecessary and wasteful; hence the second count on which the spec
> falls down.
> Certainly, a big problem is that the HTML 5 spec is not yet complete,
> so you are mandating a dependency on something that is not yet
> available.

Actually, this is not a big problem for the implementors we are targeting.  
HTML5 defines several concepts which XMLHttpRequest depends upon but the  
specifics of these concepts matter less to XMLHttpRequest (less to not at  
all, really). Also, these concepts are very much constrained by the Web  
which HTML5 takes into account so we pretty much know what HTML5 will say  
for them in the end.

> But this whole relationship is unnecessary because the XHR object
> could be used in many different contexts, in web application
> architectures far more varied than those narrowly conceived at
> present.
> You might say that since you are only documenting what currently
> exists, then this is not your problem, which would lead to the
> following comments:
>  * why go out of your way to prevent a standard from being reusable?  
> This is why
>    it is wasteful;

We're not going out of our way to do that, we're "simply" defining the  
XMLHttpRequest object. If you want something else, I suggest you define  
something else.

>  * the HTML 5 Window object does not currently exist, so how can this
> dependency?

By that rationale XMLHttpRequest does not exist either, which seems like a  
weird thing to say. (The same goes for Window by the way, but that may be  
less obvious.)

>  * the original XHR object--the Internet Explorer ActiveX control--can
> be instantiated
>    independently of a browser, so if you want to document 'what
> currently exists' you
>    need to allow for this, whether or not it is 'good design'.

Internet Explorer supports the normal way of doing this now. No need to  
specify behavior the Web platform does not depend upon.

> Our original requests for minor changes to the document to clarify
> that the XHR object be usable in other contexts and other
> specifications therefore still stand.

I'm afraid I don't really see the need.

Anne van Kesteren
Received on Friday, 13 June 2008 13:19:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:09 UTC