-----Original Message-----
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, December 17, 2009 11:33 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 11:18 AM, Klotz, Leigh <leigh.kl...@xerox.com>
wrote:
> Jonas,
> I'm not sure how the dependency is specified in the XHR draft. Can you
point me to it? The word "event loop" doesn't appear.
The term "queue a task" is defined in HTML5, and uses the event loop.
/ Jonas
Jonas,
Thank you for finding it form me. I see the use of "queue a task" now.:
http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#terminology
The terms and algorithms <fragment>, <scheme>, document base URL,
document's character encoding, event handler attributes, event
handler event type, fully active, Function, innerHTML, origin,
preferred MIME name, resolve a URL, same origin, storage mutex,
task, task source, URL, URL character encoding, queue a task,
and valid MIME type are defined by the HTML 5 specification. [HTML5]
I'd be surprised if some of these aren't terms already defined elsewhere.
"URL" for example, is surely not given a different definition in HTML5 from the
definition in RFC 3986.
The rest of these terms not elsewhere defined would need to be defined
sufficiently by contract in the XHR document and
satisfied in the HTML5 implementation document, yet left open for
"implementation" by a collaborating spec for HTML5's implementation.
In the case of "queue a task," it appears to be used in XHR, but event loop is
not used in XHR.
While I can't really comment on whether XHR should leave to the implementation
the resolution of single vs multiple task queues, it in fact may not me germane
to the XHR specification.
When I follow the implied link from #terminology to the HTML5 draft, I get this:
http://www.w3.org/TR/2009/WD-html5-20090825/Overview.html#queue-a-task
This section of the HTML5 document itself admits that there may be other
implementations of task queues, as in this note:
Note: Other specifications can define other event loops; in particular, the
Web Workers specification does so.
Therefore, it seems like it would be in the best interest of not only HTML5 but
also "Web Workers" (no link) to have XHR efine its requirements, and let them
be satisfied by integration with other specifications, HTML5 being a prime
case, but "Web Workers" possibly another, in addition to the usual suspects.
In summary, I must say that I don't see any roadblocks to a positive response
to the Forms WG comment in question, and it doesn't appear to me that it
requires all of the many months of work cited by Ian. Ian's point may be valid
for the entireity of the HTML5 document, but for this XHR document to advance
to the next stage, it still seems both necessary and possible to resolve the
required definitions in a way that makes HTML5 integration almost unchanged,
yet leaves open integration with, as Anne aptly puts it, other contexts.
Leigh.
