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:hst...@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
