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

Hi Anne,

> 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.)

Quite a contradiction. Unfortunately you can either describe XHR as it
exists, or can describe how you would like it to exist. But you can't
do both.

Anyway, you are not actually documenting 'what exists', since:

 * your spec requires the HTML 5 Window and Document objects, that no-one
   yet supports;

 * your spec requires DOM 2 Events, which IE doesn't require;

 * your spec requires that the only way to create an XHR object is via the
  Window object, which IE 5 and IE 6 *cannot* support, and other Windows
  applications don't need to support.

We have no problem with these limitations being ignored. But since
they show that the spec is clearly not 'documenting what exists', it
would save a lot of time if that wasn't continually used as an
argument against having more flexibility.


>> 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 :-)

Sure...that doesn't mean it's clear, though.


>> 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.

Since when have W3C specifications been written only for certain
audiences? The whole point of the process of review and 'last call' is
to get comments from various interested parties. You are saying that
you have already decided who the interested parties are.


> 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.

I don't really follow this.

But anyway, 'taking the web into account' is rather a slippery
concept. If browser vendors (of all shades, not just Microsoft) had
'taken the web into account' in the past, then Thomas Fuchs, Sam
Stephenson and John Resig would not be as celebrated as they are. So
forgive me if I don't trumpet the arrival of the cavalry in the form
of limited specifications created by some of the browser vendors.


>> 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.

No...you have not just defined an object, you have *also* constrained
its context. If you were designing a software application and defined
your classes in such a way that they would only run in one very
specific context, you'd be rightly laughed out of court.

And before you reply about 'ivory towers', and 'designing for the real
web', etc., the XForms WG is only asking for one or two lines to be
added to the spec.


> If you want something else, I suggest you define
> something else.

That's what I mean by wasteful. Why should I write another spec when
your spec would work for both your needs and the needs of others? Why
don't you do it? It's only a few lines that need changing in the spec.

The frightening thing about your attitude here is that it is
completely counter to the prevailing trend that embraces code-sharing,
open source, anti-patents, open standards, and so on. It certainly
makes me start to think the unthinkable; that all the rhetoric around
HTML 5 being 'open' is merely posturing.


>>  * 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.)

I don't know what you are trying to say here. But anyway, the point is this:

If you are documenting what you would *like to see*, then of course
you can refer to anything you like.

But you are arguing against flexibility in the use of the XHR object,
on the grounds that you are merely 'documenting what exists', and I am
saying that at a very simple logical level this is blatantly not true.
How can it be true if the spec that 'documents what exists' is
dependent on something that itself doesn't yet exist?


>>  * 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.

My point is not to document the ActiveX technique, but merely to
illustrate that even in the world of 'what exists' there are other
ways to instantiate an XHR object than the Window constructor.

Since IE 5 and IE 6 *only* support that method (they don't support the
native method), and you say this is irrelevant, then you seem to be
selective about 'documenting what exists'.

Which in turn leads me to think that this whole thing is a spurious
argument for not having the flexibility we suggest in the use of the
XHR object.


>> 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.

I know that. :)

But that's why we have organisations like the W3C, so that a variety
of opinions can be brought to bear; when they are doing their job
right, standards bodies like the W3C help us to create standards that
are usable by a broad community, rather than just a particular group.

Of course they don't always do this job right, and the group of people
around HTML 5 have quite rightly criticised the W3C in the past, for
being oriented only towards the 'big companies'. That group got what
it wanted, and the W3C has begun to open up more.

But let's hope that this group doesn't now do the same thing that they
have been criticising, and continue the tradition of producing
specifications that don't have broader applicability than some
particular interest group.

(Interestingly enough, your approach effectively requires that the
future Widgets 1.0 spec, which is still at a requirements stage [1],
will have to support Window as its containing object. Perhaps that's
the right solution, perhaps not, but it seems a little early in the
design process to enforce that...something that could be avoided by
some minor changes to the XHR spec.)

Regards,

Mark

[1] <http://dev.w3.org/2006/waf/widgets-reqs/>

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Friday, 13 June 2008 14:33:48 UTC