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
factor: 
http://docs.webplatform.org/wiki/WPD:Proposals/spec_status_representation.
We even talked at one point about providing a UI distinction based on if
something was production-ready or not
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=20387).

Thanks.

Julee
----------------------------
julee@adobe.com
@adobejulee





-----Original Message-----
From: "Michael Champion   (MS OPEN TECH)" <Michael.Champion@microsoft.com>
Date: Friday, February 15, 2013 9:18 AM
To: Tobie Langel <tobie@fb.com>, Robin Berjon <robin@w3.org>
Cc: julee <julee@adobe.com>, "public-webplatform@w3.org"
<public-webplatform@w3.org>
Subject: RE: How should we represent the status of a spec?
Resent-From: <public-webplatform@w3.org>
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; public-webplatform@w3.org
>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
>>subject.
>>
>> 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.
>
>--tobie
>
>
>
>
>

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