Two interoperable implementations rule
mjs at apple.com
Fri Jul 11 15:01:26 PDT 2008
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
> 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss