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

Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Steven Olmsted

I was directed to this mailing list from the link at
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:
  • 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:
  • 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.
  • 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,