Comments to the Last Call Draft: mixed-initiative issues [Email Formatting Correction]

Questions to VoiceXML 2.0, Last Call Working Draft, 24 April 2002
-----------------------------------------------------------------
   by Lyndel.McGee@intervoice-brite.com 
      Bogdan.Blaszczak@intervoice-brite.com
 


We still find the last call draft somewhat ambiguous in the cases defined below.
We believe that additional explanations and/or changes to the draft are 
needed.

Problem #1. <initial> in mixed-initiative forms.
------------------------------------------------
Section 2.1.5 specifies (the 2nd sentence):
" To make a form mixed initiative, where both the computer and the human 
direct the conversation, it must have one or more <initial> form items and one or more form-level grammars. "

That implies that <initial> is a required element of the mixed-initiative form. The examples use <initial>, too. 
However, FIA does not seem to have any provisions to enforce it.

Our questions:  
- Is <initial> required for a form to be mixed-initiative ?
- Or, does a form-level grammar alone imply mixed-initiative? 

If <initial> is not required, then there seem to be no benefit in defining directed and mixed-initiative forms (a VoiceXML language structure). 
Instead, the directed and mixed-initiative behaviors should be discussed in terms of item modality and grammar types and scoping (VoiceXML use cases).

For example, the following language could be used:
- A 'directed dialog' can be implemented by using form item-level grammars rather than form-level grammars. If it is desired to restrict user options to just the item's grammar, the form item should be made modal. Otherwise, grammars in wider scopes may still accept user utterances (eg. links with 'restart', 'new order', etc.) and restart interpretation at a different 
form.
- A 'mixed-initiative dialog' can be implemented by using form-level 
grammars that may return multiple slots and thus allow multiple form items to be filled from a single caller utterance. The <initial> form item can be 
used in this scenario to prompt for and collect an utterance before 
executing any input items of the form (which may have their own specialized grammars and may potentially capture the recognition results as their own input).


Otherwise, if <initial> is required for a form to be mixed-initiative, a 
form without <initial> would be a directed form regardless of the presence of a form-level grammar. In such case, any utterances would be processed in 
the context of individual input items rather than in the form context. The form items will be filled one at a time.



Problem #2. Mapping results from a form-level grammar.
-------------------------------------------------------
Let's consider interpretation of a VoiceXML document where:
- there is a form with multiple fields,
- the form has a form-level grammar that can return multiple slots,
- the fields do not have their own grammars,
- it is a mixed-initiative form (see also the problem #1 above),
- the first recognition result fills some fields, but not all of them,
- another caller utterance is needed to fill the remaining fields.

Our questions:
- Is it expected that the form will switch to the 'directed dialog' mode 
after the first utterance and then consider only unfilled items for the 
subsequent utterances (see also problem #1 above) ?
- Or, will the form remain in the 'mixed-initiative dialog' mode and will user utterances continue to be mapped to multiple input fields (as the 2nd table in section 3.1.6.3 seems to imply) ?
- And, if the form is to remain in the 'mixed-initiative dialog' mode, can the next user utterance overwrite fields that have been already filled or will those fields retain their previous values ?

To illustrate the problem, let's assume that:
  - the fields are 'size', 'color', and 'shape',
  - the first utterance is 'big square',
  - the second prompt says 'Please provide the color',
  - the second utterance is 'blue triangle'.
Will the completed form be 'big blue square' or 'big blue triangle' ?
The 2nd table in section 3.1.6.3 should be updated to cover all (canonical) combinations of user input and dynamic states of form components.

Any feedback on the above issues will be greatly appreciated.

Lyndel McGee
Bogdan Blaszczak