Re: CR exit criteria and features at risk for HTML5

On Aug 17, 2012, at 4:32 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Thu, Aug 16, 2012 at 8:22 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> The "strict" version does allow publicly available betas and the like. I'm curious whether anyone supports allowing non-public or experimental builds. I'll also check whether those who suggested this feel strongly about it.
> 
> I think any publicly-available implementation should definitely count.
> If it's interoperable to the level we want, why should we care if the
> implementer doesn't want to release it to all their users yet for some
> reason, or labels it "experimental"?  Even if someone only implemented
> it in a browser extension -- if it's an interoperable implementation,
> it's an interoperable implementation.  The point is just to show that
> it's interoperably implementable based on the spec, so any
> implementation at all is fine.  But we should only count public
> implementations, for the sake of transparency.

The strict criteria have a pretty specific definition of "not experimental". They *do* allow betas, nightlies, developer previews, and other such versions that are not yet released to all users. They *do not* allow versions created solely for purposes of passing the test, and which are not actually intended to ever be part of software that genuinely ships. In other words, it's meant to rule out a completely artificial implementation that is not meant to successfully browse the web at acceptable quality. Basing interop claims on such implementations would mean that we have not shown implementing the spec is feasible for a real product. Quoting the guideline again:


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


Regards,
Maciej

Received on Friday, 17 August 2012 20:16:20 UTC