W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

[xhr] Questions on the future of the XHR spec, W3C snapshot

From: Hallvord R. M. Steen <hsteen@mozilla.com>
Date: Fri, 17 Oct 2014 17:19:13 -0700 (PDT)
To: public-webapps <public-webapps@w3.org>
Message-ID: <899870493.33636821.1413591553259.JavaMail.zimbra@mozilla.com>
Apologies in advance that this thread will deal with something that's more in the realm of politics.

First, I'm writing as one of the W3C-appointed "editors" of the "snapshot" the WebApps WG presumably would like to release as the XMLHttpRequest recommendation, but I'm not speaking on behalf of all three editors, although we've discussed the topic a bit between us.

Secondly, we've all been through neverending threads about the merits of "TR, spec stability" W3C style versus "living standard, spec freedom and reality alignment" WHATWG style. I'd appreciate if those who consider responding to this thread could be to-the-point and avoid the ideological swordmanship as much as possible.

When accepting editor positions, we first believed that we could ship a TR of XHR relatively quicky. (I think of that fictive TR as "XHR 2" although W3C haven't released any XHR 1, simply because CORS and the other more recent API changes feel like "version 2" stuff to me). As editors, we expected to update it with a "next version" if and when there were new features or significant updates). However, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 "stand-alone" is the right thing to do.. However, leaving an increasingly outdated snapshot on the W3C side seems to be the worst outcome of this situation. Hence I'd like a little bit of discussion and input on how we should move on.

All options I can think of are:

a) Ship a TR based on the spec just *before* the big Fetch refactoring. The only reason to consider this option is *if* we want something that's sort of stand-alone, and not just a "wrapper" around another and still pretty dynamic spec. I think such a spec and the test suite would give implementors a pretty good reference (although some corner cases may not be sufficiently clarified to be compatible). Much of the refactoring work seems to have been just that - refactoring, more about pulling descriptions of some functionality into another document to make it more general and usable from other contexts, than about making changes that could be observed from JS - so presumably, if an implementor followed the TR "2.0" standard they would end up with a generally usable XHR implementation.

b) Ship a TR based on the newest WHATWG version, also snapshot and ship the "Fetch" spec to pretend there's something stable to refer to. This requires maintaining snapshots of both specs.

c) Ship a TR based on the newest WHATWG version, reference WHATWG's Fetch spec throughout.

d) Abandon the WebApps "snapshot" altogether and leave this spec to WHATWG.

For a-c the editors should of course commit to updating snapshots and eventually probably release new TRs.

Is it even possible to have this discussion without seeding new "W3C versus WHATWG" ideology permathreads?

Input welcome!
Received on Saturday, 18 October 2014 00:19:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:31 UTC