Re: How should we represent the status of a spec?

This is all great! Thanks for the clarity in your distinction between a &
b, below, Michael. We did discuss needing to provide both types of status
for an accurate picture.

While you all are discussing a technical solution I hope usability can
remain in the forefront. Visitors include standarnistas, testers, and so
on. But a large proportion of users need to know whether the element can
be used in production or not. Chris's proposal provides that usability
We even talked at one point about providing a UI distinction based on if
something was production-ready or not



-----Original Message-----
From: "Michael Champion   (MS OPEN TECH)" <>
Date: Friday, February 15, 2013 9:18 AM
To: Tobie Langel <>, Robin Berjon <>
Cc: julee <>, ""
Subject: RE: How should we represent the status of a spec?
Resent-From: <>
Resent-Date: Friday, February 15, 2013 9:21 AM

>+1 to Tobie's points, with some caveats:
>There are at least two types of status different audiences need to track
>a) Status of the spec as it moves toward standardization, and how well
>tests against the *spec* indicate that it is clear enough to be
>independently implemented
>b) Status of the implementations of the spec -- what percentage of
>deployed platforms claim to implement it, and how interoperable those
>implementations are in practice.
>To put it another way:  there are multiple ways to get interoperability
>-- write a spec that is so clear that everyone can implement it without
>looking at other implementations, or to start from the code (or reverse
>engineer the bits on the wire) of some de facto reference implementation.
> W3C's testing  focuses on the first, but the real-world interoperability
>of technologies that aren't yet standardized often comes from a
>combination of specs, shared code, and reverse engineering.  End users
>who just want to know "can I use this feature with confidence" don't
>particularly care how the feature got to be interoperable, and they don't
>particularly care if a spec is good enough if it's not widely implemented
>in the real world.
>The infrastructure for storing/publishing the two types of data can
>almost certainly be shared, but there may be significant differences in
>how the data are collected. In either case, we should TRY to minimize the
>number of judgment calls / political decisions between the raw facts and
>the presented data.
>From: Tobie Langel
>Sent: Friday, February 15, 2013 5:01 AM
>To: Robin Berjon
>Cc: Julee;
>Subject: Re: How should we represent the status of a spec?
>On Friday, February 15, 2013 at 1:54 PM, Robin Berjon wrote:
>> On 15/02/2013 10:00 , Tobie Langel wrote:
>> > Maybe we should start having a cross-project conversation on the
>> I'm all for that, but I want to make sure that we don't force ourselves
>> to shoehorn all the various ways of representing spec status into a
>> single unified one if it turns out not to fit.
>Absolutely. There are different audiences are interested in different
>types of status (e.g. publication status, test status, implementation
>status, etc).
>Of course there is some overlap.
>However--and that's the part I'd like us to focus on--storing, accessing,
>updating this information requires the same infrastructure, and it would
>be a shame to not consider centralization, here.

Received on Friday, 15 February 2013 18:46:57 UTC