W3C home > Mailing lists > Public > public-html@w3.org > August 2012

Public Permissive proposed CR exit criteria (was Re: CR exit criteria and features at risk for HTML5)

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 18 Aug 2012 14:39:24 -0700
Message-id: <969F79FC-FF55-4B2D-B345-550308E8FD48@apple.com>
To: "public-html@w3.org WG" <public-html@w3.org>

Based on the discussion so far, I think most of the WG would support the following "Public Permissive" criteria. These allow a permissive definition of interoperability, like the previous "Permissive" version, but require all interoperability claims to be based on public, non-experimental versions, as with the previous "Strict" version.

I would estimate that this set of CR exit criteria will lead to a CR period of 1-2 years, just a with the "Permissive" version. Both "Permissive" and "Public Permissive" assume that we enter CR with the CR exit criteria already met, modulo removal of at-risk features. So they would lead to very similar timelines.

The one possible difference is that "Public Permissive" may lead to somewhat more "at risk" features being dropped. This would occur if a feature had two judgment-level interoperable implementations, but one of them was a non-public version, or a purely experimental version created solely to show interoperability. In this case, the "Public Permissive" criteria would say to drop the feature, while the "Permissive" criteria would say to keep it.

My impression is that the WG overall would prefer this version to either the "Permissive" or "Strict" versions, with possible exceptions.

Comments welcome.


=== Public 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. (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 already have two qualitatively interoperable implementations on entry to CR>.
Received on Saturday, 18 August 2012 21:39:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:33 UTC