RE: XMLHttpRequest Comments from W3C Forms WG

Anne,
Thank you for your corrections and updates.

I'd like to suggest that the main issue is dependency of the XHR document on concepts where "HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes,  Etc".

If this is indeed the case, and the dependency cannot be abstracted out, then XHR must well and truly be considered a part of HTML5.
However, since you site SVG as another user of XHR, then it seems that it's still a goal to have XHR not require HTML5.

Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands.

Thank you,
Leigh.

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@opera.com] 
Sent: Wednesday, December 16, 2009 6:54 AM
To: Klotz, Leigh; WebApps WG
Cc: Forms WG
Subject: Re: XMLHttpRequest Comments from W3C Forms WG

On Wed, 25 Nov 2009 21:46:59 +0100, Klotz, Leigh <Leigh.Klotz@xerox.com>
wrote:
> This comment on XMLHttpRequest [1] is from the Forms WG.
>
> A standalone W3C Recommendation-track document is welcome, particularly  
> because of the statement in [2] "The goal of this specification is to  
> document a minimum set of interoperable features based on existing  
> implementations, allowing Web developers to use these features without  
> platform-specific code."  This goal was widely quoted in web discussion  
> on the working drafts, and is no doubt an attractive feature of a  
> standalone specification document.

Note that we changed this goal slightly because documenting the mimimum  
set of interoperable features did not work very well once you went beyond  
a certain level of detail.


> The XMLHttpRequest functionality described in this document has  
> previously been well isolated, and in fact XHR itself has beeen  
> implemented by a number of different desktop browser vendors by copying  
> the original implementations.
>
> It appears that the current draft, howevever, has a wide dependence on  
> HTML5: [3] "This specification already depends on HTML 5 for other  
> reasons so there is not much additional overhead because of this."

This is not new, actually, but alas.


> That dependence runs counter to the goals of allowing Web developers to  
> use the features without platform-specific code.

Why would that be? HTML5 is not platform-specific.


> While it may be useful for the HTML5 specifications to include  
> XMLHTTPRequest and make enhancements to it, the dependency should be  
> from HTML5 on XMLHttpRequest, and not vice versa.  Making XMLHttpRequest  
> depend on HTML5 causes problems with non-HTML5 implementations of the  
> feature.

HTML5 is the only specification that defines several core concepts of the  
Web platform architecture, such as event loops, event handler attributes,  
etc.


> In summary, we feel that the dependencies between HTML5 and  
> XMLHttpRequest are in the wrong direction.  We ask that the dependency  
> on HTML5 be eliminated, and that the XMLHttpRequest Working Draft be  
> changed to specify minimum requirements for integration in the areas for  
> which it depends on HTML5. The HTML5 document itself can surely satisfy  
> these requirements.

I do not think it makes sense that a user agent that implements e.g. HTML5  
and SVG would have two implementations of XMLHttpRequest. HTML5 simply  
defines some core underlying concepts and these will be the same  
everywhere. There are indeed things that can differ depending on the  
context and those have been abstracted out, as you found. Mostly to  
facilitate Web Workers, but I can imagine these hooks might be used  
elsewhere too.


> [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119

> [2] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/

> [3] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies


(I corrected the numbering here.)


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 16 December 2009 19:48:42 UTC