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

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 UTC