Main Menu
|
Section Menu
|
Syllabus
|
Previous
|
![]() |
![]() |
Next |
Form Interpretation Algorithm
Weve 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 forms 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 forms 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 iterations 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 items 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 items
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 items 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 FIAs
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 links 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 forms FIA is started with this input in its process phase.
If an input matches a grammar in this form, then:
The inputs 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.
Main Menu
|
Section Menu
|
Syllabus
|
Previous
|
![]() |
![]() |
Next |