Re: spec development process was: vendor prefixing

* Sylvain Galineau wrote:
>Of the things that puzzle me in the process, the claim that CR is a 'call 
>to implementation' ranks way up the list. If you reach CR with zero 
>implementation experience the CR status of your spec is simply not meaningful: 
>the odds of it not going back to WD upon first contact with real code are extremely 
>low vs. a spec that reaches CR on the back of several prefixed implementations,
>author feedback etc. 
>
>But this puzzlement is also a consequence of my assuming as a goal that CR should
>be entered once since it also relates to test suite production, dropping prefixes 
>based on IRs etc i.e. a number of final steps on the way to PR and REC.  
>
>It could simply be that CR is overloaded with conflicting intents.

The idea behind Candidate Recommendation is mainly to avoid two things,
vendors shipping implementations based on premature drafts, and dead-
locks, where things are not implemented because the standard is unstable
and the standard is considered unstable due to lack of implementation
experience. This is not a waterfall model, of course implementations are
developed from the very beginning, or in fact even precede the process,
but you have situations like one vendor implements positioning, and the
other vendor implements floats, but nobody implements both, so you get
both to very carefully review the part they do not implement and commit
that it would take extraordinary problems to make major changes.

It may help if you consider that there should only be weeks between the
publication of drafts, including going from Last Call to Candidate Re-
commendation, to Proposed Recommendation, to Recommendation. In the 90s
Working Groups actually had schedules and finished work on standards in
months or at least within the timeframe of the charter. The idea to work
on specifications for several decades is rather new and not a good idea,
by all indications.

The CSS Working Group essentially does not have the two problems Candi-
date Recommendations are meant to address, implementers largely behave
and don't ship some draft implementation as the real thing, and they do
refuse to implement features because the Working Group is not committed
to them yet. The CSS Working Group uses the status as substitute for the
Recommendation status for hygiene reasons. Many years ago some people
bought into the idea that the W3C should publish Recommendations only
when the standard is dead, when there is a perfect test suite for a per-
fect specification and all implementations are similarily perfect. It
turns out that the perfect is the enemy of the good, so Candidate Re-
commendation now is when things are "good enough", and without pressure
to do so, nobody invests resources into moving it past "good enough",
which is why the CSS Working Group has around 50 specifications on its
plate, but only 3 of them ever made it to Recommendation status, and
those three haven't really changed in over a decade.

The Web Applications Working Group is quite similar, it has around 30
specifications and produced only 2 Recommendations in over six years.
They recently had an argument about not being hasty in moving a speci-
fication to Candidate Recommendation status. That specification is over
a decade old and went through as many as five Last Calls and there will
be a sixth some day as a result of the argument.

What is the point, really, in having multiple implementations, then go
to Candidate Recommendation, everybody drops the prefixes, and then see
if anyone bothers writing a test suite? At that point it's too late for
the test suite to uncover problems that could then be fixed as part of
the standardization process. If problems are found, they most likely
come from the real world, with authors actually running into problems,
and then you'd address them in an errata mode with reluctance to make
major changes because such changes would likely break things, just as
would be the case if the Working Group had published a Recommendation
instead.

The process isn't going to make sense so long as people ignore what the
Process is actually there for.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 30 November 2011 18:59:09 UTC