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

On 10/17/14 8:19 PM, Hallvord R. M. Steen wrote:
> 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.

I would appreciate that too (and I will endeavor to moderate replies 
accordingly.)

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

The Plan of Record (PoR) is still to continue to work on both versions 
of XHR (historically called "L1" and "L2". However, I agree Anne's 
changes can be considered `new info` for us to factor. As such, I think 
it is important for _all_ of our active participants to please provide 
input.

(If/when there appears to be a need to record consensus on a change to 
our PoR for XHR, I will start a CfC.)

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

Indeed, the situation is confusing. (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").)

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

I agree. (It still seems useful to me to have a standard ("reference") 
that covers the set of broadly implemented and interoperable features.)

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.

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

I suspect this would result in objections to forking Fetch.

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

As such, we could do c) but with respect to helping to set realistic 
expectations for spec that references such a version of XHR, I think the 
XHR spec should be clear (think "Warning!"), that because of the Fetch 
reference, the XHR spec might never get published beyond CR.


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

-Thanks, AB

[NRP] <http://www.w3.org/2013/09/normative-references>

Received on Sunday, 19 October 2014 14:00:02 UTC