Two interoperable implementations rule

[Maciej Stachowiak]

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?

Regards,
Maciej

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