Re: [xhr] Questions on the future of the XHR spec, W3C snapshot
[ Apologies for top posting ] I just added a 11:30-12:00 time slot on Monday October 27 for XHR: https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27 I believe Jungkee will be at the meeting so, Hallvord and Julian please join via the phone bridge and/or IRC if you can: https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics -Thanks, AB On 10/19/14 11:14 AM, Hallvord R. M. Steen wrote: 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
Re: [xhr] Questions on the future of the XHR spec, W3C snapshot
On 10/19/14 10:02 PM, Michael[tm] Smith wrote: Arthur Barstow art.bars...@gmail.com, 2014-10-19 09:59 -0400: (If someone can show me a PR and/or REC that includes a normative reference to a WHATWG spec, please let me know.) If it's your goal to ensure that we actually do never have a PR or REC with a normative reference to a WHATWG spec, the line of logic implied by that statement would be a great way to help achieve that. (Huh? I'm on record for the opposite.) If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference the Fetch spec. 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. That's not necessary. Nor would it be helpful. I think it is important to try to set expectations as accurately as possible and that ignoring past history doesn't seem like a useful strategy. -Thanks, AB
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
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
Re: [xhr] Questions on the future of the XHR spec, W3C snapshot
Arthur Barstow art.bars...@gmail.com, 2014-10-19 09:59 -0400: ... 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. There's no prohibition against referencing WHATWG specs in RECs. (If someone can show me a PR and/or REC that includes a normative reference to a WHATWG spec, please let me know.) If it's your goal to ensure that we actually do never have a PR or REC with a normative reference to a WHATWG spec, the line of logic implied by that statement would be a great way to help achieve that. If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference the Fetch spec. 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. That's not necessary. Nor would it be helpful. --Mike -- Michael[tm] Smith http://people.w3.org/mike signature.asc Description: Digital signature
Re: [xhr] Questions on the future of the XHR spec, W3C snapshot
On 10/17/14, 8:19 PM, Hallvord R. M. Steen wrote: a) Ship a TR based on the spec just *before* the big Fetch refactoring. If we want to publish something at all, I think this is the most reasonable option, frankly. I have no strong opinions on whether this is done REC-track or as a Note, I think, but I think such a document would in fact be useful to have if it doesn't exist yet. 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. I think this requires more pretending thatn I'm comfortable with for Fetch. ;) c) Ship a TR based on the newest WHATWG version, reference WHATWG's Fetch spec throughout. There doesn't seem to be much point to this from my point of view, since all the interesting bits are in Fetch. -Boris
[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
