W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2003

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

From: McGlashan, Scott <scott.mcglashan@hp.com>
Date: Sat, 6 Dec 2003 20:08:06 +0100
Message-ID: <77DB1374F763FB489900AA600DA37AE10356361F@frqexc01.emea.cpqcorp.net>
To: "Guillaume Berche" <guillaume.berche@eloquant.com>
Cc: <www-voice@w3.org>


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



[1] http://lists.w3.org/Archives/Public/www-voice/2003OctDec/0055.html

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

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

Our problem with your sentence beginning "Note however ..." is that it
permissable to assign to a property of an object; second example in
makes this clear - <assign name="document.mycost"


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

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, the 
paragraph beginning "When referencing an external grammar, the value of
attribute ...", describes which values for the src attribute are
and which are not (the last paragraph of this section). It makes no
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
causes an error.semantic event."

is intended to indicate that it is not permitted to have a fragment-only
value for the src attribute in a VoiceXML <grammar> element. 

The simplest clarification is to start the last paragraph of this
"**And** the following are the forms of rule reference defined by [SRGS]
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
"We will modify the specification to clarify that an error.semantic is
when an undeclared variable is referenced, including reference within
namelist of a submit element (as well as exit, return, and subdialog


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:37 UTC