Re: CR exit criteria and features at risk for HTML5

hi Maciej,

(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.
>

don't like the idea of allowing  " non-public or purely experimental
implementations to be cited."


regards
SteveF

On 15 August 2012 00:43, 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>
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html