Video Transcription

Syntax and String Literals

Getting Started with SISR

Types of SISR

SISR is a recommendation by the W3C that was adopted in April 2007 as version 1.0. It is significantly different from earlier drafts. This current version of SISR gives you two basic options:

• String Literals
• SI Script (we will cover this in the next video)

Basics & Syntax

Tags: Basic unit of SISR. Inside of a tag is SI information.

• <tag></tag> in GrXML
• {} curly braces in ABNF
• Each tag gets put into a rule

Rule Variables: Each grammar rule has a variable. The rule variable stores SI information for the rule. The Engine returns the variable for the root rule.

String Literals

String literals are very simple. The information inside SISR tags is returned as a string. To use this, you must specify the tag-format as semantics/1.0.2006-literals. This is a little different than the tag-format specified by the W3C, because we support the older version.

Example Grammar Without SISR

#ABNF 1.0 UTF-8;
language en-US;
mode voice;

root $name;

$robertsmith = (robert | bob) [smith];

$name = $robertsmith;

Caller says "Bob" ? Engine returns "bob".

Without any SI

• Rule variable set to utterance
• Root rule inherits the $robertsmith rule variable

This is not very helpful, because you're getting back "bob", but it might also be "Robert", or "Robert Smith". The whole point of working with SISR is to get rid of these multiple results. Let's move on to an example with SISR.

Adding String Literals

#ABNF 1.0 UTF-8;
language en-US;
mode voice;
tag-format ;

root $name;

$robertsmith = (robert | bob) [smith] {100};

$name = $robertsmith;

Caller says "Bob" - $robertsmith is matched

• Rule variable set to "100"
• Root rule's variable = "100"
• Engine returns an interpretation of "100"

Expanded Example

We'll show you an example of an expanded call router. We've added in another name and a department, and they each have their own extensions which have been put in the SISR tag using the curly braces.

root $name;

$robertsmith = (Robert|bob) [smith] {100};
$billjones = (william|bill) [jones] {101};
$support = [technical] (support|service) {500};

$name = $robertsmith|$billjones|$support;

So this is really easy, right? If it's that easy there has to be a catch. The catch is that it's simple, and there's the limitation.

Drawbacks of String Literals

• Can only return strings
• Cannot perform any functions (could build out in application)
• Can only return the results of one rule

Let's say you had a pizza ordering application, and your caller wants to say that they want ham and sausage and pineapple on their pizza. String literals wouldn't help you there, because you couldn't choose multiple rules at a time. So if you need more complex options, you'll need to switch over to SI Script.

To reiterate, there are a lot of simple lists where string literals are fine. They're quick, they're easy to read and work with in simple menus where you expect the caller to pick one option. But for anything more complex, you'll need to work with SI Script. It's more complex, but it's a lot more flexible and powerful. We will cover working with SI Script in the next video.