Re: [HTMLWG] CR Exit Criteria redux

On Sep 25, 2012, at 7:20 AM, Adrian Bateman <adrianba@microsoft.com> wrote:

> On Thursday, September 20, 2012 9:37 PM, Maciej Stachowiak wrote:
>> Note that both of these examples are likely to be scenarios we actually face for at
>> least some of our specs, not just hypothetical edge cases.
>> 
>> Boris, Adrian, others, do any of you have suggestions for a form of "endorsement by
>> implementor" that would give clear answers to these problem cases?
> 
> We're talking about an implementer submitting an implementation report for passing specific
> test cases. For multiple people contributing to a common library, ultimately someone takes
> that library and packages it into an implementation that can pass the test case. Anyone that
> does this can endorse their implementation. Just like the criteria that deal with how
> independent certain implementations are there needs to be some judgement used. For two
> products working together, assuming both are necessary to pass the test case, then I think
> either should be able to submit a passing implementation (and again judgements of independent
> may come into play with the second passing test - does it use the same browser engine and if
> so is that a problem?)

Do you think a third party should not be allowed to submit an implementation report at all, even for final shipping versions? I expect neither Freedom Scientific nor Mozilla are likely to submit the Mozilla+JAWS combination as an implementation of longdesc, but I think it is highly likely a third party would want to do this. I don't think there should be a hard rule preventing this. Maybe an alternative of one month of availability *or* implementor endorsement would work,

> 
> I'm not yet convinced that it is a good idea to conflate determining that the spec is of
> sufficient quality to support independent interoperable implementation with determining
> that the feature is compatible with the existing web. Those seem like distinct problems,
> the latter one being approached differently by different organisations and with different
> tolerances to incompatibility.

My sense is that the "two interoperable implementations" requirement is meant to serve a two purposes:

(1) Make sure the spec is clear enough that two independent implementations interpret it the same way.
(2) Make sure the spec is in fact implementable.

"Implementable" could be interpreted in several different ways. But I think it has to include some aspect of "practically implementable". For example, if the parsing algorithm was perfectly clear but could only be implemented with time complexity of O(N^2) in the size of the document, that would not be practically implementable. Similarly, it seems that a number of WG participants feel that "significantly incompatible with existing Web content" is an important consideration to determining if something is practically implementable.



Taking all the feedback from you, Boris and Henri together, how about this version:

== 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, or be endorsed by their responsible organization as sufficiently stable. (3) is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward). (4) is suitable for a person to use as his/her primary means of accessing the Web.

Received on Tuesday, 25 September 2012 15:33:21 UTC