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 Thursday, 27 March 2003 03:15:00 UTC