On Jul 10, 2008, at 6:29 AM, [EMAIL PROTECTED] wrote:
In a message dated 7/10/2008 3:03:12 A.M. Eastern Daylight Time, [EMAIL PROTECTED]
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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
