RDC: Will the almost-there (hopefully) nuance grammars work on other platforms?

[Stu Robertson <sr...@nvisia.com>]

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

Re: RDC: Will the almost-there (hopefully) nuance grammars work on other platforms?

[Rahul P Akolkar <ak...@us.ibm.com>]

Stu Robertson <sr...@nvisia.com> wrote on 06/13/2005 02:13:11 PM:
<snip/>
> 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? <snap/>

Reminds me of my "if (document.all) then IE else if (document.layers) then 
Netscape else ?Mozilla?" days.

I'm not sure if we can meet the laudable goal of one grammar irrespective 
of platform. In any case, I think there are really two modes of operation 
(and you're refering to the second):
1) Deciding on a platform per deployment of an app
2) Deciding on a platform per request (or session)

The first option is more like a setting or a flag in the app deployment 
descriptor, which causes components to pick up the right grammars for the 
platform. This, I think, will make the cut in most deployments, since the 
browser farm (if there are more than one browsers for load balancing etc.) 
tends to be homogeneous i.e. using the same platform (the browser is 
usually bundled with the platform). Maintaining anything else will be a 
lot of fun.

The current support within the RDC framework allows us to define the 
target platform via the web app descriptor (option 1 above). The app 
itself is platform agnostic, a particular deployment binds it to a 
platform. I'm not sure if this is the right time to go do (2), or if its 
even needed.

> 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?

Maybe, but I'm hoping you'll figure out your Nuance grammar question so we 
won't have to :-)

-Rahul