Re: spec development process was: vendor prefixing

It is also worth noting that many external specification publishing
organizations are, under normal circumstances, prevented from making
normative reference to non-final (read less than REC status) documents.
When there have been significant delays, some organizations have been
forced to make exceptions to this process, and have ended up normatively
referencing CRs and even WDs. Ultimately, this produces interoperability
problems and barriers to both the user and the producer of such specs.

I would suggest that a policy that moves a spec as quickly as possible to a
final REC status, and then moves on to a new version of that spec (for
future work), would best serve the interests of the community of spec users
while providing freedom to the WG to innovate in a new version.

Prolonging completion serves no useful purpose.

Regards,
Glenn

On Wed, Nov 30, 2011 at 11:58 AM, Bjoern Hoehrmann <derhoermi@gmx.net>wrote:

> * 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/
>
>