RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

>-----Original Message-----
>From: es-discuss-bounces@mozilla.org [mailto:es-discuss-
>bounces@mozilla.org] On Behalf Of Yehuda Katz
>
>Another way to put my earlier concern is: It's impossible to write a
>conforming JS engine that browsers will want to use by only following
>the ES spec - since there's additional, un-speced, behavior that isn't
>in ES that is necessary in order to construct a browser's DOM.
>
>Consider the following scenario: I write an ECMAScript engine that is
>significantly faster than any existing engine by simply following the
>ECMAScript spec. A browser maker then wishes to use this engine. This
>would be impossible without adding additional (hidden) features to the
>engine to support the DOM. There is nothing in the ECMAScript spec
>that requires the ability (at the very least) to add native extensions
>with arbitrary behavior to the engine.
>
>Is this a requirement ECMA is comfortable with?
>

No we are not.  This is exactly the heart of our concern. The WebIDL
ECMAScript binding is not simply a mapping of IDL interface onto
standard language features (such as is done for the Java binding).
While it has some of that it also defines an extended ECMAScrpt language
with new semantics. (and I understand this is mostly a reflection
of past (present?) practice of browser implementers).  Essentially,
the semantics of "browser ECMAScript" has been arbitrarily split into
two independently maintained standards. 

Language design is not primarily about designing individual isolated features.
The hard parts of language design involves the interactions among such
features and typically requires making design trade-offs and alteration to
ensure that all features compose coherently.

If the language specification responsibilities are arbitrarily broken into 
two uncoordinated activities then it is impossible for either to do
the global design that is necessary to have a complete and sound language and
specification.

TC39 has the language design expertise.  W3C has Web API design expertise.
If there are language design issues that must be addressed in order to fully
specify "browser ECMAScript" (and there are) then those issues need to be
addressed by TC39. Perhaps TC309 has been remiss in the past in addressing
these browser specific language design issues.  If so, it was probably for
historic political and competitive reasons that don't necessarily apply today.
That is what we want to fix.

Allen Wirfs-Brock
Microsoft

Received on Saturday, 26 September 2009 15:29:30 UTC