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

--001a1140e4ded606e6053937f47d
Content-Type: text/plain; charset=UTF-8

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

--001a1140e4ded606e6053937f47d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hello,<br><br></div>I was directe=
d to this mailing list from the link at <a href=3D"https://www.w3.org/TR/se=
mantic-interpretation/">https://www.w3.org/TR/semantic-interpretation/</a><=
br>Thanks for everyone&#39;s hard work on this specification.=C2=A0 It seem=
s well thought out and covers everything necessary to process semantic inte=
rpretation results.=C2=A0 I would however like to share a few things I thou=
ght could be improved in this specification.<br><br></div>There appear to b=
e several typos:<br></div><ul><li>3.3.3.1 Authoring Notes - It mentions pro=
perties of meta.rulename().=C2=A0 In all other examples, meta.rulename is a=
n object.=C2=A0 The parenthesis would attempt to call a non-function and th=
row an error.</li><li>7.1 Serialization of an ECMAScript Result into an XML=
 Fragment - The first example is missing a comma in the topping array.</li>=
<li>7.2 Use of _attributes and _value - The first example is missing colons=
 for all the _attributes properties.</li><li>C Normative References - The l=
ink to Standard ECMA-327 gets redirected to ECMA-372.=C2=A0 This appears to=
 be a problem with ECMA International&#39;s website but I figured it was wo=
rth reporting here.<br></li></ul></div></div>There were a couple things I f=
elt were poorly explained:<br><ul><li>3.3.2.1 Authoring Notes - The example=
 shows rules.kindofdrink containing the value of the rule&#39;s text variab=
le.=C2=A0 This is accurate but very confusing since default assignment isn&=
#39;t described until section 5.=C2=A0 It would be better to add tags to th=
e example grammar to avoid using a feature that hasn&#39;t yet been introdu=
ced to the reader.</li><li>3.3.3.1 Authoring Notes - It makes special note =
that text and score properties of a referenced rule are not read-only.=C2=
=A0 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 ta=
g get the original value or the modified value?=C2=A0 The scoped environmen=
t setup rules in section 6.3.2 don&#39;t mention anything about resetting t=
he values of meta.rulename for previous rulenames so I assume changes writt=
en by one tag will persist into the next tag.=C2=A0 I feel like this functi=
onality should be explicitly mentioned somewhere.</li></ul>Finally, there a=
re a few things I would recommend adding or changing:<br><div><br>Section 7=
 is entirely about generating XML results.=C2=A0 Since the results are esse=
ntially ECMAScript objects, it would make much more sense to generate JSON =
results.=C2=A0 Could JSON be added as a recommended alternative result form=
at?<br><div><br></div><div>I like how tag-format semantics/1.0-literals use=
s simple string values and how tag-format semantics/1.0 uses ECMAScript Com=
pact Profile but I recommend adding a third tag-format that uses a full rec=
ent edition of ECMAScript Standard ECMA-262.=C2=A0 The compact profile is g=
reat for working with resource-constrained environments, yet it also poses =
some implementation challenges.=C2=A0 Standard ECMA-327 does not appear to =
be actively maintained by ECMA and it can be difficult to find good support=
 for it.=C2=A0 On the other hand, there are many popular and freely availab=
le implementations of ECMAScript Standard ECMA-262 with a large community o=
f knowledgeable users and an active technical committee dedicated to mainta=
ining and updating the standard.=C2=A0 It would certainly be more convenien=
t to implement a system where semantic interpretation tags are executed wit=
h Standard EMCA-262.<br></div><div><br>I noticed throughout the document, t=
he expression `new Object()` is used to created empty ECMAScript objects.=
=C2=A0 These should all be replaced with object literal notation `{}`.=C2=
=A0 The reason for this is, a global tag could do something silly like: Obj=
ect =3D null;=C2=A0 Now all of the new Object() expressions will break but =
object literal notation will continue working as expected.=C2=A0 This is an=
 unusual edge case but I think it&#39;s worth fixing.=C2=A0 Speech recognit=
ion grammars don&#39;t generally handle sensitive secret information, but i=
f for some reason they did, a clever programmer could potentially replace t=
he Object constructor and find a way to leak secure data that other grammar=
 developers may not easily notice.<br><br></div><div>Thanks again,<br></div=
><div>Steven<br></div></div></div>

--001a1140e4ded606e6053937f47d--