Part No. 520-0004-02 | © 1999-2007, BeVocal, Inc. All rights reserved | 1.877.33.VOCAL
A grammar identifies different words or phrases that a user might say and (optionally) specifies how to interpret a valid expression in terms of values for input variables. Grammars can range from a simple list of possible words to a complex set of possible phrases.
Each field in a form can have a grammar that specifies the valid user responses for that field. An entire form can have a grammar that specifies how to fill multiple input variables from a single user utterance. Each choice in a menu has a grammar that specifies the user input that can select the choice.
A grammar contains one or more rules that specify matching input, usually with one rule specified as the root rule of the grammar. If the grammar has a root rule, then you can use the grammar in your VoiceXML application without naming which rule to start from.
In some grammars, there is exactly 1 top-level rule that can be used as a starting point for that grammar. For example, a simple yes/no grammar might consist of a single rule, allowing "yes", "no", and various synonyms, such as "yep", "nope", or "no way". In this grammar, the root rule would, of course, be that one starting point.
A larger or more complex grammar, however, may have several rules that can be used as a starting point. For example, consider a grammar for recognizing marine animals. It could have 1 rule that recognizes all marine animals. That rule might itself be composed of rules that recognize smaller sets of animals, such as one for marine mammals, another for types of coral, and a third for species of fish. This marine animals grammar might allow you to specify one of these subrules as the starting point, instead of always using the complete grammar. To use the subrules, you'd have to ask for the rule by name. This grammar might still identify one rule as the root rule, so that you could ask for the grammar without specifying a rule by name.
Your VoiceXML application specifies a grammar to use with the VoiceXML <grammar> tag. It can use built-in grammars and application-defined grammars.
A built-in grammar is one that is built directly into the VoiceXML interpreter. You can use these grammars without any coding effort.
An application grammar, on the other hand, is one that a developer defines from scratch. An application grammar may be a grammar you've defined specifically for a particular application or it may part of a general library of grammars you have access to for reuse in multiple VoiceXML applications.
Application grammars can either be inline or external. The entire definition of an inline grammar appears directly in the <grammar> element of the VoiceXML document; the definition of an external grammar appears in a separate file.
If the <grammar> element contains content, that content is the definition of an inline grammar. If the element does not contain content, it must have a value for either the src attribute or the expr attribute. In this case, depending on the value of that attribute, the reference is to either a built-in grammar or an external grammar file.
This chapter is concerned with how you use a grammar in your VoiceXML document and what the interpreter does with the grammar in later processing. This chapter has the following sections:
| • | Referencing Grammars |
| • | VoiceXML <grammar> element |
| • | Active Grammars and Grammar Scope |
| • | Setting Input Variables |
| • | Ambiguous Grammars |
| • | Universal Grammars |
The rest of this document contains the following chapters:
| • | Chapter 2, Using Built-in Grammars describes built-in grammars and how to use them. |
| • | Chapter 3, Defining Grammars describes general information on how to build and use your own grammars. |
| • | Chapter 4, XML Speech Grammar Format, Chapter 5, ABNF Grammar Format, Chapter 6, Nuance GSL Grammar Format, and Chapter 7, JSGF Grammar Format describe the individual grammar formats you can use to write your grammar--the XML form of the W3C Speech Recognition Grammar Format, the Augmented BNF (ABNF) form of the W3C Speech Recognition Grammar Format, the Nuance Grammar Specification Language (GSL), and the Java Speech Grammar Format (JSGF). |
| • | Chapter 8, Nuance SayAnything Grammars describes how to use Nuance Say Anything grammars. |
| • | Chapter 9, Voice Enrollment Grammars describes how to create and use a special type of grammar that directly captures a user's utterance for a grammar. You use these grammars from within an ABNF grammar. |
You reference a grammar with the VoiceXML <grammar> element. You use a different syntax to reference each type of grammar.
A built-in grammar is defined directly by the VoiceXML interpreter. The primary way your application references a built-in grammar is from the <grammar> element, by providing a value for the src attribute using one of the following formats:
builtin:grammar/typeNamebuiltin:grammar/typeName?parameters
Chapter 2, Using Built-in Grammars describes alternative ways to specify a built-in grammar in some circumstances.
Specific standard built-in dtmf-only grammars can be specified using the syntax:
builtin:dtmf/typeName
See Chapter 2, Using Built-in Grammars for more details.
If a VoiceXML <grammar> tag does not have a value for either the src or the expr attribute, it is an inline grammar and must have child elements that constitute a valid grammar definition (as described in later chapters).
By its very nature, you do not reference an internal grammar, it is simply included where it's needed.
If a VoiceXML <grammar> tag has a value for either the src or the expr attribute, it is an external grammar and the attribute must specify the URI of an external grammar file (src) or be a JavaScript expression that evaluates to such a URI (expr). If the tag has one of these attributes, it cannot also have child elements.
Providing a value for the src or expr attribute is called referencing the grammar. As we'll see later, you can also reference a grammar from within a grammar. When a grammar is referenced by a VoiceXML document or another grammar, there must be a way for the VoiceXML interpreter to decide which rule in the grammar to use as its starting point in that grammar. The reference may explicitly name a rule to use; if it does so (and that rule is available in the grammar), then the interpreter uses the named rule. On the other hand, the reference may only name a grammar and not name a rule within the grammar. In this case, the grammar must itself identify a rule for the interpreter to start from. The rule that the grammar identifies is called the root rule of the grammar.
The URI specified by src or expr can be of one of the following general formats:
For example, assume colors.gram contains 3 rules, Colors, Shades, and ShadeAndColor, where the ShadeAndColor rule is defined in terms of the two other rules and the external grammar file identifies ShadeAndColor as the root rule of the grammar. (Later chapters will discuss how to create such a grammar file.) With this grammar, the paint field can access the ShadeAndColor rule as follows:
<field name="paint"><grammar src="colors.gram"/>... </field>
When this field becomes active, the interpreter uses ShadeAndColor as the top-level rule for recognizing input. This rule itself accesses the other rules in the grammar. On the other hand, the color field can directly use the Colors rule by specifying it as the rule to start from:
<field name="color"><grammar src="colors.gram#Colors"/>... </field>
In this case, the interpreter uses the colors.gram file and uses the rule in that file named Colors as its starting point. It is an error if colors.gram does not contain a rule named Colors.
You can specify the URI in either absolute or relative terms. For example, a VoiceXML document http://myCompany.com/myvxml.vxml could use any of the following URIs to refer to the same grammar file:
You use a <grammar> element in your VoiceXML document to specify a grammar to be used within some VoiceXML tag such as <field>, <form>, or <link>. The <grammar> element serves two primary purposes:
| • | To define the grammar or point to a predefined grammar |
The <grammar> element can either contain the entire grammar definition directly, point to an external grammar file in one of several formats, or point to a built-in grammar. Referencing Grammars described the differences in the <grammar> element for identifying where to locate the grammar definition. In addition, if the grammar definition is inline and is in the XML format, then the <grammar> element allows extra attributes to support the grammar definition; these attributes are ignored for an inline grammar in any other format and they are ignored for all external grammars. These special attributes are described in Chapter 4, XML Speech Grammar Format. | |
| • | To specify aspects of how to use the grammar in the particular containing VoiceXML element. |
For this purpose, the <grammar> element supports a set of attributes you can use with any application grammar. You can use these attributes for any grammar format and for both external and internal grammars. You cannot use these attributes for built-in grammars. |
The grammar attributes are as follows:
| Available when | Attributes | For information, see |
src expr |
||
On the These are part of defining the grammar. The other grammar definition formats do not use attributes to specify this information. |
mode root tag-format version xml:base xml:lang |
|
On a VoiceXML These are for controlling fetching and caching information in the interpreter. They only make sense for external files. |
fetchhint fetchtimeout maxage maxstale caching (VXML 1.0 only) |
Chapter 4, Fetching and Caching Resources of the VoiceXML Programmer's Guide |
On a VoiceXML These are for specifying how to use a grammar, once defined. They are applicable to all grammars except built-in grammars. |
scope type universal |
|
On the These are for specifying XML information about the document as a whole. They only make sense on the root element of a VoiceXML or XML document. |
xmlns xmlns:xsi xsi:schemaLocation |
|
weight |
The scope attribute sets the scope of a form grammar; you cannot set this attribute for other grammars. See Active Grammars and Grammar Scope for information about grammar scopes. The possible values are:
Note: Some grammar formats have the notion of the scope of an individual rule in the grammar. That scoping is separate from the scope of the grammar as a whole.
The type attribute optionally specifies the MIME type of the grammar; that is, it specifies the grammar's format. If present, this attribute is only used as a last resort by the interpreter. If the interpreter can determine a grammar's format in some other way, it does so.
The currently supported types are:
| Type | Grammar |
In addition, the following types are deprecated, but are currently supported. Support for these values will be removed from a future release.
| Type | Grammar |
For external grammars, the default type is taken from the Content-type header of the returned file. If not present, the type is inferred from the extension of the URL or from the contents of the grammar (for example, a file beginning with <?xml maps to application/srgs+xml). The recognized extensions are:
| Extension | Grammar |
|
|
|
|
|
|
|
|
|
For internal grammars, if the grammar definition specifies the grammar type (either directly with a declaration or indirectly by containing XML elements), the interpreter uses that type. If the grammar definition doesn't indicate the type, the interpreter uses the value of the type attribute, if present. Otherwise, the interpreter assumes that the grammar is in GSL format.
Later chapters describe these grammar formats in detail.
The universal attribute is a BeVocal extension that lets you declare the grammar as a "universal" grammar; that is, one that is always active. The string you specify as the attribute value is used as the name of the universal grammar; you use that string to activate and deactivate the universal grammar using the universals property. This attribute does not affect the scope of the grammar; it simply assigns it to a universal category.
For more information on universal grammars, see Universal Grammars.
The speech-recognition engine uses active grammars to interpret user input. A grammar is active when it is in scope. The speech-recognition engine recognizes utterances from any and all active grammars; that is, all grammars that are in scope. There are four scopes:
| Scope | Grammar is in scope when execution is | Default scope for a grammar defined in |
any element with document scope that appears in the application root document. |
By default, the scope of a grammar is set by the element that contains the grammar:
| • | If the parent is an input item, the grammar has field scope. |
| • | If the parent is a link, the scope is the element that contains the link. |
| • | If the parent is a menu choice, the grammar scope is specified by the scope property of the containing <menu> element (or dialog scope by default). |
Field scope is the lowest, or narrowest, scope and application scope is the highest, or widest, scope.
For example, a field grammar is active whenever the interpreter is executing that field. A menu-choice grammar is active whenever the interpreter is executing the containing menu. A form grammar is active whenever the interpreter is executing the containing form.
If the interpreter is executing one dialog and the user's input matches an active grammar for a different dialog, control transfers to the latter dialog. If the user says something that matches a grammar of higher scope, control jumps to the higher-level element that contains the matching grammar. In the case of an event handler, control resumes in the original dialog after the event is handled. If the grammar is in application scope, control might transfer to a dialog in a different document.
A form grammar or the collection of choice grammars in a menu can optionally be made active at higher scopes. In general, you should keep the scope of your grammars as narrow as possible; this allows the speech-recognition engine to be most efficient.
The interpreter uses a grammar to recognize user input. The interpreter then uses the returned information to set appropriate input variables that can be used by other elements in the VoiceXML application. The rules for how the interpreter sets variables are somewhat complicated. For basic information on input variables, see Chapter 1, Getting Started in the VoiceXML Programmer's Guide.
The grammar always returns the text string matched as the utterance. Depending on the grammar, it may also return a semantic interpretation of the utterance. A semantic interpretation is itself a structured object that can provide several pieces of information about what the user said. For example, if the matched text string is "March thirteenth", the semantic interpretation might indicate that the month is "March" and the day of the month is "13".
When the interpreter recognizes a valid utterance against a grammar, it sets the variable application.lastresult$ to a JavaScript object containing information about the recognized utterance. The application.lastresult$.utterance field always contains a text string of the words that were recognized. If the grammar specified a semantic interpretation, the application.lastresult$.interpretation field contains that JavaScript object.
To set input variables, the interpreter uses the semantic interpretation if there is one. If there is not a semantic interpretation, it uses the utterance text string.
Exactly what the interpreter does depends on whether or not there is a semantic interpretation and on whether the grammar was a field-level grammar or a form-level grammar.
In this case, things are very simple.
If there is no semantic interpretation and recognition was against a form-level grammar, the interpreter does not set any input variables.
If there is no semantic interpretation and recognition was against a field-level grammar, the interpreter sets that field's input variable to the utterance text string.
For example, if the field-level grammar is a disjunction of a set of simple words, you can use a very simple notation, as shown here (using the GSL format):
[ january february march april may june july august september october november december ]
If the user says "February", then the input variable is assigned the value february. If the input variable is date, you can obtain its value in the field's <filled> element with:
<value expr="date">
If there's a semantic interpretation, things are significantly more complicated. The semantic interpretation is a JavaScript object, such as:
{
airline: "aa"
flight: {
start: "sjc"
roundtrip: "yes"
stops: [ "lax" "phx" ]
freqflyer: undefined
}
}
This example object has 3 properties, airline, flight, and freqflyer. Notice that the values of the properties can be a simple text string, another structure, or undefined. We'll see in a bit how the interpreter uses these different properties. First, however, we need to understand slot names.
Every input item has an associated slot name. The interpreter uses the slot name to extract a part of the full semantic interpretation to use for that input item. If a <field> element has a slot attribute, the value of that attribute is its slot name. For all other input items, and for <field> elements that do not set the slot attribute, the slot name is the value of the name attribute. If neither slot nor name is present, then the slot name is undefined.
For example, with this definition:
<field name="airline">
The slot name is airline and the input variable is airline. But with this definition:
<field name="carrier" slot="airline">
The slot name is airline, but in this case the input variable is carrier.
The interpreter uses the slot name to figure out what value to extract from the semantic interpretation result. It there is a match, it sets the input variable to that value. With the second field definition and the semantic interpretation above, the interpreter uses the slot name airline to extract the value aa from the semantic interpretation and assigns the value aa to the input variable carrier.
With a field-level grammar, with a given semantic interpretation, the interpreter always sets the input variable for that one field.
Assume that you have a field grammar that recognizes the user utterance "from San Jose to Los Angeles and then on to Phoenix and back." And that the interpreter returns this semantic interpretation for the recognition:
{
flight: {
start: "sjc"
stops: [ "lax" "phx" ]
}
}
The following table shows how the interpreter uses this semantic interpretation to set the input variable for different field definitions.
A form that includes its own grammar is a mixed-initiative form. If you are writing a grammar for a mixed-initiative form, you may use multiple slot names, each identifying an input variable to be filled. In this case you can name each field (or set its slot attribute) according to the corresponding slot name in the grammar.
Here, the interpreter may set one input variable, many input variables, or none at all.
Assume that you have a form grammar that recognizes the user utterance "I would like to fly American Airlines from San Jose to Los Angeles and then on to Phoenix and back." And that the interpreter returns this semantic interpretation for the recognition:
{
airline: "aa"
flight: {
start: "sjc"
roundtrip: "yes"
stops: [ "lax" "phx" ]
freqflyer: undefined
}
}
The following table shows how the interpreter uses this semantic interpretation to set the input variables of different field elements for the form.
A grammar is ambiguous if more than one rule can match a given user utterance. Ambiguous grammars can be a problem if the different rules make different slot assignments. For example:
#ABNF 1.0;
root $Cities;
$Cities =
portland [maine] {city="Portland" state="Maine"} |
portland [oregon] {city="Portland" state="Oregon"} |
dallas [texas] {city="Dallas" state"Texas"}
;
The Cities rule is ambiguous because the utterance "Portland" can match two rules; the state slot could be filled either with Maine or Oregon.
In general, you should avoid using ambiguous grammars. If you choose to use them, you need to enable recognition of multiple interpretations of the user's speech and implement a mechanism to get user clarification for ambiguous utterances. See Chapter 5, Using Multiple-Recognition in the VoiceXML Programmer's Guide.
A universal command is always available--the user can give the command at any point in an interaction. A universal grammar specifies user utterances that can be recognized as a universal command.
The following predefined universal grammars are available to all applications:
| Grammar | Description |
|
|
|
|
|
|
|
The user wants to retract the last response and go back to an earlier part of the interaction. |
If one of these predefined universal grammars is activated and a user utterance matches the grammar, an event of the same name is thrown. For example, a help event is thrown when the user says "help."
An application creates its own universal command by defining and enabling a new universal grammar and implementing its response to the command.
To define a universal grammar, set the universal attribute in the <grammar> tag that defines the grammar for the command. The attribute value is a name that uniquely identifies the grammar among all universal grammars in the application. In the following example, the new universal grammar is named joke; the user utterance "Tell me a joke" will be a universal command when this universal grammar is activated.
<!-- GSL format --> <grammar universal="joke"> (tell me a joke) </grammar>
You should not name your universal grammars help, exit, cancel, goback, or none.
An application can activate any of the universal grammars to enable the corresponding universal commands. When a universal grammar is activated, a user utterance that matches the grammar is treated as a universal command.
All universal grammars are deactivated by default. The application can activate some or all universal grammars by setting the universals property. This property specifies which of the universal grammars should be active; all other universal grammars are deactivated.
Note: (VoiceXML 1.0 only) If the <vxml> tag's version attribute is 1.0, all universal grammars are activated by default.
A <link> element containing a universal grammar implements the application's response to the corresponding universal command. Your application can respond to the command in whatever manner is appropriate. Typically, the response is to throw an event or to transition to a different form.
If you throw an application-specific event, you must provide an event handler to take the appropriate action. For example:
<!-- Throw an event when the command is given -->
<link event="joke">
<!-- Define the universal grammar (GSL format) -->
<grammar universal="joke">
(tell me a joke)
</grammar>
</link>
<!-- Invoke a subdialog when the event is thrown -->
<catch event="joke">
<subdialog name="joker" src="telljoke.vxml"/>
</catch>
|
Café Home |
Developer Agreement |
Privacy Policy |
Site Map |
Terms & Conditions Part No. 520-0004-02 | © 1999-2007, BeVocal, Inc. All rights reserved | 1.877.33.VOCAL |