Nuance seems to support a very old version of the SRGS
specification. While we don't even have it completely working yet,
it looks like something like the following is what's going to be the
answer:
<rule id="numbers" scope="public">
<item>
<ruleref uri="#gathernumbers"/>
<tag> compatibility=$return </tag>
</item>
</rule>
<rule id="gathernumbers">
<item repeat="1-50">
<item><ruleref uri="#digit"/>
<tag>assign(a strcat($a strcat(" " $return)))</tag>
</item>
<tag> return($a) </tag>
</item>
</rule>
...and the #digit rule is the same as it was before.
I think the SRGS specification no longer uses this "compatibility=
$return" syntax for tags though. If that's the case, will still end
up with divergent grammars for different voice interpreters. At
least until Nuance decides it's time to implement the 15 month-old
recommendation (what's up with that, anyway?).
If that's the case, I think we'll need some simple browser sniffing.
We could recognize when a nuance interpreter is making the request,
and serve it nuance-compatible grammars that are equivalent to the
standard ones. While this is obviously what the SRGS spec is trying
to avoid, are we stuck with this in the meantime?
If the answer is yes, and it turns out nuance's SRGS flakiness makes
using their outdate implementation too difficult, what do you think
about making that special nuance grammar their proprietary GSL?
Stu
