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 Saturday, 6 December 2003 14:08:08 UTC