RE: Comments on VXML Candidate Recommendation 28 January 2003 (part 1 + 2)

Dear Guillaume,

Thank you for your comments [2,3] on VoiceXML 2.0 Candidate
Recommendation [1].  We will consider your comments and get back to you
as soon as possible with our official response.

Thanks again,

Scott McGlashan
Leader, Dialog Team, W3C VBWG

[1] VoiceXML 2.0, W3C Candidate Recommendation, 28 January 2003
http://www.w3.org/TR/2003/CR-voicexml20-20030128/

[2] Email from Guillaume Berche to www-voice@w3.org
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0070.html

[3] Email from Guillaume Berche to www-voice@w3.org
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0071.html


-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com] 
Sent: Wednesday, February 12, 2003 14:50
To: www-voice@w3.org
Subject: Comments on VXML Candidate Recommendation 28 January 2003 (part
1)



Hello,

Following are suggestions for clarifications on the VXML Candidate
Recommendation 28 January 2003 (this is actually based on comments that
I made on the April 24, 2002 draft in a mail to the W3C mailing list on
Oct 15, 2002). 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
------------------------------------------


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.4 ENUMERATE":

"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> should be ignored if the expression resolves to
ECMAScript undefined

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 value of 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 can not 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- 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 Wednesday, 12 February 2003 09:40:45 UTC