RE: [dialog] Berche #3 - VBWG official response to VoiceXML 2.0 Last Call Review Issues

The Voice Browser Working Group (VBWG) has almost
finished resolving the issues raised during the last call
review of the 24 April 2002 VoiceXML 2.0 [1]. Our apologies that 
it has taken so long to respond.

Although your comments were received outside the review period,
this is the VBWG's formal response to the issues you raised,
which have been logged in the Working Group's issues list [4].
The VBWG's resolutions have been incorporated into the 13 September
2002 draft of the VoiceXML 2.0 [5]. 

Please indicate before 18 October 2002 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 18 October, please let me
know. The Director will appreciate a response whether you agree
with the resolutions or not.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's responses to each of your issues.

Thank you,

Scott
Co-Chair, VBWG

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 5.2.3 [2] of the 19th July 2001 Process Document, in
order for the VoiceXML 2.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:

  "In the context of this document, a Working Group has formally
  addressed an issue when the Chair can show (archived) evidence
  of having sent a response to the party who raised the
  issue. This response should include the Working Group's
  resolution and should ask the party who raised the issue to
  reply with an indication of whether the resolution reverses the
  initial objection."

If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.

If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. 

[1] http://www.w3.org/TR/2002/WD-voicexml20-20020424/
[2] http://www.w3.org/Consortium/Process-20010719/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010719/groups.html#WGVotes
[4] http://www.w3.org/Voice/Group/2002/voiceXML-change-requests.htm
(members only)
[5] http://www.w3.org/Voice/Group/2002/WD-voicexml20-20020913.htm
(members only)
(http://www.w3.org/Voice/Group/2002/WD-voicexml20-20020913.zip) (members
only)


-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------

In http://lists.w3.org/Archives/Public/www-voice/2002JulSep/0058.html
you raised the following issues registered as dialog change request
R519 respectively. Our response is given inline after each issue.

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"

VBWG Response: Rejected.

We believe that the text is already sufficiently explicit on this issue
- see Section 5.2, last paragraph describing 'as if by copy semantics'. 


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."

VBWG Response: Rejected.

Multiple blocks can achieve the same purpose. No clear use case is
offered for this change.

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)"

VBWG Response: Rejected.

The prompt counter would default to 1. 


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"

VBWG Response: Accepted.

Edit applied in current specification [5].

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."

VBWG Response: Accepted.

The next version will contain an "error.unsupported.builtin" error type
for this purpose; "_msg" can provide more information such as builtin
type. 


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."


VBWG Response: Rejected.

Platform only rejects language at the point it is used in a prompt or
grammar in the document.

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."

VBWG Response: Accepted.

If a platform detects that the value of a legal property name is
illegal, then it should throw an error.semantic (some platforms may deal
with this situation by using an appropriate default value). 


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)."

VBWG Response: Accepted.

Already fixed in [5] due to earlier change request.


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") ...

VBWG Response: Accepted.

Already applied in [5] due to other change requests. Not that maxage and
maxstale are derived from HTTP 1.1 and are clearly integers indicating
seconds. We see no reason to coerce these into CSS2 time durations.


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.


VBWG Response: Rejected.

This is already clear -- we don't see any confusion.


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.

VBWG Response: Accepted.

Already fixed in [5] due to earlier change requests.


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."

VBWG Response: Accepted.

Already fixed in [5] due to earlier change requests.

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.

VBWG Response: Rejected.

xml:base is by definition a document-oriented concept, not an
application-oriented concept. 

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."

VBWG Response: Accepted.

We are currently investigating similar clarification on the wording in
this section. 


-------------------
Scott McGlashan
 
PIPEBEACH
Box 24035/Linnégatan 89 B, 7tr
SE-104 50 Stockholm, Sweden
fax:       +46 8 54590993
office:    +46 8 54590990



www.pipebeach.com

Received on Wednesday, 9 October 2002 12:23:37 UTC