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

>> 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..

> (For those not familiar with 
> WebApps' XHR TR publication history, the latest snapshots are: Level1 
> <http://www.w3.org/TR/2014/WD-XMLHttpRequest-20140130/>; Level 2 
> <http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/> (which now says 
> the Level 1 <http://www.w3.org/TR/XMLHttpRequest/ is the "Latest version").)

The one currently known as "Level 2" is very outdated - it still has stuff like an AnonXMLHttpRequest constructor.

> What to do about the L2 version does raise some questions and I think a) 
> can be done as well as some set (possibly an empty set) of the other 
> three options.

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

> The staff does indeed permit normative references to WHATWG specs in WD 
> and CR publications so that wouldn't be an issue for those types of 
> snapshots. However, although the Normative Reference Policy [NRP] 
> _appears_ to permit a Proposed REC and final REC to include a normative 
> reference to a WHATWG spec, in my experience, in practice, it actually 
> is _not_  permitted. (If someone can show me a PR and/or REC that 
> includes a normative reference to a WHATWG spec, please let me know.)

I guess we could push for allowing it if we want to go this route - however, pretty much all the interesting details will be in the Fetch spec, so it's going to be a bit strange. Actually, we could introduce such a spec like this: "Dear visitor, thanks for reading our fabulous W3C recommendation. If you actually want to understand or implement it, you'll see that you actually have to refer to that other spec over at whatwg.org for just about every single step you make. We hope you really enjoy using the back button. Love, the WebApps WG".


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

> Do you mean abandon both the L1 and L2 specs or just abandon the L2 version?

The only good reason we'd want to ship two versions in the first place would be if we lack implementations of some features and thus can't get a single, unified spec through a transition to TR. If we're so late shipping that all features have two implementations there's no reason to ship both an L1 and L2 - we should drop one and ship the other. Isn't that the case now? I should probably go through my Gecko bugs again, but off the top of my head I don't remember any "major feature missing" bug - the overwhelming number are "tweak this tiny little detail that will probably never be noticed by anyone because the spec says we should behave differently"-type of bugs.

Additionally, if we don't plan to add new features to XHR there's no reason to expect or plan for a future L2. If we want to do option b) or c) we could make that L2, but I don't think it adds much in terms of features, so it would be a bit odd. I think we can drop it.
-Hallvord

Received on Sunday, 19 October 2014 15:15:15 UTC