W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2002

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 13 Nov 2002 16:50:38 +0100
Message-ID: <2764A29BE430E64A92EB56561587D2E7108087@se01ms02.i.pipebeach.com>
To: "Guillaume Berche" <guillaume.berche@eloquant.com>, <www-voice@w3.org>

Hi Guillaume, 

Our response to your comments are marked with **VBWG** at the beginning
of the first line. 

Please send your response as soon as possible so we can finalize this
official response.

thanks

Scott


-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, October 15, 2002 11:15
To: Scott McGlashan; www-voice@w3.org
Subject: RE: [dialog] Berche #1, #2, #3 - VBWG official response to
VoiceXML 2.0 Last Call Review Issues


Scott,

Thanks for your response and for processing my change requests even
though
some were submitted outside the review period.

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

Again, I regret that the VBWG's resolutions are not public, not
providing
public reviewers a way to check whether their feedback was properly
integrated (the referenced document "13 September 2002 draft of the
VoiceXML
2.0" not being public)

**VBWG** This is due to the W3C confidentiality rules for non-members.
All I can 
do is make our responses as explicit as possible. I hope my responses
below 
are sufficiently clear.

Except for the following points for which I wish to provide additional
explanation and rationale, I am satisfied with the VBWG's resolutions
provided in the following VBWG responses:
http://lists.w3.org/Archives/Public/www-voice/2002OctDec/0016.html
http://lists.w3.org/Archives/Public/www-voice/2002OctDec/0018.html
http://lists.w3.org/Archives/Public/www-voice/2002OctDec/0020.html

As a general feedback, I find it not always easy to understand the
meaning
of the "VBWG Response: Rejected." statement. Is the suggested text
rejected
for addition in the specs but the interpretation of the specifications
implied by the suggestion correct? Or is it that my interpretation of
the
specification is also rejected by the VBWG?

**VBWG** Generally, it means that your interpretation is rejected: any
wording 
you provide is generally taken as a suggested solution which we evaluate

with other solutions to the same problem. 

Additional comments to response #1
http://lists.w3.org/Archives/Public/www-voice/2002OctDec/0016.html

> [5]
> For completeness and convenience, an extract from section 4.1.5 below
> should
> be reproduced or at least mentionned in section 4.1.8.
> Suggested fix: add the sentence below before "Before the interpreter
> exits
> all ..."
> "As stated in section 4.1.5, when the bargein attribute is false, any
> DTMF
> input buffered in a transition state is deleted from the buffer"
>
> VBWG Response: Rejected.
>
> We didn't see a clear use case or motivation for this change.

The motivation for my comment is that information is spread around in
the
specification. My feedback is that it is often hard to have a good
understanding of the behavior of the language because general behavior
such
as input processing is scattered in different sections. Adding such
cross
references would make the specifications easier to read and understand.
In
the specific case of this request, the section "4.1.8 Prompt Queueing
and
Input Collection" provides a general description of the algorithm and
state
the interpreter uses to process input and play prompts. However it omits
the
description of bargein which impacts both input processing and prompt
queueing.

**VBWG** Accepted. We will add in Section 4.1.8 a cross-reference to
Section 4.1.5.

> [6]
> Concerning ECMAScript variables holding non-scalar values (such as
field
> item variable for a record fieldaudio, or the special _prompt variable
> as
> mentionned in my previous mail)
> - what ECMAScript type do they have? Is it indeed an ECMAScript an
host
> object as defined in the ECMAScript specifications (or Array object
> containing other objects in the case of the _prompt variable). If so,
> what
> is their exact list of properties along with their type and properties
> (ReadOnly, DontEnum, DontDelete, Internal)?. As a side-question, what
> does
> the ECMAScript typeof operator returns on these objects?
>
> Concerning ECMAScript special variables (such as <name>$.<shadow_var>
in
> fields)
> - can they be modified by (of as a side effect of) ECMAScript code
> evaluation (such as evaluating a guard condition, or an expr
attribute)?
>
> Suggested fix: Add a specific section about ECMAScript evaluation.
This
> section could precise runtime error that occur during ECMAScript
> evaluation,
> possible side-effects of ECMAScript evaluation (such as cond attribute
> evaluation), and also the type of shadow variables with the text
below:
> "Shadow variables are host objects as defined in the ECMAScript
> specifications. The properties of these shadow variables are
read-only.
> Any
> attempt by some ECMAScript code evaluation (either in a script element
> or as
> a side effect of the evaluation of an expr attribute) to modify those
> properties will result in an error.semantic to be thrown"
>
> VBWG Response: Rejected Suggested Fix.
>
> Many questions here!
>
> The properties of ECMAScript variables in VoiceXML are not specified
> unless necessary.
>
> With <record>, we have clarified in [5] that its implementation is
> platform-dependent (so different implementations can have different
> ECMAScript properties) but that all must playable by <audio>,
> submittable by <submit> and so on as described in the specification.
>
> For shadow variables, we have clarified in [5] that they are writable,
> so they can be modified.

Can you please detail the motivation behind making shadow variables
writable? I don't quite understand the use-case for having them be
modified
by the application.

**VBWG** Having shadow variables be writable is motivated by the need at

times to post-process the shadow variables.  For instance, the n-best
list of
responses returned can often be filtered by prior information collected.
If
the user was prompted "did you say New York" and the user said "no" it
is
best to filter "New York" out of the n-best list in the next pass.
Given
multiple places in code execution may be referencing the n-best list, it
is
occasionally easier to modify the list directly so that code further
downstream can operate independent of the n-best filter.


Additional comments to response #3
http://lists.w3.org/Archives/Public/www-voice/2002OctDec/0020.html


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


In Section 5.2, last paragraph describing 'as if by copy semantics', the
specification only describes variable resolution and not property
resolution
as the extract below illustrates. This was the point of my change
request.
From your answer I understand that my interpretation is right although
the
suggested changes are considered extra by the VBWG.

Extract from Section 5.2:
"The "as if by copy" semantics for inheriting catch elements implies
that
when a catch element is executed, variables are resolved and thrown
events
are handled relative to the scope where the original event originated,
not
relative to the scope that contains the catch element. For example,
consider
a catch element that is defined at document scope handling an event that
originated in a <field> within the document. In such a catch element
variable references are resolved relative to the <field>'s scope, and if
an
event is thrown by the catch element it is handled relative to the
<field>.
Similarly, relative URL references in a catch element are resolved
against
the active document and not relative to the document in which they were
declared."

**VBWG** Accepted. We will modify the extract from 5.2 so that it is
clear 
that properties, like variables, are resolved relative to the scope
where 
event is thrown (i.e. NOT where the <catch> is defined).


> 1- Precise that Block elements also have a form item [intern prompt
counter]
>
> 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.

I understand the prompt counter is a convenience feature to not require
VXML
authors to use <if> statements relying on ECMAScript variables to select
prompts to play during their execution. I believe that for consistency
of
the specifications, prompts counters should apply in blocks as well as
in
any form item. I don't see any motivation for excluding blocks from
event
counter feature and for adding an exception case in the VXML
specifications.
As the "event counter feature" is a convenience, there are ways to do
the
same thing with more work from VXML authors. I believe that removing the
exception that Blocks have no internal prompt counters would make the
specifications simpler and more consistent with additional benefits to
VXMl
authors.


**VBWG** We believe that the current approach provides a consistent 
treatment of prompts inside fields and catches, and that adding a prompt

counter to <block> at this stage may do more harm than good.

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

Section "5.2 Event Handling", states that "Similarly, relative URL
references in a catch element are resolved against the active document
and
not relative to the document in which they were declared." In addition,
section "5.2.4 Catch Element Selection" states that "Form an ordered
list of
catches consisting of all catches in the current scope and all enclosing
scopes (form item, form, document, application root document,
interpreter
context), ordered first by scope (starting with the current scope), and
then
within each scope by document order."

Consequently, a catch element in a root application with a relative URI
may
be resolved from the xml:base of a leaf document. If no consistency is
enforced between the application and the document whereas logic is
shared
among the two (such as catch elements, or links), this reduces the
benefits
of shared logic provided by application documents.


**VBWG** We are struggling to understand your point. We believe that the
use of
xml:base is clear in the specification. A root document and a leaf
document can have 
different xml:bases by assigning different values to their attributes.
When relative 
URIs are evaluated, they are evaluated together with the xml:base value
of the document 
which contains the active dialog. For example, take a <link> defined in
a root document. 
If the active dialog is in the leaf document, then the leaf's xml:base
would be used; 
if the active dialog is in the root document, then the root's xml:base
would be used.  
This seems to us consistent and coherent.


Any comment on this is welcome. Regards,

Guillaume.

------------------------------------------
Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
guillaume.berche@eloquant.com
------------------------------------------
Received on Wednesday, 13 November 2002 10:52:11 GMT

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