Re: Reference to the HTML specification

Hi, Ian-

On 9/3/11 2:54 PM, Ian Hickson wrote:
> On Mon, 29 Aug 2011, Philippe Le Hegaret wrote:
>>
>> But, the WHATWG HTML links to the editor's drafts and does not link to
>> the TR one. While documents on the REC-track should link to other
>> documents on the REC tracks, this doesn't apply to editor's draft, which
>> have no special status anyway. So, you can link to both versions in the
>> editor's draft if you prefer.
>
> Well, the editor's drafts have one special status: they're the most
> correct drafts, unlike the TR/ drafts, which are often obsolete as soon as
> they're published (in the case of the HTML spec, they're obsolete _before_
> they're published, since the publication process takes several days). So
> it's not entirely true that they have no special status.

Let's examine that claim objectively.  Specs define two different 
flavors of behavior: documentation of existing features, and new 
features.  (Sometimes one spec, like HTML5, does both.)

1) Documenting existing behavior:  Here, the specification is attempting 
to define a feature that matches one or more existing implementations 
which are believed to be stable and to have the generally desired 
behavior.  In this case, if the editor's draft in fact matches the 
behavior, the specification is "correct"; however, to determine if the 
spec achieves its goal, you need adequate test cases and implementation 
reports to make sure that all the details are indeed correct.

2) Defining new behavior:  Here, the specification is trying to satisfy 
a set of use cases and requirements that may not yet have a clear 
solution.  This needs not only tests, but the consensus of the group. 
Of course the editor believes it's correct... they wouldn't have 
specified it that way if they didn't.  But sometimes editors have made a 
technical mistake, or informed opinions vary on what the desired 
behavior is.  This is especially unstable, because there is no reference 
implementation that needs to be matched for backwards compatibility and 
interoperability, and there may need to be a period of experimentation 
(in the spec drafts, or in implementations) before a good solution is ready.


It makes sense that you, as an editor, and as someone who wants to 
perpetuate the notion that specs are never stable, should want to give 
special status to your own work, but to claim that editor's drafts are 
"correct" is a gross oversimplification.

Instead, a more credible claim should be that editor's drafts reflect 
the most recent best attempt by the editor.  That's not always stable, 
and it's not always right.


I believe that we should, in general, defer to the editor, because they 
have delved most deeply into the subject matter and are probably best 
informed about the issues (Aryeh wrote a nice essay on this recently). 
However, sometimes a little distance from the subject is also useful, 
because the editor might be too immersed in it to be able to see the 
perspective of the people who will ultimately use the feature.  And in 
any case, if the editor really does know best, they should easily be 
able to describe and justify the feature to the rest of the group.

I also support the idea of a prominent warning to reviewers or 
implementers that a more recent draft is available, and that they should 
refer to that before spending too much energy on the TR draft; I see no 
harm there, and potential a lot of benefit.  But equally, the editor's 
draft should bear the warning that it may not have undergone substantial 
independent review.

Regards-
-Doug Schepers
W3C Developer Outreach
Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs

Received on Monday, 5 September 2011 01:31:03 UTC