RE: Comments on VoiceXML Version 2.0 Implementation Report (Version: Jan 23, 2003)

Hi Guillaume,

Thanks for the comments on the VoiceXML 2.0 implementation. I'll pass
your comments onto the implementation report team. 

Thanks

Scott



-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com] 
Sent: Thursday, March 27, 2003 09:20
To: www-voice@w3.org
Subject: Comments on VoiceXML Version 2.0 Implementation Report
(Version: Jan 23, 2003)



Hello,

First I would like to thank the W3C for making the VXML IPR report
available, I believe it will greatly help in making VXML implementations
compatible and enhancing the VXML specifications.

Please find below comments on the VXML VoiceXML Version 2.0
Implementation Report (Version: Jan 23, 2003)
http://www.w3.org/Voice/2003/ir/voicexml20-ir.html based on the VXML 2.0
Candidate Recommendation  20 February 2003.

Let me know if more details would be useful, or please point me to the
appropriate VXML specifications section if I missed it. I hope these
comments can help.

Thanks and best regards,

Guillaume.

------------------------------------------
Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
guillaume.berche@eloquant.com
-----------------------------------------




1- case #0059 (file 453/453.vxml):

Here is the extract of the VXML specifications concerning event handler
selection:
"When an event is thrown, the scope in which the event is handled and
its enclosing scopes are examined to find the best qualified catch
element, according to the following algorithm:

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.
Remove from this list all catches whose event name does not match the
event being thrown or whose cond evaluates to false after conversion to
boolean. Find the "correct count": the highest count among the catch
elements still on the list less than or equal to the current count
value. Select the first element in the list with the "correct count". "



When handling the event "xyz.mno.rst", the current count of the
different event subparts (as specified in table 41 as reproduced below)
is as follow:

- xyz.mno.rst =1
- xyz.mno =1
- xyz =2

The list of catches with their associated count is therefore at the end
of step 3:
- <catch event="xyz"> (count=1) currentcount=2 (current count for the
xyz
part)
- <catch> (count=1) currentcount=1 (current count for the xyz.mno.rst
part)

For step4, the 2nd element is selected since count==currentCount

Extract from table 41:
"Counters are incremented against the full event name and every prefix
matching event name; for example, occurrence of the event "event.foo.1"
increments the counters for "event.foo.1" plus "event.foo" and "event".
"

As a result, I believe that the test case #0059 generates a false
positive with the message "fail doc-scoped catch-all caught xyz.mno.rst"




2- IR test suite test case #858 (237/237.txml) and #1085
(1032/1032.vxml)

The target test specification item is the following "If the cond
attribute is present and its value evaluates to boolean false, the field
is not visited." However, the tests try to respectively resolve the
value "NaN" and "'iConvertToTrue'" as the boolean value. This does not
resolve into a Boolean value, and the VXML specifications are unclear
about the expected behavior in this case.

A clarification request on this point was submitted to the W3c. As a
result, I believe that these test cases assert an unspecified behavior
of the VXML specifications.



3- test case #860 255/255.vxml

The VXML specifications in section "2.3.1.3. Fields Using Option
Lists","Table 11" state the following:

"value The string to assign to the field's form item variable when a
user selects this option, whether by speech or DTMF. The default
assignment is the CDATA content of the <option> element with leading and
trailing white space removed. If this does not exist, then the DTMF
sequence is used instead. "

However, the test case #860 255/255.vxml is assuming that this implies
that an implicit grammar with a semantic interpretation assigning a
string litteral with the content of the value attribute of the option
element. I believe this assumption is invalid as other implementation
may conform to the VXML specifications without conforming to this
assumption.

Suggested modification to test case #860: only assert that the field's
form item variable is assigned when the option is selected and not that
the name$.interpretation and the
application.lastresult$[0].interpretation are also assigned this same
value.



4- test cases #1227 (1027/1027.vxml), #1228 (1034/1034.vxml), #1230
(1039/1039.vxml)

The VXML specifications in section "2.3.5. OBJECT" state that:

"There is no requirement for implementations to provide
platform-specific objects, although implementations must handle the
<object> element by throwing error.unsupported.objectname if the
particular platform-specific object is not supported. If an
implementation does this, it is considered to be supporting the <object>
element. "

However, the test cases makes the assumption that "<object name="a"
expr="'dontVisitMe'"/>" would assign always assign the variable "a",
overlooking conformant implementation that would throw an
error.unsupported.object event.

Suggested modification to test case #1227: use "<block name="a"
expr="'dontVisitMe'"/>" instead of "<object name="a"
expr="'dontVisitMe'"/>"

Received on Friday, 28 March 2003 06:11:09 UTC