Voxeo Developers Corner

For our last certified tech-tip, we explored the older SISR-formatted returns that one can use when designing a recognition grammar for a VoiceXML application. For this week, we will tackle two different things related to SISR grammars when using the Prophecy 8 software:1 – How to use the newer SISR “.out” grammar return syntax2 – How we can craft a subgrammar returning multiple slot valuesIt would seem as if the second item is pretty elementary, but it does bear a little bit of illustration, especially in terms of how the values in the sub-rules will bubble up to the top-level return. For the sake of simplicity, we will do a much-simplified month/day grammar that contains a single entry. One you grasp the syntax, you can easily flesh this out more fully to include all possible months & days, or even overhaul it into a first-name & last-name grammar.Let’s take a peek at the grammar file itself, and then look at the relevant working parts: <?xml version= “1.0″?>

</grammar> The grammar above consists of two sub-rules titled “MONTH” and “DATE”, and we have a single top-level rule titled “TOPLEVEL”. The sub-rules each specify a month and day slot respectively, and these slots will bubble up to the to-level when we invoke the syntax that we have below:

<ruleref uri=”#SUBRULE”> <tag>out.slotname.SUBRULENAME.subslot;</tag>

And we then reference these various slots within the VoiceXML as follows:

<log expr=”‘*** SLOT RESULT = ‘ + lastresult$.interpretation.slotname”/>

We also threw in a quick example of using the “out” syntax in a more generic manner for our “yearslot” value. In this case, it simply allows us to return a year value back to the VoiceXML from the top-level rule as opposed to having to reference the sub-rule values.This is added in to show how a “flat-file” non subgrammar can return a slot value using the newer SISR syntax that follows this format:

<tag>out.slotname;</tag>

So when using our month/day grammar above, one might still be unclear on how we get at all these slot values within the VoiceXML dialog. Once recognition has occurred, we would specify something like this:

<log expr=”‘*** YEAR RESULT = ‘ + lastresult$.interpretation.yearslot”/>

<log expr=”‘*** MONTH RESULT = ‘ + lastresult$.interpretation.monthslot”/>

<log expr=”‘*** DAY RESULT = ‘ + lastresult$.interpretation.dayslot”/>

Eventually, we will get around to creating some fully fleshed-out additions to our VoiceXML documentation on the subject of SISR grammars, but until then, we will post any cool tricks and tips here for the edification of our developers. As always, if heres anyone who’d like to see a posting, or techtip on a particular subject, just drop us a line, and we would be happy to accommodate.Next TechTip: Using SSML markup within a CallXML 3.0 application. Stay tuned to the blog; this next one is really cool.

~Matthew Henry

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

I am happy to announce a new semi-regular addition to the Voxeo blog, where the Voxeo Support team will be adding VoiceXML, CallXML, and CCXML tips, tricks, and best practices for our developers, which we will christen as “Certified Tech Tips”. The name has a nice ring to it and all, but this isn’t just for show: 100% of the technical support team are certified VoiceXML developers, and we are pretty proud of being the only provider who holds these standards.

As we devise some really inventive means of achieving project goals & cool functionality when coding in the framework of these various IVR markups, we thought that we might share some of these tips to our readers of the Voxeo Blog.

For those who haven’t interacted with the support team yet, a bit of introduction is in order. My name is Matthew Henry, and serve as the Director of Customer Support here at Voxeo. I have been with the company since it’s inception (way back in the 20th Century), and have been lucky enough to work with a sizable number of really talented IVR developers and engineers, which has allowed me to learn a lot, and has also allowed me to build up a respectable code library for all things IVR. And now, it’s time for some payback.

=^)

As our maiden posting to the Voxeo blog, we will cover the topic of Semantic Interpretation for Speech Recognition-formatted grammar returns when using the Prophecy 8 software. A lot of folks are used to using plain-old Nuance GSL grammars due to it’s ease of use and concise markup, but the drawback of using this approach is pretty fundamental: As GSL is Nuance-specific, it isn’t guaranteed that every provider will support it. And those of us who have written complex grammars know that porting a grammar can be a tedious job to take on. For this reason, we always suggest that folks stick with a W3C standard when writing grammars, that being using the SRGS XML-based grammar format that leverages the SISR syntax to populate our grammar interpretations back to the VoiceXML dialog. Most of the documentation on our site references using the Nuance-specific return formatting, and today we will show you what a 100% w3c compliant grammar looks like.

To start things off, let’s take a look at some GSL, and some SRGS with Nuance-specific returns for the sake of comparison:

Simple GSL

MYRULENAME [
[utterance]      {<mySlotName  "my return value">}
]

Simple SRGS with Nuance-returns

<?xml version= "1.0"?>
    <grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US" 
        root = "MYRULENAME">
      <rule id="MYRULENAME">
        <one-of>
          <item> 
   	       utterance
	       <tag> <![CDATA[  <mySlotName "my return value"> ]]>  </tag> 
          </item>
        </one-of>
      </rule>
    </grammar>

Simple SRGS with SISR returns

<?xml version= "1.0"?>
    <grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US" 
          root = "MYRULENAME">
      <rule id="MYRULENAME">
        <one-of>
          <item>
               utterance
	       <tag>$.mySlotName = "my return value"</tag> 
	  </item>
        </one-of>
      </rule>
    </grammar>

The differences in syntax are fairly self-evident in these cases. In the case of SISR, the “$.” prefix allows us to specify any slotname that we will return to our VoiceXML dialog, and specifying a quoted interpretation value preceded by an ‘equals’ sign links the value to this slot.

In addition, we can also specify a “generic” return where no slotname is specified (which comes in handy for subgrammars) by putting $=”my return value” within the . If we want to get really fancy, we can even specify multiple slots to return back to the dialog by inserting a “;” delimiter between the slot/interpretation pairing. A sample multislot return with an “anonymous” slot also defined might look something like this:

<item> 
    utterance 
    <tag>
    $ = "my anonymous slot value"; 
    $.mySlotName1="my slot 1 return";	 $.mySlotName2="my slot 2 return";
    </tag> 
</item>

As you can see, the SISR returns are much more concise, easy to read, and much more lightweight than Nuance-specific returns. And once you write a grammar using SIRGS and SISR, then any Certified Compliant VoiceXML platform will run these grammars without any porting at all being required.

If you found this posting useful, then let us know! Mayhap we will dig deeper into this the next time, and whip out some more complex subgrammars to better illustrate the usage of SISR formatting within your IVR applications.

Till next time!
~Matthew Henry

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.