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: Guillaume Berche <guillaume.berche@eloquant.com>
Date: Wed, 13 Nov 2002 17:35:45 +0100
To: "Scott McGlashan" <scott.mcglashan@pipebeach.com>, <www-voice@w3.org>
Message-ID: <ELEGLIHGLLIBFPCIGAKGAELNDAAA.guillaume.berche@eloquant.com>

Scott,

Thanks for your response and for taking time to process my comments even
when they looked obscure. I've added for reviewers a few words in the text
prefixed with "**GB**" that should not be considered as official comments to
the VXML specifications. Your response is satisfactory to me and you can
officially close this comment.

Thanks again,

Guillaume.

> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On
> Behalf Of Scott McGlashan
> Sent: mercredi 13 novembre 2002 16:51
> To: Guillaume Berche; www-voice@w3.org
> Subject: RE: [dialog] Berche #1, #2, #3 - VBWG official response to
> VoiceXML 2.0 Last Call Review Issues
>
>
>
> 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.

**GB** Your latest responses which quotes the modifications made to the
specs did provide enough details. Thanks!

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

**GB** Thanks this answer clarifies the need to have shadow variables
writable.

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

**GB** I understand. Thanks for processing my comment anyway :-)

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

**GB**

Your answer corrects my understanding of the specifications. I was missing
the part "they are evaluated together with the xml:base value of the
document which contains the **active** dialog". Can you please point me to
the section in the specs which details this?

Since I could not find this information in the specs I misinterpreted them
thinking that such URIs would be resolved from the element that defined them
and thus potentially in the root document.

>
>
> 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 11:34:37 GMT

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