VoiceXML

 

Form Interpretation Algorithm

We’ve presented the form interpretation algorithm (FIA) at a conceptual level while introducing Forms.

Initialization Phase

Whenever a form is entered, it is initialized. Internal prompt counter variables (in the form’s dialog scope) are reset to 1. Each variable (form-level <var> elements and form item variables) is initialized, in document order, to undefined or to the value of the relevant expr attribute.

Main Loop

The main loop of the FIA has three phases:

The select phase: the next form item is selected for visiting.

The collect phase: the next unfilled form item is visited, which prompts the user for input, enables the appropriate
grammars, and then waits for and collects an input (such as a spoken phrase or DTMF key presses) or an event
(such as a request for help or a no input timeout).

The process phase: an input is processed by filling form items and executing <filled> elements to perform actions
such as input validation. An event is processed by executing the appropriate event handler for that event type.

Note that the FIA may be given an input (a set of grammar slot/slot value pairs) that was collected while the user
was in a different form’s FIA. In this case the first iteration of the main loop skips the select and collect phases, and
goes right to the process phase with that input.

Select phase

The purpose of the select phase is to select the next form item to visit. This is done as follows:

If a <goto> from the last main loop iteration’s process phase specified a <goto nextitem>, then the specified form
item is selected.

Otherwise the first form item whose guard condition is false is chosen to be visited.

If no guard condition is false, then the last iteration completed the form without encountering an explicit transfer of
control, so the FIA does an implicit <exit> operation.

Collect phase

The purpose of the collect phase is to collect an input or an event. The selected form item is visited, which performs
actions that depend on the type of form item:

If a field item is visited, the FIA selects and queues up any prompts based on the field item’s prompt counter and the
prompt conditions. Then it listens for the field level grammar(s) and any active higher-level grammars, and waits for a
grammar recognition or for some event.

If a <transfer> is visited, the prompts are queued based on the item’s prompt counter and the prompt conditions.
The item grammars are activated. The queue is played before the transfer is executed.

If a <subdialog> or <object> is visited, the prompts are queued based on the item’s prompt counter and the prompt
conditions. Grammars are not activated. Instead, the input collection behavior is specified by the executing context
for the subdialog or object. The queue is not played before the subdialog or object is executed, but instead should
be played during the subsequent input collection.

If an <initial> is visited, the FIA selects and queues up prompts based on the <initial>’s prompt counter and prompt
conditions. Then it listens for the form level grammar(s) and any active higher-level grammars. It waits for a grammar
recognition or for an event.

A <block> element is visited by setting its form item variable to true, evaluating its content, and then bypassing the
process phase. No input is collected, and the next iteration of the FIA’s main loop is entered.

Process phase

The purpose of the process phase is to process the input or event collected during the collect phase, as follows:

If an event (such as a noinput or a hangup) occurred, then the applicable catch element is identified and executed. Selection of the applicable catch element starts in the scope of the current form item and then proceeds outward by enclosing dialog scopes. This can cause the FIA to terminate (e.g. if it transitions to a different dialog or document or it does an <exit>), or it can cause the FIA to go into the next iteration of the main loop (e.g. as when the default help event handler is executed).
If an input matches a grammar from a <link> then that link’s transition is executed, or its event is thrown. If the <link> throws an event, the event is processed in the context of the current form item (e.g. <initial>, <field>,
<transfer>, and so forth). If an input matches a grammar in a form other than the current form, then the FIA terminates, the other form is initialized, and that form’s FIA is started with this input in its process phase.

If an input matches a grammar in this form, then:

The input’s grammar slot values are assigned to the corresponding field item variables. The <filled> actions triggered by these assignments are identified as described . Each identified <filled> action is executed in document order. If a <submit>, <disconnect>, <exit>, <return>, <goto> or <throw> is encountered, the remaining <filled> elements are not executed, and the FIA either terminates or continues in the next main loop iteration. <reprompt> does not terminate the FIA (the name
suggests an action), but rather just sets a flag that affects the treatment of prompts on the subsequent iteration of the FIA. If an event is thrown during the execution of a <filled>, event handler selection starts in the scope of the <filled>, which could be a form item or the form itself, and then proceeds outward by enclosing dialog scopes.

After completion of the process phase, interpretation continues by returning to the select phase.