- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Fri, 13 Jun 2008 15:33:10 +0100
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: public-webapps@w3.org, public-forms@w3.org
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