Re: RE: Questions on the future of the XHR spec, W3C snapshot

Thanks Hallvord for having started the thread and sharing the annotate_spec.js to move the testing activity forward.

For the spec side of it, I agree to Domenic's idea either publishing it as a group note pointing to the source material or installing a redirection to it. Without the Fetch refactoring, it seems that a new TR based on the old snapshot won't be satisfying the forward compatibility sooner or later. E.g., web authors will also expect an XHR request will fire a fetch event on a service worker, but the old snapshot will still remain with a pointer to a fetch in HTML spec, etc.

--
Jungkee


------- Original Message -------
Sender : Domenic Denicola<domenic@domenicdenicola.com> 
Date   : 2014-10-20 11:44 (GMT+09:00)
Title  : RE: Questions on the future of the XHR spec, W3C snapshot

I just remembered another similar situation that occurred recently, and in my opinion was handled perfectly:

When it became clear that the WHATWG DOM Parsing and Serialization Standard was not being actively worked on, whereas the W3C version was, a redirect was installed so that going to https://domparsing.spec.whatwg.org/ redirected immediately to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html.


This kind of solution seems optimal to me because it removes any potential confusion from the picture. XHR in particular seems like a good opportunity for the W3C to reciprocate, since with both specs there's a pretty clear sense that we all want what's best for the web and nobody wants to have their own outdated copy just for the sake of "owning" it.

-----Original Message-----
From: Hallvord R. M. Steen [mailto:hsteen@mozilla.com] 
Sent: Friday, October 17, 2014 20:19
To: public-webapps
Subject: [xhr] Questions on the future of the XHR spec, W3C snapshot

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!
-Hallvord

<p>&nbsp;</p>--
Jungkee Song
Samsung Electronics<p>&nbsp;</p>

Received on Monday, 20 October 2014 05:28:43 UTC