More comments on draft from Apr 24, 2002.

Scott,

Following are additional suggestions for clarifications on the VXML 2.0 W3C
Working Draft from 24 April 2002 (the latest public draft). I understand
that my comments may not be processed for the next public draft because it
is out of the official review period, but I nevertheless hope they can be
useful. From the VBWG responses to the mailing list I could not find
information that let me suppose that these issues were already fixed in the
private draft of the VBWG. Please point me to such responses when I missed
them.

Let me know if more detail would be useful.

Thanks and best regards,

Guillaume.

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



0- Precise the value of the _dtmf special variable when a grammar element is
specified in a choice element.

As specified in the section "2.2 Menus", paragraph "Choice element":
"If a <grammar> element is specified in <choice>, then the external grammar
is used instead of an automatically generated grammar."

However, in such case it is not clear what value will be assigned in the
_dtmf special variable while executing an enumerate element.

Suggested text modification to "2.2 Menus", paragraph "Enumerate element":

"This specifier may refer to two special variables: _prompt is the choice’s
prompt, and _dtmf is the choice’s assigned DTMF sequence. **If no DTMF
sequence is assigned to the choice element or if a <grammar> element is
specified in <choice> then the _prompt variable is assigned the ECMAScript
undefined value.**"



1- Precise semantics of id attribute of form and menu

The id attribute is optional according to the schema. However the
specifications do not seem to precise how the interpreter should handle
dialogs without specified id.

Suggested text modification to section "2.1 Forms":

"id         The optional name of the form. If specified, the form can be
referenced within the document or from another document. For instance <form
id="weather">, <goto next="#weather">. **If not specified, an internal name
is generated by the interpreter instead.**"

Suggested text modification to section "2.2 Menus":

"id The optional identifier of the menu. It allows the menu to be the target
of a <goto> or a <submit>. **If not specified, an internal name is generated
by the interpreter instead.**"



2- Precise that <value expr="null"> should be ignored silently

There are cases where it is difficult to know whether a variable (such as
special variable as _dtmf) has a non-null value without writing an explicit
if statement. To avoid this, it would be convenient if value elements would
be silently ignored if their expressions resolved into the ECMAScript
undefined value (whereas references to undeclared variables would keep
throwing an error.semantic event).

Suggested text modification to section section "4.1.4 <value> Element":

"expr The ECMAScript expression which provides the text to render, or
resolves into a special variable such as _prompt or _dmtf as specified in
section "2.2 Menus" paragraph "Enumerate element". If the expression
resolves into the ECMAScript undefined value, then the value element is
silently ignored. However, if the expression refers to an undeclared
variable, then an error.semantic event is thrown."



3- Precise the value of _prompt when an option has no nested CDATA

As specified in "2.3.1.3. Fields Using Option Lists": "The default
assignment is the CDATA content of the <option> element with leading and
trailing white space removed. If this does not exist, then the DTMF sequence
is used instead."

Since the valueof the _prompt variable is computed from the CDATA content,
what values is assigned to the _prompt variable when no CDATA content is
available in an option element? If the undefined value is assigned to the
_prompt special variable, would a <value expr="_prompt"> element fail?

Suggested modification: if no CDATA is available from the <option> or
<choice> element, then the _prompt special variable is assigned the
undefined ECMAScript value.



4- precise the semantics of the value attribute of option elements

Section "2.3.1.3. Fields Using Option Lists" specifies the following: "value
The string to assign to the field’s form item variable when a user selects
this option, whether by speech or DTMF. The default assignment is the CDATA
content of the <option> element with leading and trailing white space
removed. If this does not exist, then the DTMF sequence is used instead. "

However, the DTMF sequence is optional according to the schema.
Consequently, it would be useful to precise the behavior if unspecified

Suggested text modification to section "2.3.1.3. Fields Using Option Lists":

"Each <option> element contains PCDATA that is used to generate a speech
grammar. This follows the grammar generation method described for <choice>
in Section 2.2. Attributes may be used to specify a DTMF sequence for each
option and to control the value assigned to the field's form item variable.
Each option should at least define a DTMF sequence through the dtmf
attribute or contain CDATA content specifying the matching speech element,
otherwise an error.badfetch event is thrown."



5- Precise the format of the _dtmf special variable.

Section "2.2 Menus", paragraph "Enumerate element" states that "specifier
may refer to two special variables: _prompt is the choice’s prompt, and
_dtmf is the choice’s assigned DTMF sequence." However it does not precise
how the DTMF sequence is formatted (whether there are white space delimiters
that makes the string suitable for direct inclusion within a speech prompt)

Suggested text modification to section "2.2 Menus", paragraph "Enumerate
element":
"_prompt is the choice’s prompt, and _dtmf is the choice’s assigned DTMF
sequence formatted as a string holding the DTMF keystrokes separated by
white spaces (making it suitable for inclusion within a speech prompt)"



6- Precise the semantics of the dtmf attribute of option elements

Suggested modification to section "2.3.1.3. Fields Using Option Lists":

"dtmf    An **optional** DTMF sequence for this option. It is equivalent to
a simple DTMF <grammar> and DTMF properties (Section 6.3.3) apply to
recognition of the sequence. Unlike DTMF grammars, whitespace is optional:
dtmf="123#" is equivalent to dtmf="1 2 3 #". **If unspecified, no DTMF
grammar is associated to this option, meaning that this option can not be
matched using a DTMF**"

Rationale: it would make sense to add an option similar to the menu's dtmf
attribute so that dtmf sequence is automatically generated. Without this
attribute, how would an VXML author prevent the automatic generation of DTMF
grammars that may override other grammars (such as links)?
In addition, we would also need to specify what happens if a specified
option's dtmf attributes overlaps an automatically assigned dtmf. Should
this throw an "error.semantic" event as for choice elements or should we
rather apply the default grammar precedence algorithm to select the matching
element?



7- Precise semantics of Clear element.

Section "5.3.3 CLEAR" states that "The <clear> element resets one or more
form items" However, the definition of the namelist attribute adds that
"this [i.e. the namelist] can include variable names other than form items"
Besides, in the case where the namelist includes variable names other than
form items, what is the variable scope in which the variable must be defined
to be cleared?

Since a Clear element is an executable which may be included in a catch
element, which variable scope does it targets? In other words, would the
reset of a non-form item variable target the anonymous, dialog, document or
application-level scope?
[In addition, the Clear element may be invoked outside of the FIA (such as
during the document initialization), in which the notion of active element
is not clear, so relying on the scope of the active element as the scope in
which a variable should be cleared is ambiguous.]

Suggested text modification to Section "5.3.3 CLEAR":
"The <clear> element resets one or more form items, and possibly other
variables which are not form items. For each specified variable name, the
variable is resolved in the closest enclosing scope of the currently active
element as described in section "5.1.3 Referencing Variables". To remove
ambiguity, each variable name in the namelist may be prefixed with a scope
name as described in section "5.1.3 Referencing Variables".

Once a declared variable has been identified as declared in a given scope S,
its value is assigned the ECMAScript undefined value. In addition, if the
variable name corresponds to a form item in scope S, then the form item's
prompt counter and event counters are reset."



8- Precise that var name attribute does not support scope prefixes

Suggested text modification to section "5.3.1 VAR":
 "name        The name of the variable that will hold the result. **Unlike
the name attribute of assign element, this attribute should not contain dots
(and in particular a scope prefix). The scope in which the variable is
defined is determined from the position in the document at which the var
element is declared.**"



9- Precise that the assign's name attribute does support scope prefixes

The scope in which a variable is resolved is currently not clear. The
accepted scope prefix in the name attribute is also not clear.

Suggested text modification to section "5.3.2 ASSIGN"

"name The name of the variable being assigned to. As specified in section
"5.1.2 Variable Scopes", the corresponding variable should have been
previously declared otherwise an error.semantic event is thrown. By default,
the scope in which the variable is resolved is the closest enclosing scope
of the currently active element. To remove ambiguity, the variable name may
be prefixed with a scope name as described in section "5.1.3 Referencing
Variables". Note however that the name must refer to a variable and can not
refer to a property of an ECMAScript object or be a complex ECMAScript
expression."



10- Precise evaluation order of log attributes versus nested text/value, and
constraints on attributes

Suggested modification to section "5.3.13 LOG":

"label An **optional** string which may be used, for example, to indicate
the purpose of the log.
expr An **optional** ECMAscript expression evaluating to a string.
"

"The <log> element may contain any combination of text (CDATA) and <value>
elements. The generated message consists of the concatenation of the
evaluation of the ECMAscript expression followed in their respective order
by the nested text and the string form of the value of the "expr" attribute
of the <value> elements."



11- Precise ordering of anonymous grammar generated for dtmfterm

As specified in section "2.3.6. RECORD": "The <record> element contains a
'dtmfterm' attribute as a developer convenience. A 'dtmfterm' attribute with
the value 'true' is equivalent to the definition of a local DTMF grammar
which matches any DTMF input. "

However, it is legal to have nested grammars in a record element. For
instance, a DTMF grammar that matches only the # key. It is not clear which
grammar would match because the precedence is not described.

Suggested text modification to section "2.3.6. RECORD": "The <record>
element contains a 'dtmfterm' attribute as a developer convenience. A
'dtmfterm' attribute with the value 'true' is equivalent to the definition
of a local DTMF grammar which matches any DTMF input. Any nested grammar
element will have precedence over this anonymous local grammar (even though
usefulness of such nested grammar is not clear)."



12- Precise the semantics of the timeout property for the record element

The specs currently state the following "A timeout interval is defined to
begin immediately after prompt playback (including the 'beep' tone if
defined) and its duration is determined by the 'timeout' property. If the
timeout interval is exceeded before recording begins, then a <noinput> event
is thrown. "

However, how the "recording begins" is not clearly defined. I would assume
that when the platform supports speech recognition during recording, the
recording begins as soon as speech is provided by the remote end. However
the specification is not clear on whether in this case the platform should
remove the silence from the end of the first beep prompt up to the first
recognised speech. It is not clear either whether background noise or music
should trigger beginning of recording. For platforms not supporting speech
recognition during recording I believe this timeout property should be
ignored.

Suggested text modification to section "2.3.6. RECORD":

"A timeout interval is defined to begin immediately after prompt playback
(including the 'beep' tone if defined) and its duration is determined by the
'timeout' property. If the timeout interval is exceeded before recording
begins, then a <noinput> event is thrown. When the platform supports
detection of silence, the recording begins as soon as leading silence
(following the 'beep' tone if defined) completes. Note that whether the
recording would include the leading silence is platform specific. For
platforms not supporting silence detection, this property is ignored and no
<noinput> even is ever raised during a recording."



13- Precise that maxtime record attribute is mandatory and has no defaults

Suggested text modification to section "2.3.6. RECORD":
"maxtime The maximum duration to record. **This attribute must be specified
as it has no default value. If not specified an error.badfetch event is
thrown.**"



14- Precise that if value is used outside of a prompt element it inherits
default prompt parameters

The prompt element defines that if its attributes are not specified, they
default to values specified by properties. However, for the value element,
the specification do not precise how default values are computed.

Suggested text addition to section "4.1.4 <value> Element":
"The manner in which the value attribute is played is controlled by the
surrounding speech synthesis markup in the case the expression resolves to a
string. In the case the expression resolves to a special variable such as
_prompt, then the prompt attributes are inherited from the enclosing element
of the definition of the referenced element.

If no surrounding prompt element nor SSML tag is available, then the default
attributes of a prompt element (such as bargein, timeout or language) are
applied.

Consequently, the two following constructions are equivalent.
<catch event="noinput">
  <value expr="'please retry'">
</catch>

<catch event="noinput">
  <prompt>
      <value expr="'please retry'">
  </prompt>
</catch>
"



15- Precise that <value expr="_prompt"/> should not be used within a choice
prompt or an option prompt.

For instance, the following VXML content should throw an error.semantic
event for the nested value inside the "sports" choice:

<menu dtmf="true">
  <prompt>
    Welcome home.
    <enumerate>
     For <value expr="_prompt"/>, press <value
     expr="_dtmf"/>.
   </enumerate>
   </prompt>
   <choice next="http://www.sports.example.com/vxml/start.vxml">
      sports <value expr="_prompt"/>
   </choice>
   <choice next="http://www.stargazer.example.com/voice/astronews.vxml">
      news
   </choice>
</menu>



16- Inconsistent behavior of option vs choice.

- Choice can have nested grammars that override the default grammar whereas
options can not
- Choice can have nested audio as alternate prompts whereas options can not
- Menus can have a dtfm boolean flag to turn on automatic dtmf grammar
generation where as options within fields can not.

Suggested modification: upgrade options so that they are equivalent to
choice and only differ in the treatment of a match (which in the case of
options does not trigger a transition)

Received on Tuesday, 15 October 2002 08:48:44 UTC