Two interoperable implementations rule

[Brendan Eich]

On Jul 11, 2008, at 3:01 PM, Maciej Stachowiak wrote:

>
> On Jul 10, 2008, at 6:29 AM, OpenStrat at aol.com wrote:
>
>> In a message dated 7/10/2008 3:03:12 A.M. Eastern Daylight Time,  
>> mjs at apple.com writes:
>> I do not believe that ECMA has the "two interoperable  
>> implementations"
>> rule that the IETF and W3C have, but since ECMAScript is a  
>> standard of
>> equal important to the Web, I think we should adopt this rule for any
>> future edition of ECMAScript. Such a rule is needed precisely to  
>> avoid
>> such casual breakage relative to Web reality. Can we make that a
>> binding TC39 resolution?
>> While it is true that no such rule exists in Ecma, it has been  
>> used in work I am familiar with (optical storage) within TC 31.   
>> Early work on MO storage resulted in TC 31 agreeing that at least  
>> two implementations must demonstrate interoperability before  
>> approval of the standard.  This meant that both disk manufacturers  
>> and drive manufacturers had to work together to demonstrate that  
>> the product resulting from the standard would work together.  The  
>> committee always followed this rule without question, and the CC  
>> and GA of Ecma did not interfere with its implementation.
>>
>> We can add this subject to discussion at Oslo, but this is a  
>> question that I would put to an internal vote of TC 31 since it  
>> has wider impact than may be represented in Oslo.
>
> Since there is precedent within ECMA, then I definitely think we  
> should take a formal vote on adopting this rule for TC39, in  
> particular that we must have two interoperable implementations for  
> any of our specs before it progresses outside our committee.
>
> There are also some details to be worked out:
>
> 1) Is "two interoperable implementations" at feature granularity,  
> or whole spec granularity? In particular, is it ok to cite two  
> implementations for one feature, but two other implementations for  
> another?
>
> 2) How is interoperability to be demonstrated? Do we accept good- 
> faith claims of support, or do we need a test suite?
>
> Given the nature of programming languages and the high stakes of  
> Web standards, I would personally prefer whole-spec granularity  
> (different implementations having different mixes of features does  
> not prove real interoperability), and a test suite rather than just  
> bare claims of support.
>
> To be clear, I propose this rule not to block ES3.1, but to make it  
> successful. The WebKit project will accept patches for any feature  
> of 3.1 that  has been reconciled with 4, and we will likely devote  
> Apple resources to implementing such features as well, so  
> SquirrelFish will likely be a candidate for one of the  
> interoperable implementations. Mozilla also has an extensive test  
> suite for ECMAScript 3rd edition, which could be a good starting  
> point for an ES3.1 test suite.
>
> I also note that the strong version of the interoperable  
> implementations rule will be an even higher hurdle for ES4.
>
> Any comments?

You don't need another huzzah from me.

The hurdle is certainly higher for ES4, although it may be less high  
given its reference implementation, which could pass the tests.  
Should a reference implementation, even if slow, count?

Of course tests are never complete, but we need not pretend they are  
to have confidence in interoperation. I am interested in real  
programmers banging on "draft" implementations, which will produce  
bug reports beyond what tests find, and lead to more tests being  
developed.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080711/c26fdc73/attachment-0002.html