Re: Proposed pubrules change for clearer indication of First Public/Last Call Working Draft at top of document

On Wednesday, March 20, 2013 at 11:46 PM, Giuseppe Pascale wrote:

> On Tue, 19 Mar 2013 19:15:59 -0000, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>  
> >  
> > IMO, LC should absolutely not be viewed as stable (only for marketing  
> > reasons or to deliberately deceive). It just means that it won't get any  
> > more features at that particular moment - but the stability of those  
> > features is not guaranteed in any way…
>  
>  
>  
> But this is what people are looking for actually, a spec that 1) are not  
> expecting to see major features added 2) whose features can surely be  
> modified but only if there is a good reason for it (e.g. they were very  
> broken). Currently the editor draft doesn't give you this sort of  
> guarantee.

Neither does any other kind of W3C label. Consider:  

1. Document goes to CR - 3 month review period.
2. A whole bunch of reviews come in. Test suite is created.
3. Editor's draft is updated - CR now grossly out of date.  
4. Two months pass - more changes are made to ED.  
5. Document is republished as an ordinary WD (new feature is added, because someone found a new use case).
6. Document goes to LC.  
7. Document gets help up for a year on a patent disclosure.  
8. Work continues regardless in the ED.  
9. …rinse and repeat.  

When 2 happens, Ed is more "stable" than CR (or any other label). This is why when you look at any HTML draft, you get the red box telling you that the document is out of date and to . For example:

http://www.w3.org/TR/2012/WD-html5-20121025/

"For the latest updates from the HTML WG, possibly including important bug fixes, please look at the editor's draft instead."

> So I agree that spec evolves, but is still useful to know if a particular  
> document is on a "stabilization path" or if it's still evolving.

This assumes that there is a linear path of steady development on a spec: yes, specs become more stable over time, but that has little relationship to what label is slapped on it or when and how stabilization happens. To believe otherwise sets forth an unrealistic expectation and understanding of how specifications work is actually done - and how stability is actually achieved. Hence, relying on W3C labels as signs of stability should be strongly discouraged.  

This why every document's SoTD (except REC) clearly states:   

"This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress."

Consider what happened with the abandonment of XHR in favor of XHR 2 (which is just called XHR), and that all new core specs are being done as Living Standards (including HTML itself):  

http://dom.spec.whatwg.org/
http://encoding.spec.whatwg.org/
http://fetch.spec.whatwg.org/
http://html.spec.whatwg.org/

Almost all of the above end up being copy/pasted by the W3C to eventually get the patent commitments - as well as to get help from the W3C membership with the testing (and to resolve a few differences of opinion between the W3C and WHATWG, at least in the case of HTML).  

> And for  
> people not involved in the everyday work these sort of milestones are the  
> only indication of this sort.
>  

This is an misuse of the W3C process (and only loosely maps to reality - hence my call for legally important drafts to be labelled properly as "Lawyer Call" or "Attorney Call"). The W3C process should only be seen as a legal instrument to secure patents commitments once two implementations have been shown to be interoperable.  

However, having a REC doesn't even guarantee "stability" because:

1. new editions may supersede old ones.  
2. specs like WebIDL, and DOM, are being forked on parts that interoperable primarily for the purpose of   moving them to REC, but work on those specs continues unabated or with little regard for the W3C process.

I hope that helps clarify things: one can only view a spec as stable if it can be implemented in an interoperable manner to meet a set of use cases - and those use cases can also change over time. Interoperability can be verified through a test suite and hopefully real content in the wild). Until then, all bets are off and labels won't help.

--  
Marcos Caceres

Received on Friday, 22 March 2013 11:28:38 UTC