Sent from my iPhone On Sep 5, 2011, at 1:50 AM, Marcos Caceres <marcosscace...@gmail.com> wrote:
> > > On Monday, September 5, 2011 at 5:53 AM, Ian Hickson wrote: > >> Anyway, my point was just that Philippe's statement that an "editor's >> draft" has "no special status" is false, and I stand by this: editors' >> drafts are the most up-to-date revisions of their respective specs. Since >> TR/ drafts are snapshots of editors' drafts, it would be impossible for a >> spec on the TR/ page to be more up-to-date than the latest editors' spec. >> At most, it would be _as_ up to date, and that only if the editors stopped >> work after the TR/ page copy is forked. > I strongly second Ian's arguments, which are just the tip of the iceberg. > > Direct consequences from not giving Editor's draft authoritative status: > > * Implementers start implementing outdated specs, then point to dated spec as > "authoritative" because it's in TR. On the contrary, but still supporting your point, as an implementer I always reference editor's drafts as the authoritative source given they are most up-to-date. This could be considered bad practice analogous to pulling WebKit from trunk and shipping it with a production product and hoping no bugs show up; the draft in an "unratified" state has the luxury to change itself around, voiding any implementation's "to-spec" status. But I live dangerously ;) However, based on what I'm reading here, that may be a good thing. It sounds like editor's drafts are the latest version of an iterative enhancement (in a perfect world at least) and thus have some "safeness" to referencing or even experimentally implementing them; that is, not a lot has the potential to be reverted after implementations have occurred. If that's the case, they ought to receive some normative status. Not all implementers may follow this process, though most I encounter do reference bleeding edge quite often. It's a game of "who can have the latest and greatest first and the best". > * Implementers document developer documentation against (out)dated specs. > * Implementers/other standards bodies get confused about status (e.g., think > that LCWD is < CR). > * Blogs, news sources, and even other specs point to outdated documents > through dated URLs. > * Search engines bring up the wrong "dated" version of a spec. > > I'm sure I'm not alone in seeing extreme fragmentation as a direct result of > the broken W3C process. An increasing number of editors are citing the > Editor's drafts as the sole authoritative source for specs: I ask that the > W3C acknowledge this (best) practice and give working groups the ability to > choose what model they wish to use. The current model is clearly and > evidently and extremely harmful to standardization of technology that is done > in the open. > > > >
