On Fri, 13 Jun 2008 14:54:50 +0200, Mark Birbeck
<[EMAIL PROTECTED]> 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
interoperable.)
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
<http://annevankesteren.nl/>
<http://www.opera.com/>
