Re: Snapshots

On 10/04/2014 11:34 AM, Brian Kardell wrote:
> On Fri, Oct 3, 2014 at 7:03 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On 10/03/2014 03:53 PM, Chris Wilson wrote:
>>>
>>> Yes, I think that's helpful; they're not currently binding in any way,
>>> and they don't really indicate "consensus" (unless "ready for
>>> implementation" really means "we all talked it out, hugged, and we think
>>> it's good now."  There should also be a status that says "this is baked,
>>> done, shipped, and is incredibly unlikely to change."  (AKA really
>>> long-term normative).
>>
>>
>> Even that's not complete.  There also should be a status for: (1) not yet
>> widely reviewed, (2) one or more implementers tried to implement this, and
>> decided to pull it, but it remains in the spec, (3) authoring advice that is
>> widely ignored as the authors that ignore it find the results to be useful.
>>
>> I can provide examples of each of these categories, and suggest many more
>> categories, but that will quickly go off topic; instead I will suggest that
>> the right 80/20 balance is struck with two documents types:
>>
>> Working Drafts: for those that can tolerate change, but want to see the
>> likely future direction, and ideally want to comment on it and influence the
>> direction.
>>
>> Recommendations: as Chris said "this is baked, done, shipped, and is
>> incredibly unlikely to change."
>>
>> At the moment, the WHATWG is focused primarily on the first type, and yet
>> people are asking why the documents that they produce can't be treated like
>> Recommendations; where the obvious answer is that the specific specification
>> in question doesn't meet that bar.
>>
>> In the recent past, this has been addressed by co-branding a number of
>> specifications once they reach the point where they are "baked, done, etc.".
>>
> I think that perhaps we're talking past one another.  I mentioned
> statuses on sections, this is considerably more granular.  To
> illustrate, have a look at
> https://html.spec.whatwg.org/multipage/forms.html#number-state-(type=number)
> and the corresponding
> http://www.w3.org/TR/html5/forms.html#number-state-(type=number).
> Note in the WHATWG version on the right (at least on a desktop) there
> is a thing listing implementation status and related bugs.  This is
> sort of one of the key issues as I see it, that some specs are very
> substantial and we gain progressive agreement - I don't think that
> there is any spec (unless it was something really basic like beacon
> maybe) which is just 'implemented'.  Often, "specs" (I'll explain the
> quotes) like HTML have many features of varying degrees of
> agreement/usefulness.  I say specs because it's not limited to drafts
> or REC or anything else - in practice it is just a true statement that
> there are features even in RECs which are actually not implemented
> anywhere - or are universally implemented in disagreement with the
> spec.
>
> The aim of a standard is wide implementation and interoperability -
> and reference.  Developers need to be able to look at a spec and get a
> sense of what's what, I'd offer than any AC reviewing the spec for
> progress really should have the ability to do the same in order to
> make sensible decisions and that, it's just generally helpful for a
> whole number of reasons.  I'd personally like to see W3C attempt an
> easy way to track like this.

I'll try to restate what I meant in a different way.

In W3C terms, when a specification is on a Recommendation track, and 
nears Candidate Recommendation status, I'll agree with you and Chris 
that information such as what you describe is indeed useful.  I'll also 
agree with Chris that this information is not complete.

For specifications that aren't quite mature (and this includes many 
Editor's working drafts and some Living Standards), that data doesn't 
capture a complete picture.

- Sam Ruby

Received on Saturday, 4 October 2014 16:05:40 UTC