W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2002

More VXML specs comments and suggestions

From: Guillaume Berche <guillaume.berche@eloquant.com>
Date: Tue, 3 Sep 2002 16:03:45 +0200
To: <scott.mcglashan@pipebeach.com>, <www-voice@w3.org>
Message-ID: <ELEGLIHGLLIBFPCIGAKGAEFACOAA.guillaume.berche@eloquant.com>

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 Tuesday, 3 September 2002 10:04:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:56 GMT