Comments on Semantic Interpretation for Speech Recognition (SISR) Version 1.0

Hello,

I was directed to this mailing list from the link at
https://www.w3.org/TR/semantic-interpretation/
Thanks for everyone's hard work on this specification.  It seems well
thought out and covers everything necessary to process semantic
interpretation results.  I would however like to share a few things I
thought could be improved in this specification.

There appear to be several typos:

   - 3.3.3.1 Authoring Notes - It mentions properties of meta.rulename().
   In all other examples, meta.rulename is an object.  The parenthesis would
   attempt to call a non-function and throw an error.
   - 7.1 Serialization of an ECMAScript Result into an XML Fragment - The
   first example is missing a comma in the topping array.
   - 7.2 Use of _attributes and _value - The first example is missing
   colons for all the _attributes properties.
   - C Normative References - The link to Standard ECMA-327 gets redirected
   to ECMA-372.  This appears to be a problem with ECMA International's
   website but I figured it was worth reporting here.

There were a couple things I felt were poorly explained:

   - 3.3.2.1 Authoring Notes - The example shows rules.kindofdrink
   containing the value of the rule's text variable.  This is accurate but
   very confusing since default assignment isn't described until section 5.
   It would be better to add tags to the example grammar to avoid using a
   feature that hasn't yet been introduced to the reader.
   - 3.3.3.1 Authoring Notes - It makes special note that text and score
   properties of a referenced rule are not read-only.  If a tag modifies the
   text property of a referenced rule then the next tag reads the text
   property of the same referenced rule, does the second tag get the original
   value or the modified value?  The scoped environment setup rules in section
   6.3.2 don't mention anything about resetting the values of meta.rulename
   for previous rulenames so I assume changes written by one tag will persist
   into the next tag.  I feel like this functionality should be explicitly
   mentioned somewhere.

Finally, there are a few things I would recommend adding or changing:

Section 7 is entirely about generating XML results.  Since the results are
essentially ECMAScript objects, it would make much more sense to generate
JSON results.  Could JSON be added as a recommended alternative result
format?

I like how tag-format semantics/1.0-literals uses simple string values and
how tag-format semantics/1.0 uses ECMAScript Compact Profile but I
recommend adding a third tag-format that uses a full recent edition of
ECMAScript Standard ECMA-262.  The compact profile is great for working
with resource-constrained environments, yet it also poses some
implementation challenges.  Standard ECMA-327 does not appear to be
actively maintained by ECMA and it can be difficult to find good support
for it.  On the other hand, there are many popular and freely available
implementations of ECMAScript Standard ECMA-262 with a large community of
knowledgeable users and an active technical committee dedicated to
maintaining and updating the standard.  It would certainly be more
convenient to implement a system where semantic interpretation tags are
executed with Standard EMCA-262.

I noticed throughout the document, the expression `new Object()` is used to
created empty ECMAScript objects.  These should all be replaced with object
literal notation `{}`.  The reason for this is, a global tag could do
something silly like: Object = null;  Now all of the new Object()
expressions will break but object literal notation will continue working as
expected.  This is an unusual edge case but I think it's worth fixing.
Speech recognition grammars don't generally handle sensitive secret
information, but if for some reason they did, a clever programmer could
potentially replace the Object constructor and find a way to leak secure
data that other grammar developers may not easily notice.

Thanks again,
Steven