On Jul 11, 2008, at 3:01 PM, Maciej Stachowiak wrote:
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?
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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
