RE: Comments on VXML Candidate Recommendation 20 February 2003

Dear Guillaume,

Thank you for your comments [2] on VoiceXML 2.0 Candidate Recommendation
[1]. 

We will review your comments in the group and get back to you as soon as
possible with our official response.

Thanks again,

Scott McGlashan
Co-Chair VBWG

[1] VoiceXML 2.0, W3C Candidate Recommendation, 20 February 2003
http://www.w3.org/TR/2003/CR-voicexml20-20030220/

[2] Email from Guillaume Berche to www-voice@w3.org 
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0091.html




-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com] 
Sent: Thursday, March 13, 2003 08:45
To: www-voice@w3.org
Subject: Comments on VXML Candidate Recommendation 20 February 2003



Hello,

Following are additional suggestions for clarifications on the VXML
Candidate Recommendation  20 February 2003. Let me know if more detail
would be useful, or please point me to the appropriate 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- precise behavior when only activated grammars are disabled by
"inputmodes" property

In the following example, what is the expected behavior? Should an
error.semantic be thrown as would if no grammar was activated as
described in section "3.1.4 Activation of Grammars"? Should the grammars
considered rather as activated but would not match as described in
section "6.3.6 Miscellaneous Properties" (inputmodes property) ", and
thus lead to a nomatch event to be thrown?


Section "3.1.4 Activation of Grammars" states that "If no grammars are
active when an input is expected, the platform must throw an
error.semantic event".

Section "6.3.6 Miscellaneous Properties" states that "For instance,
voice-only grammars may be active when the inputmode is restricted to
DTMF. Those grammars would not be matched, however, because the voice
input modality is not active. "

<menu>
         <prompt>
	   Choose wind speed and after temperature then finaly ask for
leave choice test.
         </prompt>
	 <choice next="#exacte_rain"> rain humidity </choice>
	 <choice next="#approx_wind"> wind speed </choice>
	 <choice next="#approx_weat">temperature celcius</choice>
	 <choice next="#exacte_leave">Leave choice test </choice>
</menu>

Suggested modification to Section "6.3.6 Miscellaneous Properties"
(inputmodes definition) "[..] For instance, voice-only grammars may be
active when the inputmode is restricted to DTMF. Those grammars would
not be matched, however, because the voice input modality is not active.
If among all grammars active none can be matched because their
associated input modality is not enabled, then a nomatch event is
thrown."



2- out-of-date fetching algorithm: maxage defaults to property value

Section "6.1.2 Caching" specifies the following:

"[...]
If a maxage value is provided,
[...]
Otherwise,
If the resource has expired,
Perform maxstale check.
Otherwise, use the cached copy."

I understand that the predicate "If a maxage value is provided" is
always true, as there are default values for the different maxage
properties (audiomaxage, documentmaxage, grammarmaxage, objectmaxage,
scriptmaxage...) as specified in section "6.3.5 Fetching Properties"

Suggested modification to section "6.1.2 Caching": remove the "If a
maxage value is provided, " part and the corresponding "otherwise"
statement.



3- schema forbids empty catch event name

Section "5.2.4 Catch Element Selection " specifies the following "The
name of a thrown event matches the catch element event name if it is an
exact match, a prefix match or the catch event name is not specified. A
prefix match occurs when the catch element event attribute is a token
prefix of the name of the event being thrown, where the dot is the token
separator, all trailing dots are removed, and the empty string matches
everything. "

However, the schema forbids an empty string event specification as
illustrated below:

    <xsd:element name="catch">
        <xsd:complexType>
            <xsd:complexContent mixed="true">
                <xsd:extension base="basic.event.handler">
                   <xsd:attribute name="event"
type="EventNames.datatype"/>
                </xsd:extension>
            </xsd:complexContent>
        </xsd:complexType>
    </xsd:element>


    <xsd:simpleType name="EventNames.datatype">
        <xsd:annotation>
            <xsd:documentation>space separated list of
EventName.datatype</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:NMTOKENS"/>
    </xsd:simpleType>


The schema specifications
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NMTOKENS) defines
NMTOKENS as the following:

"3.3.5 NMTOKENS
[Definition:]   NMTOKENS represents the NMTOKENS attribute type from
[XML
1.0 (Second Edition)]. The *value space* of NMTOKENS is the set of
finite, non-zero-length sequences of *NMTOKEN*s."

Received on Thursday, 13 March 2003 12:20:42 UTC