Creating the context file

The context file is an XML document that specifies properties for a dialog state. It allows the following two elements:

  • <context>: Specifies a context. A context lets you group a set of properties. A <context> element can include other <context> elements—nested contexts—or <property> elements. You can also specify an id attribute to provide a name to a context, which can be used later to refer to a specific context.
  • <property>: Lets you set a property, using the same name and value attributes specified in the VoiceXML language.

Nuance recommends that you use a single context file per Voice Platform application. An Voice Platform application is defined by the Management Station, and may contain many VoiceXML files. Dialog content is tuned from call log data, and this data is segmented based on Voice Platform application boundaries. Having one context file per Voice Platform application, as opposed to one context file per VoiceXML file, eliminates the need for the tuning expert to understand VoiceXML application boundaries.

Name context files with a .ctx extension. The official MIME type for the context file will be application/x-nuance-context, but application/xml and a low-probability */* will also be sent in the HTML Accept header.

Understanding <context> elements

Since the <context> element can be nested within other <context> elements, they can be categorized according to their position relative to other elements:

  • A parent <context> contains one or more nested <context> elements.
  • A child <context> is contained in an enclosing <context> element. A child <context> may itself be a parent <context> or a leaf <context>.
  • A leaf <context> does not enclose another <context>. The innermost leaf <context> elements must be labeled with an identifier (specified with the id attribute) that is unique to the entire context file (and hence the Voice Platform application).

The following examples show how you could structure your context files. Consider a VoiceXML document that includes two forms. Each form has two items: a field to collect a number and a field to confirm the input. One way to organize the context file is to follow VoiceXML scoping lines. For example:

<?xml version="1.0"?>
<context>
document-level default properties
   <context>
      <context id="form1_fieldA">
      <property name="timeout" value="2s"/>
      </context>
      <context id="form1_fieldB">
      <property name="completetimeout" value="500ms"/>
      </context>
   </context>
   <context>
      <context id="form2_fieldA">
      <property name="timeout" value="2s"/>
      </context>
      <context id="form2_fieldB">
      <property name="completetimeout" value="500ms"/>
      </context>
   </context>
</context>

You could also organize the contexts by theme—for example, confirmation, help, and so on—since states with a similar purpose often share common tuning properties. For example, you could organize the contexts for the example above by grouping the form items in a get number context and a confirmation context. As shown below, instead of having to set the same property for each confirmation item, you could set it as a default for all confirmation items:

<?xml version="1.0"?>
<context>
document-level default properties
   <context>
   <property name="timeout" value="2s"/>
      <context id="form1_fieldA">
      </context>
      <context id="form2_fieldA">
      </context>
   </context>
   <context>
   <property name="completetimeout" value="500ms"/>
      <context id="form1_fieldB">
      </context>
      <context id="form2_fieldB">
      </context>
   </context>
</context>

The context identifier enables the leaf context to be uniquely referenced within the file and serves as the default grammar label for that state. When a VoiceXML application refers to the leaf context, it sets the nuance.grammarlabel property to the id specified. This label is used to identify a particular recognition state among the many recognition states in your Voice Platform application.

Parent contexts may not contain an identifier and thus may not be referenced. Allowing parent contexts to be referenced would imply a binding between the application developer and the tuner, because the tuning expert would have to be aware that the parent context could both completely apply to a particular state and serve to provide default <property> elements for another state. Such a configuration would be very difficult to maintain with an evolving application and tuning iterations.

Because leaf contexts are the only entry point into a context file, developers may need to specify an empty context just to grab the parent’s default values. This approach may seem awkward, particularly in the early stages where there is little tuning content to the file. However, this strategy will prove useful as the application evolves and is tuned over time. With this approach, tuning experts can use a state’s grammar label to locate the context for that state and then set the appropriate properties.

Setting properties in <context> elements

You can set most standard VoiceXML properties, Nuance extensions to VoiceXML properties, and Voice Platform application-settable service properties in a context file, with a few exceptions. For a complete list of VoiceXML properties that can be set in a context file, see the VoiceXML elements.

The semantics of nested <context> elements are similar to those in VoiceXML. <property> elements contained within enclosing <context> elements are included “as if by copy” into nested <context> elements, giving priority to <property> elements within the inner context. If a property occurs more than once in the same scope, the latest value takes precedence.