RE: XMLHttpRequest Comments from W3C Forms WG

 
Please note (for the record) the following reference from public-webapps on this topic before.
(The lists.w3.org archives seem to be stuck in 2008.)
http://article.gmane.org/gmane.org.w3c.appformats/8012

Leigh.
-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of Klotz, Leigh
Sent: Wednesday, November 25, 2009 1:27 PM
To: Boris Zbarsky
Cc: public-webapps@w3.org; Forms WG
Subject: RE: XMLHttpRequest Comments from W3C Forms WG

Boris,

Thank you for your response.  I appreciate your asking the clarifying questions.  I'll put some answers inline below.
Please consider these answers to be part of the Forms WG comment as well.

Leigh.

> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> Sent: Wednesday, November 25, 2009 12:54 PM
> To: Klotz, Leigh
> Cc: public-webapps@w3.org; Forms WG
> Subject: Re: XMLHttpRequest Comments from W3C Forms WG
> 
> On 11/25/09 3:46 PM, Klotz, Leigh wrote:
> > 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.
> 
> Note that these were all building on a common reverse-engineered base, and that the implementations were far from interoperable.

Indeed, a standalone XHR specification document is welcome, and interoperability is weakened if it works only in HTML5.

> 
> > 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
> 
> The main dependencies, I believe, are on the Window object and the security sandboxing behavior that web browsers have.  How do you propose such dependencies be eliminated?

The majority of the current WD is well modularized and isolated.  These points are integration points for XHR and other environments.  One important target of integration is HTML5, but it is not the only one.  Forgive me if I sound like I'm lecturing, but I'd just like to state this point about abstraction for the archives: a small piece of modular functionality which needs to be integrated into a larger system should specify its integration points and the requirements it has for support from the larger system.  That's what we mean by "minimum requirements" below.

So, to be concrete in an example dependency, if the window object is important to XHR, then its dependencies should be abstracted out.  It's unfortunate that the WD notes that a previous effort at providing a Window Object specification cannot be used, but it is still better for XHR to specify its requirements and let them be by its integrators, whether they be HTML5, a revivified Window Object 1.0, or some other context.

For example, section 4.1 "Base and Origin URL" says 
   This specification defines their values when the global object is represented by the Window object. 
   When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate 
   for that context. That is considered to be out of scope for this specification. 

Our point is that the XHR document should merely state its requirements for such facilities (base and origin) and that the HTML5 specification document should say how it satisfies them.  Alternatively, a companion document called "XMLHttpRequest for HTML5" could specfiy it, but that's a detail of integration best left to the HTML5 WG.

In summary, we ask that the XHR document define its requirements, and that the integration with HTML5 satisfy them.

I realize that there are other dependencies on HTML5 in the XHR document, but I would like to agree at first on the principle that specifications which incorporate XHR should depend on it, and not vice versa.

(I won't specifically address the last question below, because I believe it's been answered sufficiently above.)

Leigh.

> 
> > and that the XMLHttpRequest
> > Working Draft be changed to specify minimum requirements for 
> > integration in the areas for which it depends on HTML5.
> 
> The XHR spec needs to describe the precise behavior of things like 
> same-origin requests.  However nothing specifies the concept of 
> "origins" outside the HTML5 specification.  Should XHR simply say that 
> something else needs to define origins, in this situation, without 
> referring to the one thing that actually does define them?  There are 
> no plans for anyone other than HTML5 to define them at this point, and 
> the
> HTML5 definition is not limited to HTML documents.
> 
> -Boris

Thank you,
Leigh.

Received on Wednesday, 25 November 2009 21:40:25 UTC