Re: CR exit criteria and features at risk for HTML5

FWIW: I'm personally happy to go with the permissive version.
Cheers,
Silvia.

On Wed, Aug 15, 2012 at 9:43 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Hello Working Group,
>
> To make a realistic estimate of the REC date for HTML5, we need to determine the CR exit criteria and set of features at risk for HTML5 (and related specs). The W3C Process recommends two interoperable implementations of every feature, but is not very specific in how this is to be determined.
>
> To kick off the discussion, I'd like to present for your consideration two different proposed versions of CR exit criteria, and approaches to choosing "at risk" features. The Chairs and Team Contacts agree that the "strict" version below is likely to lead to a CR period of 5-6 years (~3 years from CR to create a comprehensive test suite, 2-3 years from there to pass it. We also agree that the "permissive" version is likely to lead to a CR period of 1-2 years, largely because it does not require any additional test suite or implementation work to exit CR.
>
> We have been advised by the Team that the Director is likely to reject a request for advancement to CR that contains the "strict" criteria as-is. W3C Management feels strongly that getting to REC quickly is essential, and more important than creating an extensive test suite or proving interoperability in detail. Nevertheless, it is the prerogative of the Working Group to choose what CR exit criteria to propose to the Director. The Team strongly urges something more like the permissive version. Also, the "strict" and "permissive" versions below can be seen as two endpoints on a continuum; perhaps the WG will favor a middle ground approach.
>
> The Chairs are eager to hear the WG's input.
>
> === Key differences between the versions
>
> (1) The strict version requires passing a comprehensive test suite to prove interoperability of each feature. The permissive version makes it a qualitative judgment call.
> (2) The strict version requires that implementations used to prove interoperability must be public, but must not be experimental (they can be betas, nightlies, developer previews or the like); the permissive version allows non-public or purely experimental implementations to be cited.
> (3) The strict version would mark at risk any feature that lacks two reasonably complete (if not necessarily fully interoperable) implementations; the permissive version would mark at risk any feature that is not already judged interoperable at a qualitative high level.
>
>
> === Strict version
>
> For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:
>
> == independent
>
> Each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
>
> == interoperable
>
> Passing the respective test case(s) in the official HTML test suite, or, if the implementation is not a Web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.
>
> == implementation
>
> A user agent which: (1) implements the "Web browsers and other interactive user agents" conformance class of the specification. (2) is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or “nightly build”). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability. (3) is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).
>
> The specification will remain Candidate Recommendation for at least six months.
>
> The following features are at risk: <fill in all features that do not have two reasonably complete implementations on entry to CR>
>
>
> === Permissive version
>
> For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:
>
> == independent
>
> Each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
>
> == interoperable
>
> Qualitatively interoperable at at a judgment level, not necessarily for every spec assertion. A test suite may be used as guidance for the qualitative decision.
>
> == implementation
>
> A user agent which: (1) implements the "Web browsers and other interactive user agents" conformance class of the specification.
>
> The specification will remain Candidate Recommendation for at least six months.
>
> The following features are at risk: <fill in all features that do not already have two qualitatively interoperable implementations on entry to CR>
>
>

Received on Wednesday, 15 August 2012 03:52:43 UTC