MITRE comments on Semantic Interpretation WD

MITRE Comments on Semantic Interpretation for Speech Recognition
W3C Working Draft dated 16 November 2001


For us, the problems begin in section 1.3, "Why not simply use
ECMAScript". We find this section unconvincing, and all the other
problems with the document follow from it.

Section 1.3 identifies "concerns on performance and other implications
from using ECMAScript", but does not flesh them out in any way that
would allow the reader to evaluate the validity of the authors'
conclusion. Furthermore, at least one of the topics of concern,
namely, performance, can only be based on the shortcomings of current
implementations of ECMAScript, which isn't an appropriate basis on
which to make a decision about a forward-looking standard. (If it's
based on performance problems with ECMAScript IN PRINCIPLE, then ECMA
has a real problem, and so do all the browsers that rely on it, and we
can't believe that that's the case.)

In any case, let's call the version described here ES-prime.

In addition to not being convinced by the motivations for choosing
ES-prime over ECMAScript, we also don't believe that the limitations of
ES-prime are realistic. For instance, ES-prime doesn't have
conditions. However, one could easily imagine a context in which we
wanted to standardize a value on some parent node, which depended
conditionally on the values of the children. It's possible that some
of these cases might be addressed by exploding the grammar itself, but
that's not necessarily an appropriate strategy from the point of view
of maintainability.

Finally, we have to object to the draft's explicitly choosing a
scripting language. In HTML, you can choose your scripting language;
why can't you do so in this specification?

As a result, we do not believe that the draft should be defining yet
another scripting module, which looks like ECMAScript but has
different scoping rules. We believe that the specification ought to be
agnostic about the choice of scripting language, but if that's not
possible, the group ought to be choosing ECMAScript over ES-prime, or
needs to be far more explicit about their decision not to do so.

The remainder of the document does a nice job of illustrating the
details of the specification, but suffers from the fact that the
decision to deviate from ECMAScript is not sufficiently justified in
section 1.3. As with the VoiceXML 2.0 specification, this draft
appears to be exercising a great deal of effort to define a
programming language, when the fact is that many other groups whose
job it is to design programming languages have spent a great deal more
time doing a cleaner job. While we respect the amount of effort
invested in this document as well as the VoiceXML 2.0 document, we find
it to be misguided.

Samuel Bayer
John Aberdeen

The MITRE Corporation

Received on Thursday, 20 December 2001 13:40:39 UTC