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)

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?


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.


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



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


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


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



Any comment on this is welcome. Regards,

Guillaume.

------------------------------------------
Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
guillaume.berche@eloquant.com
------------------------------------------

Received on Tuesday, 15 October 2002 05:15:05 UTC