RE: More VXML specs comments and suggestions

Guillaume,

thank you for your comments. I will add these to our change request
process. I cannot guarantee that they will be address immediately since
they were not received within the official comment period - however,
they will be addressed at some stage and we will discuss with you
directly our response. 

I cannot provide information about the next release of VoiceXML 2.0 on a
public mailing list since it would violate W3C Member Confidentiality. 

thanks

Scott
VoiceXML dialog team leader, VBWG

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, September 03, 2002 16:04
To: Scott McGlashan; www-voice@w3.org
Subject: More VXML specs comments and suggestions


Scott,

Following are additional suggestions for clarifications on the VXML 2.0
W3C
Working Draft from 24 April 2002. Do you have insights about when the
working group would provide feedback on the comments/clarification
requests
made to this list as well as the expected release date of the next
specification version?


0- Precise the property scope from which executables within catch
elements
are evaluated.

For instance, would a prompt element in a document-level catch element
use
the PropertyScope of the document or the active element at the time the
event is handled?

Suggested text addition to section "5.3 Executable Content":
"Note that the property scope in which default values are resolved is
the
property scope of the active element at the time the executable content
is
executed. For example, a prompt element executed as the result of a
document-level catch element would use the PropertyScope of the active
element to resolve the "timeout" property if no "timeout" attribute was
specified in the Prompt itself"


1- Precise that Block elements also have a form item

Block elements may be executed more than once without clearing their
prompt
counters through their transition using a goto element. Consequently, it
seems logical that they have a prompt counters like any form item. In
addition, this removes an unnecessary exception statement in the specs
and
uniformises definition of form items.

Suggested text modification to section "4.1.6 Prompt Selection":
"Each form item 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."


2 - Precise which prompt counter to use when handling a runtime error
while
in the FIA selection phase?

While in the FIA selection phase, no form item is currently active.
However,
if a runtime error occurs (such as during the evaluation of a cond
attribute), prompts may be played by catch elements. Which prompt
counter
would then be used?

Suggested text modification to section "4.1.6 Prompt Selection":
"Each form item 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. Note that when a prompt is used while no
form
item or menu is active, the current prompt counter value is one. This
condition may happen when a runtime error occurs while the FIA is in the
selecting phase (e.g. the cond expr of a form item generates an
ECMAScript
evaluation expression error)"


3- Typo: Invalid cross-reference in "1.4 VoiceXML Elements"

The <block> element is defined in section "2.3.2 BLOCK" and not "2.3.1
FIELD"


4- Precise behavior if an unsupported built-in grammar is referenced in
a
document

Suggested text addition to section "2.3.1 FIELD":
"type: The type of field, i.e., the name of a builtin grammar type (see
Appendix P). Platform support for builtin grammar types is optional. If
the
specified built-in type is not supported by the platform, an
error.unsupported.format event will be thrown. In this case, <grammar>
elements can be specified instead."


5- Precise behavior for unsupported language defined in xml:lang
attribute
of <vxml>

Suggested text modification to section "1.5.1 Execution within One
Document":
"xml:lang    The language identifier for this document as defined in
[RFC3066]. If omitted, the value is a platform-specific default.
When an unsupported language is requested, the platform throws an
error.unsupported.language event which specifies the unsupported
language in
its message variable."


6- Precise the event thrown when an invalid property value is assigned.

The section "6.3 Property" usually specifies the valid values for a
property. However, it does not specify the behavior of the browser if a
invalid value is specified in a property value. Since the schema does
not
provide validation support for property values, it seems important to
specify the browser behavior in such a condition (for instance if the
bargein property is assigned to the value "maybe")

Suggested text addition to section "6.3 Property":
"If a property element provides a value that falls outside of the set of
valid values specified for the corresponding property name in this
section,
an error.badfetch event is thrown at document initialization."


7- Precise that a field with a built-in type may contain additional
nested
grammar elements

I believe it can make much sense on real applications to define a field
with
one of the built-in type and have in addition other grammars that can
match.
One possible example is to complete a platform built-in grammar with
alternative tokens (e.g. for boolean complete with "sure", "of course"
and
associate them with the "true" tag value)

Suggested text addition to section "2.3.1 FIELD" (at the end of the type
attribute definition):
"When this attribute is defined, use of nested grammar elements is still
legal and can possibly be used to extend the built-in grammar with
application-specific tokens (e.g. for boolean complete with "sure", "of
course" and associate them with the "true" tag value)."


8- Precise and uniformize units for time values

The timeout attribute specification of the Prompt element does not
specify a
unit, nor does the timeout property. It seems desirable to me add
cross-reference to section "6.5 Time Designations" to precise the
ambiguity.
The ambiguity is made stronger by the fact that some properties
representing
time [intervals] do not conform to section "6.5 Time Designations": this
is
the case for the maxstale and maxage.

There are numerous time designation in the specs. Following are two
examples
of modifications that would clarify time units.

Suggested text modification to section "4.1.7 Timeout":

"The timeout attribute is a time designation as specified in section
"6.5
Time Designations" which specifies the interval of silence allowed while
waiting for user input after the end of the last prompt."

Suggested text modification to section "6.1.1 Fetching":

fetchtimeout:      The interval to wait (as specified in section "6.5
Time
Designations") ...
maxage:            Indicates that the document is willing to use content
whose age is no greater than the specified time (in the format specified
in
section "6.5 Time Designations") ...
maxstale:          Indicates that the document is willing to use content
that has exceeded its expiration time (in the format specified in
section
"6.5 Time Designations") ...


9- Precise the semantic for the "xml:lang" attribute of Prompt elements

It is not clear how the xml:lang attribute of the Prompt element
integrates
with the xml:lang attributes in nested SSML markup such as in paragraph
or
sentence.

Suggested text modification to section "4.1 Prompts":
"xml:lang        The language identifier as defined in [RFC3066]. If
omitted, it defaults to the value specified in the document's "xml:lang"
attribute. For speech output, this attribute has the same semantics as
the
SSML xml:lang attribute. Refer to SSML section "2.1.2 "xml:lang"
Attribute:
Language". For audio output, this attribute is ignored.


10- Precise the behavior of queued prompts when a prompt fails to be
played.

In the current specs, prompts are queued during the transitionning
phase.
Then during the waiting phase, they start being played. It seems unclear
how
the browser should react to a prompt which can not be played (e.g. an
unsupported language, or an audio prompt which can not be fetched and
without alternative prompt): an event would be thrown, however the
following
questions remain:
a- does the interpreter enter the transitionning phase?
b- do remaining prompts get played?

I believe that the answer to a) is yes, and answer to b) is no because
otherwise partial audio would be delivered to the end-user, without the
application being able to control it in any way.

Suggested text modification to section "4.1.8 Prompt Queueing and Input
Collection":
- when a prompt fails to be played, the appropriate event is thrown
(such as
error.badfetch, error.unsupported.format, or error.unsupported.language
)
and the interpreter enters the transitionning phase. The remaining
prompts
do not get played. As described in section "4.1.3 Audio Prompting",
events
thrown as a result of failed prompts are not designed to support
programmatic recovery from the application.


11- Comment on issue concerning Grammar mode attribute in section
"3.1.1.4
Grammar Element"

I believe that this attribute should be ignored for external grammars.
This
is because a default value in SRGS exists, and as noted in the case a
mode
value is provided in the grammar, conflict can occur.

Suggested text modification to section "3.1.1.4 Grammar Element":
"mode         Defines the mode of the contained grammar following the
modes
of the W3C Speech Recognition Grammar Specification [SRGS]. Defined
values
are "voice" and "dtmf" for DTMF input. If the mode value is in conflict
with
the mode of the grammar itself, a "badfetch" event is thrown. This
attribute
is ignored for referenced grammars."


12- Enforce consistency among "xml:base" attribute of application and
document and precise precedence order.

Suggested text modification to section "1.5.1 Execution within One
Document":
"xml:base    The base URI for this document as defined in [XML-BASE]. As
in
[HTML], a URI which all relative references within the document take as
their base. If both the root application and the leaf document define an
"xml:base" attribute and the values for this attribute if different then
an
error.semantic event is thrown. If either the root application or the
leaf
document define the xml:base attribute, then it becomes the base URI for
the
current document. If the xml:base attribute is defined in neither root
application nor leaf document, then the root and leaf documents must be
loaded from URIs with the same base, otherwise an error.semantic event
is
thrown."

Rationale: it may be difficult for VXML authors to develop VXML
applications
in which the base URI is different for the root than for the leaf. This
is
because links defined in the application are active while the leaf is
active. Therefore, relative URIs in root-defined links would probably
fail
if activated while the leaf is active. Consequently, not enforcing
consistent base URIs prevents such root documents to use relative URIs
since
their leaf documents might override it.



13- Preventing use of caches for submit requests

I believe that the following sentence in section "5.3.8 SUBMIT" is
dangerous
and not consistent with the described intent of the submit element.

"Note that although the URI is always fetched and the resulting document
is
transitioned to, some <submit> requests can be satisfied by intermediate
caches. This might happen if the method is "get", the namelist is empty,
there is no query string in the URI, and the application and the origin
web
server both allowed the document to be cached."

The submit element is designed to expressly communicate with the origin
server as stated in section "5.3.8 SUBMIT": "The <submit> element is
used to
submit information to the origin web server and then transition to the
document sent back in the response."

I therefore believe that <submit> elements should never be satisfied by
intermediate caches. I don't see any real-life case in which this would
be
desirable. This would lead to situations were the cached pages would be
transitionned to while the URI fetching might fail later on.

A submit request with get request, empty namelist, no query string in
the
URI should logically use a goto rather than a submit. A cached submit
request might also be dangerous for VXML browser supporting persistent
HTTP
Header such as cookies, because the remote server may expect to maintain
session information and may rely on receiving the submit request even if
it
always provides the same result page back.

Suggested text modification to section "5.3.8 SUBMIT":
"Note that the URI is always fetched, the resulting document is
transitioned
to, and no <submit> requests should ever be satisfied by intermediate
caches. VXML authors willing to have such behavior should rather use a
goto
element."


I hope this feedback can help. Any comment on this is welcome.

Thanks,

Guillaume.

Received on Thursday, 5 September 2002 08:01:32 UTC