Comments on VXML Candidate Recommendation 28 January 2003 (part 2)

Hello,

Following are additional suggestions for clarifications on the VXML
Candidate Recommendation 28 January 2003. Let me know if more detail would
be useful, or please point me to the appropriate specifications section if I
missed it. I hope these comments can help.

Thanks and best regards,

Guillaume.

------------------------------------------
Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
guillaume.berche@eloquant.com
-----------------------------------------


1- Precise that buffered non-matching DTMF are discarded when an ASR grammar
matches.

It is unclear in the specifications whether the following document

<form name="form1">
  <field>
     <grammar src="builtin:grammar/boolean"/>
     <grammar src="builtin:dtmf/digits?length=4"/>
  <field>
  <filled>
     <goto next="#form2">
  </filled>
</form>

<form name="form2">
  <field>
     <grammar src="builtin:dtmf/digits?length=1"/>
  <field>
  <filled>
     <prompt>thanks for the dtmf</prompt>
  </filled>
  <noinput>
     <prompt>DTMF was discarded</prompt>
  </noinput>
</form>

By pressing the 1 key and speaking "yes" and waiting for the input timeout.
Should the interpreter play the "thanks for the dtmf" prompt or the "DTMF
was discarded" prompt?

Suggested solution: specify that partially buffered data are flushed in case
of grammar match in another mode.


2a- Rationale for not accepting local ruleref in inline SRGS grammars?

Can you please provide rationale for not accepting ruleref elements with
pure fragment URLs? Why would this be rejected in grammars provided inline
in VXML documents? What is the reason driving this restriction and forcing
to use remote grammars for any grammar using private rules?



2b- Schema imposes that grammar rule roots and [private] rule ids are unique
among grammar elements on a same VXML document.

The VXML schema imposes the following constraint to the root attribute of
the grammar element:

    <xsd:simpleType name="Root.datatype">
        <xsd:annotation>
            <xsd:documentation>does not expression the constraint that NULL
VOID GARBAGE
are illegal as rule name</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:IDREF">
            <xsd:pattern value="[^.:-]+"/>
        </xsd:restriction>
    </xsd:simpleType>

I understand this implies that it is illegal to have two different grammars
with refering to distinct root rules with the same name.


In addition, the VXML schema imposes the following constraint to the id
attribute of the rule element:

    <xsd:simpleType name="Id.datatype">
        <xsd:annotation>
            <xsd:documentation>
does not expression the constraint that NULL VOID GARBAGE are illegal as
rule name
</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:ID">
            <xsd:pattern value="[^.:-]+"/>
        </xsd:restriction>
    </xsd:simpleType>

I understand this implies that it is illegal in a same VXML document to have
two different grammars with private rules that have the same id. To me this
defeats the purpose of SRGS private rules (even if referencing to one inline
private is currently forbidden in VXML as noted in remark #2a)


Suggested modification: investigate modification of the VXML schema to waive
the restrictions described above.


3- Precise that when transitionning to a document (without fragment in the
URI) and the transitionned document has no form, then the interpreter exits

Rationale: it can not be requested that every document have at least a
dialog (because a root application may only define variables or links),
however when transitionning to a document (without specifying a dialog) and
this document has no dialog defined, then the execution stops.

Suggested modification to section "5.3.7 GOTO"

"If the form item, dialog or document to transition to is not valid (i.e.
the form item, dialog or document does not exist), an error.badfetch must be
thrown. Note that for errors which occur during a dialog or document
transition, the scope in which errors are handled is platform specific. For
errors which occur during form item transition, the event is handled in the
dialog scope. If the document to transition has no dialog defined (and no
specific dialog was specified), then the execution stops."



4- Precise Prompt selection algorithm when the Prompt element appears as
executable content.

It does not seem clear from the examples provided in section "4.1.6 Prompt
Selection" whether the "prompt tappering" mechanism is supposed to be
applied when a prompt element appears as executable content.

For instance in the following case:

<field ...>
<help>
   <prompt count="1"> prompt 1 </prompt>
   <prompt count="3"> prompt 2 </prompt>
   <goto next="#form2"/>
   <prompt count="4"> prompt 3 </prompt>

</help>
</field>

Which prompt should be heard when the prompt counter of the current form
item (the field in this same) is 4? Applying the algorithm described in
section "4.1.6 Prompt Selection" would result in having the "prompt 3"
speech text to be heard, however it would be very confusing from the VXML
author point of view because it would be expected that after the goto
element no more executable content would be executed as specified in
Appendix C in the definition of the "execute" term.

Suggested modification to section "4.1.6 Prompt Selection":

"Each input item, <initial>, and menu has an internal prompt counter that is
reset to one each time the form or menu is entered. Whenever the system uses
a prompt, its associated prompt counter is incremented. This is the
mechanism supporting tapered prompts within form item elements. **When a
prompt element is specified as executable content (e.g. inside a catch or
filled element) then its count element is ignored and all prompts contained
in this element as queued in document order)**"



5- Precise the value of name$.inputmode when a transfer is not interrupted
by user input

Suggested modification to "Table 22: <transfer> Shadow Variables"

"name$.inputmode     The input mode of the terminating command (dtmf or
voice) or **undefined if the transfer was not interrupted by a grammar
match**"



6- Correct typo in example of Section "4.1.3 Audio Prompting"

The extension of the file should rather be .vxml to not introduce confusion.
"<goto next="./make_bid.html"/>"



7- Precise that alternate audio is recursive:

According to the schema, the following vxml fragment is legal

<prompt>
  <audio src="http://www.dummy.org/main.wav" >
	<audio src="http://www.dummy.org/alternate1.wav" >
		<audio src="http://www.dummy.org/alternate2.wav"/ >
	</audio>
  </audio>
</prompt>

Can you please confirm my understanding of the specification: I understand
that if both main.wav and alternate1.wav can not be played, but
alternate2.wav can be played, then alternate2.wav will be played and no
error will be thrown.



8- Precise behavior of submit if undeclared/unvalid variables are references
in submit's namelist attributes

The specifications section "5.3.8 SUBMIT" states the following

"The list of variables to submit. By default, all the named input item
variables are submitted. If a namelist is supplied, it may contain
individual variable references which are submitted with the same
qualification used in the namelist. Declared VoiceXML and ECMAScript
variables can be referenced."

It does not specify the expected behavior in case an undeclared variable or
an invalid variable name is referenced in the namelist attribute.

Suggested modification to section "5.3.8 SUBMIT":
"namelist          The list of variables to submit. By default, all the
named input item variables are submitted. If a namelist is supplied, it may
contain individual variable references which are submitted with the same
qualification used in the namelist. Declared VoiceXML and ECMAScript
variables can be referenced. **If an undeclared or invalid variable name is
referenced then an "error.semantic" event is thrown**"



9- Inconsistent variable scope description:

In section "5.1.2 Variable Scopes", the dialog variable scope is defined as:

"dialog     Each dialog (<form> or <menu>) has a dialog scope that exists
while the user is visiting that dialog, and which is visible to the elements
of that dialog. Dialog variables are declared by <var> and <script> child
elements of <form> and by the various form item elements.  "

However, a block element is also a form item, as such variables defined in
its are part of the dialog scope.

Then the anonymous variable scope is defined as:

"(anonymous)  Each <block>, <filled>, and <catch> element defines a new
anonymous scope to contain variables declared in that element."

This definition is in contradiction with the first definition which
specified that the block element had its variables assigned into the dialog
scope.


Correction suggestion to section "5.1.2 Variable Scopes":
"(anonymous)  Each <filled>, and <catch> element defines a new anonymous
scope to contain variables declared in that element." (note block was
removed from the description to make it consistent with the definition of
the dialog scope)



10- Catch only apply to input items not to control items

Section "5.2.2 Catch" state that "The catch element associates a catch with
a document, dialog, or form item." However, the schema for block is the
following:

"    <xsd:element name="block">
        <xsd:complexType mixed="true">
            <xsd:choice minOccurs="0" maxOccurs="unbounded">
                <xsd:group ref="executable.content"/>
            </xsd:choice>
            <xsd:attributeGroup ref="Form-item.attribs"/>
        </xsd:complexType>
    </xsd:element>"

Suggested correction to Section "5.2.2 Catch":
"The catch element associates a catch with a document, dialog, or a form
item except for blocks."



11- Typo in section "2.3.6. RECORD"

The second sentence of the extract below seems incomplete, I don't get the
impact of the timeout interval on having a record variable unfilled.

"If no audio is collected during execution of <record>, then the record
variable remains unfilled (note). This can occur, for example, when DTMF or
speech input is received during prompt playback or the timeout interval (if
the developer wants input during prompt playback to initiate recording, then
prompts should be placed in an immediately preceding <field> with a zero
timeout). "


12- Typo in "Last Call Disposition of Comments"

The table in section "2. Comments" has an invalid "disposition" content: all
items are marked as accepted whereas this is not the case.

Received on Wednesday, 12 February 2003 08:45:58 UTC