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

Re: XMLHttpRequest Comments from W3C Forms WG

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 17 Dec 2009 09:44:56 -0800
Message-ID: <63df84f0912170944k620b9e75re2bcf3a60ec6a50e@mail.gmail.com>
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Forms WG <public-forms@w3.org>
On Thu, Dec 17, 2009 at 9:30 AM, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
> 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.

I don't think I understand your suggested changes. As long as the
concepts that XHR uses are only defined in the HTML5 spec, XHR will
always require that those things from the HTML5 spec are implemented
when implementing XHR. This doesn't seem to change even if the XHR
spec is split into two.

However I don't really understand what specifically you are suggesting
should live in the two XHR specs, so I could very well be
misunderstanding you. Could you describe that in more detail?

/ Jonas
Received on Thursday, 17 December 2009 17:45:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:02 UTC