RE: VoiceXML 2.0: Official Response #1 to Candidate Recommendation Issues

Scott,

Thanks for your response and the revised VBWG resolutions that I accept.

Best regards,

Guillaume. 

> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On
> Behalf Of McGlashan, Scott
> Sent: samedi 6 decembre 2003 20:08
> To: Guillaume Berche
> Cc: www-voice@w3.org
> Subject: RE: VoiceXML 2.0: Official Response #1 to Candidate
> Recommendation Issues
> 
> 
> 
> Guillaume,
> 
> Thank you again for your detailed comments on the VoiceXML 2.0. 
> 
> Below are our revised resolutions of the issues you raised in [1] (all
> other issues are taken as accepted). Please let us know as soon as
> possible whether you accept these revised resolutions.
> 
> On the issue of the implementation report testsuite issues, they have
> been discussed within the implementation report team. A revised
> testsuite will be published with the PR version of VoiceXML 2.0. The
> timeframe for publication is given at http://www.w3.org/Voice (although
> there may be a slight delay due to work on other specifications).
> 
> Thanks
> 
> Scott
> 
> [1] http://lists.w3.org/Archives/Public/www-voice/2003OctDec/0055.html
> 
>                        --------------------------- 
> CR5-7: 
> New disposition, making it clearer that we accept your suggested
> modification but don't believe that it is motivated on the basis of your
> rationale but simply that your modification is a good clarification as
> it stands.
> 
> "We accept the suggested modification to 2.3.1.3 concerning the
> description of
> the dtmf attribute based on an alternative rationale; namely, that this
> is good
> clarification independent of the new features you mentioned in your
> rationale."
> 
>                        --------------------------- 
> CR5-8:
> New disposition making it clearer that resolution relative to current
> scope is, as you point out, defined in section 5.1.3. Our concern about
> your suggested modification was only to do with wording in English. 
> 
> "We accept that the clear element should be clarified as your text
> suggests. However, we will modify the wording so that (a) variable
> references
> are resolved relative to the current scope as described in section
> 5.1.3, and
> (b) in the case of initialization, variable references are handled the
> same as
> for other ECMAScript variables."
> 
>                        --------------------------- 
> CR5-10:
> Our problem with your sentence beginning "Note however ..." is that it
> is
> permissable to assign to a property of an object; second example in
> 5.3.2
> makes this clear - <assign name="document.mycost"
> expr="document.mycost+14"/>.
> 
>                        --------------------------- 
> 
> CR5-13: The group needs to discuss this issue further. We will get back
> to you as soon as possible.
>                        --------------------------- 
> 
> CR5-16: Revised disposition 
> "Making them consistent at this stage in the specification is
> problematic. However, we will consider this issue for a future version
> of
> VoiceXML." 
> 
>                        --------------------------- 
> CR6-1: Revised disposition
> "We will modify the specification to make it clear that this is a
> platform-specific issue (i.e. platforms may differ in whether or not
> they discard buffered non-matching DTMF when an ASR grammar matches)."
> 
>                        --------------------------- 
> 
> CR6-2: This is probably a misunderstanding on both sides. In section
> 3.1.1.4, the 
> paragraph beginning "When referencing an external grammar, the value of
> src
> attribute ...", describes which values for the src attribute are
> permitted
> and which are not (the last paragraph of this section). It makes no
> statement
> about inline grammars. In particular, 
> 
> "Local rule reference: a fragment-only URI is not permited. (See
> definition in
> Section 2.2.1 of [SRGS]). A fragment-only URI value for the src
> attribute
> causes an error.semantic event."
> 
> is intended to indicate that it is not permitted to have a fragment-only
> URI
> value for the src attribute in a VoiceXML <grammar> element. 
> 
> The simplest clarification is to start the last paragraph of this
> section  
> "**And** the following are the forms of rule reference defined by [SRGS]
> that
> are not supported in VoiceXML 2.0. ...". Would this be acceptable?
> 
> For <ruleref>s in inline grammars, it is possible to refer rules within
> the same grammar, or an external grammar. What is not possible is to
> reference rules within a different inline grammar in a VoiceXML document
> since the uri is then pointing at a VoiceXML document not a grammar
> document. We believed that is clearly implied by VoiceXML and SRGS
> (especially with the clarification above) and that a separate
> clarfication is not required. Is this acceptable?
> 
>                        --------------------------- 
>  
> CR6-9: It was our intention to make the clarification general. Revised
> disposition.
> "We will modify the specification to clarify that an error.semantic is
> thrown
> when an undeclared variable is referenced, including reference within
> the
> namelist of a submit element (as well as exit, return, and subdialog
> elements)."
> 
>                        --------------------------- 
> 
> CR6-10: We agree with your interpretation - i.e. 'myvar' has the value
> 'dialog' in the log element. 
> 
>                        --------------------------- 
> 
> CR12-2: Revised disposition
> "We will clarify that maxage and maxstale properties are allowed to have
> no default value whatsoever. If the value is not provided by the author,
> and the platform does not provide a default value, then the value is
> undefined and the 'Otherwise' clause of the algorithm applies. All other
> properties must provide a default value (either as given by the
> specification
> or by the platform)."
> 
>                        --------------------------- 
> 
> CR14-1: We assume that you accept our disposition, albeit reluctantly.
> The alternative for you is to reject it and provide some technical
> arguments for your position. 
> 
> 
> 
>

Received on Tuesday, 9 December 2003 04:22:13 UTC