- From: McGlashan, Scott <scott.mcglashan@hp.com>
- Date: Wed, 19 Nov 2003 20:33:24 +0100
- To: <guillaume.berche@eloquant.com>
- Cc: <www-voice@w3.org>
The Voice Browser Working Group (VBWG) is now completing its resolution
of
issues raised during the review of the Candidate Recommendation version
of
VoiceXML 2.0 [1]. Our apologies that it has taken so long to respond.
Following the process described in [2] for advancement to Proposed
Recommendation, this is the VBWG's formal response to the issues you
raised.
Please indicate before 26 November 2003 whether you are satisfied with
the
VBWG's resolutions, whether you think there has been a misunderstanding,
or
whether you wish to register an objection.
If you do not think you can respond before 26 November, please let me
know.
The Director will appreciate a response whether you agree with the
resolutions
or not. However, if we do not hear from you at all by 26 November 2003,
we
will assume that you accept our resolutions.
Below you will find a summary of the VBWG's responses to each of your
issues. Please use the issue identifiers when responding.
Thank you,
Scott McGlashan
Co-chair, Voice Browser Working Group
[1] http://www.w3.org/TR/2003/CR-voicexml20-20030220/
[2] http://www.w3.org/2003/06/Process-20030618/
-----------------------------------------------
Issues you raised and VBWG responses
-----------------------------------------------
Issues:
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0070.html
CR5-1, CR5-2, CR5-3, CR5-4, CR5-5, CR5-6, CR5-7, CR5-8,
CR5-9, CR5-10, CR5-11, CR5-12, CR5-13, CR5-14, CR5-15, CR5-16
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0071.html
CR6-1, CR6-2, CR6-3, CR6-4, CR6-5, CR6-6, CR6-7, CR6-8,
CR6-9, CR6-10, CR6-11, CR6-12, CR6-13
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0091.html
CR12-1, CR12-2, CR12-3
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0099.html
CR14-1, CR14-2
Issue CR5-1
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.**"
CR5-1 Resolution: accepted with modifications
We accept the suggested text but will re-word it more precisely (e.g.
'_dtmf' instead of '_prompt').
-----------------------------------------------
Issue CR5-2
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.**"
CR5-2 Resolution: rejected
If no explicit id is specified, then the developer is not interested in
referring to the form or menu element. Whether or not the platform
generates an internal name is a vendor-specific issue.
-----------------------------------------------
Issue CR5-3
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."
CR5-3 Resolution: rejected
As pointed out, the developer can always write explicit code to check
the value of variables. The value of providing a 'convenience'
interpretation is not clear to us.
-----------------------------------------------
Issue CR5-4
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."
CR5-4 Resolution: rejected
Having considered various alternatives including your suggestion, the
group felt that at this stage in the process it is better to leave the
behavior undefined and thereby platform-specific. A later version of
VoiceXML may provide a more optimal solution.
-----------------------------------------------
Issue CR5-5
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."
CR5-5 Resolution: accepted with modifications
We will modify the specification so that in the situation where neither
CDATA content nor a dtmf sequence is specified, then the default for the
value attribute is undefined and the form field item is not filled.
-----------------------------------------------
Issue CR5-6
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)"
CR 5-6 Resolution: accepted with modifications
The specification will be modified so that the format of _dtmf is a
normalized representation of the dtmf sequence (i.e. single whitespace
between DTMF tokens).
-----------------------------------------------
Issue CR5-7
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?
CR5-7 Resolution: accepted with modifications
We accept the suggested modification to 2.3.1.3 concerning the
description of the dtmf attribute. We reject the rationale that option
should allow automatically generated dtmf sequences.
-----------------------------------------------
Issue CR5-8
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."
CR5-8 Resolution: accepted with modifications
We accept that the clear element should be clarified as your text
suggests. However, we will modify the wording so that (a) variable
references are resolved relative to the current scope, and (b) in the
case of initialization, variable references are handled the same as for
other ECMAScript variables.
-----------------------------------------------
Issue CR5-9
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.**"
CR5-9 Resolution: accepted with modifications
We accept the suggestion but will modify the text style for consistency
with the rest of the document.
-----------------------------------------------
Issue CR5-10
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."
CR5-10 Resolution: accepted with modifications
We accept the suggested text modification but not the final line
beginning "Note however".
-----------------------------------------------
Issue CR5-11
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."
CR5-11 Resolution: accepted with modifications
We accept the clarification of 'optional' but not the last paragraph
describing the order of evaluation - the order is already specified as
document order.
-----------------------------------------------
Issue CR5-12
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)."
CR5-12 Resolution: accepted with modifications
We accept the suggested clarification of 'dtmfterm' attribute, but
reject the suggested priority order when both the attribute and local
grammars are specified. That is, we maintain that the dtmfterm attribute
has priority over local grammars. Developers who want full control can
omit the dtmf attribute and write their own local grammar.
-----------------------------------------------
Issue CR5-13
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."
CR5-13 Resolution: rejected
The comments no longer applies since, following analysis of
implementation reports, the specification will no longer allow speech
recognition during recording (no supporting implementations).
-----------------------------------------------
Issue CR5-14
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.**"
CR5-14 Resolution: rejected
The default value of the maxtime attribute is already specified as
platform-dependent (see Table 16).
-----------------------------------------------
Issue CR5-15
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>
"
CR5-15 Resolution: accepted with modifications
We accept that clarification is required but not the proposed
modification. We will clarify in 4.1.2 that for cases where prompt
content is specified without prompt element then attributes are defined
as specified in table 33.
-----------------------------------------------
Issue CR5-16
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)
CR5-16 Resolution: rejected
We see no value in making them consistent.
-----------------------------------------------
Issue CR6-1
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.
CR6-1 Resolution: rejected
This is a platform-specific issue and is outside the scope of the
specification.
-----------------------------------------------
Issue CR6-2
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?
CR6-2 Resolution: accepted
One such reason is that some interpreters will not have processed the
inline SRGS grammars that aren't involved with the current recognition
cycle. For instance imagine:
<vxml version="2.0">
<form>
<field name="a">
<!-- inline foo grammar -->
<grammar>
<!-- inline ref to grammar bar -->
</grammar>
</field>
</form>
<form>
<field name="a">
<!-- inline bar grammar -->
<grammar>
...
</grammar>
</field>
</form>
</vxml>
Another concern is that it isn't currently possible to name grammar
tags, and as such there isn't a consistent way to reference another
inline grammar in the file (as evidenced by the inline comment naming
scheme). Another concern is that we wish to make resource requests of
grammar in this way similar to script tags. It isn't possible today to
have an inline script tag local to one form but then have a later form
use an inline fragment to include the inline script. For all of these
concerns we've decided to not accept local rulerefs in inline SRGS
grammars. No changes will be made to the specification.
-----------------------------------------------
Issue CR6-3
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.
CR6-3 Resolution: rejected
This is a common problem with using ids on elements from multiple
namespaces within the same document. The W3C Schema working group are
aware of the problem and we may be able to provide a better solution in
future versions of VoiceXML.
-----------------------------------------------
Issue CR6-4
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."
CR6-4 Resolution: rejected
We believe it is already precise: a document to transition to without
dialog is not valid, so an error.badfetch is thrown as already stated in
5.3.7.
-----------------------------------------------
Issue CR6-5
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)**"
CR6-5 Resolution: rejected
As stated in 5.3.5 the count attribute on prompts in executable content
is meaningless.
-----------------------------------------------
Issue CR6-6
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**"
CR6-6 Resolution: accepted
We will apply the suggested modification.
-----------------------------------------------
Issue CR6-7
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"/>"
CR6-7 Resolution: accepted
We will correct the typo.
-----------------------------------------------
Issue CR6-8
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.
CR6-8 Resolution: accepted
Your understanding is correct. No modifications will be made to the text
since we believe this is sufficiently clear already.
-----------------------------------------------
Issue CR6-9
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**"
CR6-9 Resolution: accepted with modifications
We will modify the specification to clarify that an error.semantic is
thrown when an undeclared variable is referenced, including reference
within the namelist of a submit element.
-----------------------------------------------
Issue CR6-10
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)
CR6-10 Resolution: accept with modifications
We reject the suggested correction, but accept that a clarification is
required in the definition of dialog scope, namely, that form element
item names are being referred to.
-----------------------------------------------
Issue CR6-11
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."
CR6-11 Resolution: accepted
We will apply the suggested correction.
-----------------------------------------------
Issue CR6-12
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). "
CR6-12 Resolution: accepted
We will modify the text so that the second sentence reads "This can
occur, for example, when DTMF or speech input is received during prompt
playback or *before* the timeout interval *expires* ..."
-----------------------------------------------
Issue CR6-13
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.
CR6-13 Resolution: accepted
No action since this document will be replaced by a CR disposition of
comments document.
-----------------------------------------------
Issue CR12-1
1- precise behavior when only activated grammars are disabled by
"inputmodes"
property
In the following example, what is the expected behavior? Should an
error.semantic be thrown as would if no grammar was activated as
described in
section "3.1.4 Activation of Grammars"? Should the grammars considered
rather
as activated but would not match as described in section "6.3.6
Miscellaneous
Properties" (inputmodes property) ", and thus lead to a nomatch event to
be
thrown?
Section "3.1.4 Activation of Grammars" states that "If no grammars are
active
when an input is expected, the platform must throw an error.semantic
event".
Section "6.3.6 Miscellaneous Properties" states that "For instance,
voice-only
grammars may be active when the inputmode is restricted to DTMF. Those
grammars would not be matched, however, because the voice input modality
is
not active. "
<menu>
<prompt>
Choose wind speed and after temperature then finaly ask for
leave choice test.
</prompt>
<choice next="#exacte_rain"> rain humidity </choice>
<choice next="#approx_wind"> wind speed </choice>
<choice next="#approx_weat">temperature celcius</choice>
<choice next="#exacte_leave">Leave choice test </choice>
</menu>
Suggested modification to Section "6.3.6 Miscellaneous Properties"
(inputmodes
definition) "[..] For instance, voice-only grammars may be active when
the
inputmode is restricted to DTMF. Those grammars would not be matched,
however,
because the voice input modality is not active. If among all grammars
active
none can be matched because their associated input modality is not
enabled,
then a nomatch event is thrown."
CR12-1 Resolution: rejected
Your question is not very clear but given a menu with active speech
grammars and no user input, then a noinput event would be thrown. This
also applies if the input mode is set to dtmf only; an error.semantic
event would not thrown since the statement in 3.1.4 only applies when
there are no active grammars - and there are active grammars in this
example, even though their input mode is disabled. In essence, grammar
activation is separate from input mode activation.
-----------------------------------------------
Issue CR12-2
2- out-of-date fetching algorithm: maxage defaults to property value
Section "6.1.2 Caching" specifies the following:
"[...]
If a maxage value is provided,
[...]
Otherwise,
If the resource has expired,
Perform maxstale check.
Otherwise, use the cached copy."
I understand that the predicate "If a maxage value is provided" is
always
true, as there are default values for the different maxage properties
(audiomaxage, documentmaxage, grammarmaxage, objectmaxage,
scriptmaxage...) as
specified in section "6.3.5 Fetching Properties"
Suggested modification to section "6.1.2 Caching": remove the "If a
maxage
value is provided, " part and the corresponding "otherwise" statement.
CR12-2 Resolution: rejected
'Provided' is equivalent to specified in this context: i.e. while there
is always a platform-specific value, it is not always the case that a
value is provided or specified in the document.
-----------------------------------------------
Issue CR12-3
3- schema forbids empty catch event name
Section "5.2.4 Catch Element Selection " specifies the following "The
name of
a thrown event matches the catch element event name if it is an exact
match, a
prefix match or the catch event name is not specified. A prefix match
occurs
when the catch element event attribute is a token prefix of the name of
the
event being thrown, where the dot is the token separator, all trailing
dots
are removed, and the empty string matches everything. "
However, the schema forbids an empty string event specification as
illustrated below:
<xsd:element name="catch">
<xsd:complexType>
<xsd:complexContent mixed="true">
<xsd:extension base="basic.event.handler">
<xsd:attribute name="event"
type="EventNames.datatype"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="EventNames.datatype">
<xsd:annotation>
<xsd:documentation>space separated list of
EventName.datatype</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:NMTOKENS"/>
</xsd:simpleType>
The schema specifications
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NMTOKENS) defines
NMTOKENS as the following:
"3.3.5 NMTOKENS
[Definition:] NMTOKENS represents the NMTOKENS attribute type from
[XML
1.0 (Second Edition)]. The value space of NMTOKENS is the set of finite,
non-zero-length sequences of NMTOKENs."
CR12-3 Resolution: accepted with modifications
We will modify the description in 5.2.4 to make it clearer that event
names cannot be empty strings (i.e. event="" is illegal) but can be
unspecified (i.e. <catch> ....) and can prefix match when dots are
removed (e.g. event="." will match any event).
-----------------------------------------------
Issue CR14-1
1- Precise that timeout attribute of the <prompt/> element only applies
if
the prompt element is not empty
The <prompt> element is designed to queue prompt element for play. As a
side
effect it also set the timeout for the next input collection. However,
the
specifications do not describe the expected behavior if the prompt
element
is empty: should tghe side-effect still apply? This would make little
sense:
this would be a synonym for a "set next timeout" command without
queueing
any prompt.
Suggested addition to section "4.1 Prompts":
"Note that an empty prompt such as "<prompt [...]/>" will be silently
ignored and in particular would not set the timeout of the next input
collection phase"
Dependency: IR testsuite case #539 (389/389.vxml)
CR14-1 Resolution: rejected
The timeout property applies as normal even if there is no content in
the prompt.
-----------------------------------------------
Issue CR14-2
2- Precise behavior if "cond" attribute of form item does not resolve
into
an EcmaScript boolean value
The VXML specification state the following in section "2.1.3 Form Item
Variables and Conditions":
"cond An expression to evaluate in conjunction with the test of the
form
item variable. If absent, this defaults to true, or in the case of
<initial>, a test to see if any input item variable has been filled in."
However, the specifications do not detail the expected behavior if the
expression does not resolve to a boolean.
Suggested modification to "2.1.3 Form Item Variables and Conditions"
"cond An expression to evaluate in conjunction with the test of the
form
item variable. If absent, this defaults to true, or in the case of
<initial>, a test to see if any input item variable has been filled in.
If
the evaluation of the expression results into an error or does not
resolve
into an ECMAScript boolean value, then an error.semantic event is
thrown."
CR14-2 Resolution: rejected
In the specific description of cond attributes it states that it is "An
expression that must evaluate to true after conversion to boolean in
order for the form item to be visited". Boolean conversion of an
ECMAScript expression always returns either true or false.
-----------------------------------------------
Received on Wednesday, 19 November 2003 14:33:28 UTC