W3C home > Mailing lists > Public > public-forms@w3.org > December 2009

RE: XMLHttpRequest Comments from W3C Forms WG

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Thu, 17 Dec 2009 09:30:39 -0800
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF409717090@USA7061MS01.na.xerox.net>
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Henri Sivonen" <hsivonen@iki.fi>, "Anne van Kesteren" <annevk@opera.com>, "WebApps WG" <public-webapps@w3.org>, "Forms WG" <public-forms@w3.org>
Jonas,
Thank you for your response; comments below:

    -----Original Message-----
    From: Jonas Sicking [mailto:jonas@sicking.cc] 
    Sent: Thursday, December 17, 2009 9:22 AM
    To: Klotz, Leigh
    Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG
    Subject: Re: XMLHttpRequest Comments from W3C Forms WG
    
    On Thu, Dec 17, 2009 at 9:10 AM, Klotz, Leigh
    > <Leigh.Klotz@xerox.com> wrote: If XHR is wholly dependent on
    > HTML5 then it should either be moved into the HTML5
    > recommendation-track document, or renamed "XHR for HTML5."   Ian
    > has made a point that modularizing HTML5 itself is a large task;
    > it's not clear that the same applies to this XHR document, at
    > least to the same degree of work required.  I don't see what
    > harm comes from waiting to advance this XHR document until the
    > necessary work has been done.
    
    XHR isn't wholly dependent on HTML5. It is however dependent on a few 
    things that are currently only defined by the HTML5 specification.

    This means that if someone wants to implement XHR they will have
    to read parts of the HTML5 specification, and implement a few
    things defined in that specification. It does *not* however mean
    that if someone wants to implement XHR they will have to implement
    all, or even a significant portion, of the HTML5 specification.
    
    I hope that makes it clear?
    
The Forms WG comment is that those items be abstracted out as requirements
for any host of XHR, so that XHR need not depend on HTML5, but
can interoperate with any system which provides those few things.  

One easy way to dot his is to split the XHR document in two, with one document
called XHR which lists the dependencies, and another called "XHR For HTML5"
which satisfies them.  The amount of text changed need not be large: the
references to HTML5 need to be changed to "Requirements for host languages."

(Moving away from monolithic specs and towards more interoperable document
is one of our goals for next year.)
    
    Yes, we could move XHR into the HTML5 specification, but I don't 
    understand what problems that would solve. Feel free to elaborate.
    
I agree, it's not desirable at all, but it's the current state; 
the XHR document currently works only with HTML5.  That's why we're suggesting
an alternative that preserves the dependency on HTML5 for HTML5 integration, yet
allows other implementations.

    / Jonas

Leigh.
Received on Thursday, 17 December 2009 17:31:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:53 UTC