comments on Voice XML from XML Schema Working Group

Dear Colleagues:

At its face to face meeting earlier this week, the XML Schema
Working Group discussed the Candidate Recommendation version of
VoiceXML 2.0, approved the following comments, and charged its
chair to forward them to you for your consideration.

The XML Schema WG congratulates the Voice Browser WG on the
publication of the Candidate Recommendation of voiceXML version 2.0.

We apologize profusely for missing the deadline for comments on the
Last-Call working draft, but we have now reviewed the revised
document.  We have some comments and suggestions based on our
experience on schema design, which we offer to you for your
consideration. Some of them may suggest changes which can
appropriately be made in a Candidate Recommendation, and some may
suggest larger changes which you may not feel in a position to make in
a CR; we do not have strong opinions about which are which.

We hope our comments are helpful. Please let us know if you have any
questions or if further discussion would be beneficial.


1. Several complex type definitions in vxml.xsd have <choice> model
groups that contain a single particle consisting of a reference to a
group. For example:

   <xsd:complexType name="basic.event.handler" mixed="true">
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
       <xsd:group ref="executable.content" />
     </xsd:choice>
     <xsd:attributeGroup ref="EventHandler.attribs" />
   </xsd:complexType>

Since the particle in the group executable.content is also a <choice>,
this content model becomes

   <xsd:choice minOccurs="0" maxOccurs="unbounded">
     <xsd:choice>
       <xsd:group ref="audio"/>
       <xsd:element ref="assign"/>
       <xsd:element ref="clear"/>
       ... ...
     </xsd:choice>
   </xsd:choice>

The outer <choice> is clearly redundant.  The complex type definition
can be simplified to:

   <xsd:complexType name="basic.event.handler" mixed="true">
     <xsd:group ref="executable.content" minOccurs="0" 
maxOccurs="unbounded" />
     <xsd:attributeGroup ref="EventHandler.attribs" />
   </xsd:complexType>

We think such a simplification makes the schema easier to follow and
we recommend the change.


2. Some contents may usefully be constrained more tightly than the
schema now constrains them. For example, the <if> element is declared
as:

   <xsd:element name="if">
     <xsd:complexType mixed="true">
       <xsd:choice minOccurs="0" maxOccurs="unbounded">
         <xsd:group ref="executable.content" />
         <xsd:element ref="elseif" />
         <xsd:element ref="else" />
       </xsd:choice>
       <xsd:attributeGroup ref="If.attribs" />
     </xsd:complexType>
   </xsd:element>

Since there is no order or occurence constraint, instances such as the
following are all valid, which seems too flexible.

   <if>
     ...
     <else/>
     ...
     <else/>
     ...
     <elseif/>
     ...
   </if>

The content can be changed to the following to ensure that all
<elseif> elements occur before <else> and that there is no more than
one <else> element:

   <xsd:element name="if">
     <xsd:complexType mixed="true">
       <xsd:sequence>
         <xsd:group ref="executable.content minOccurs="0"
                    maxOccurs="unbounded" />
         <xsd:sequence minOccurs="0" maxOccurs="unbounded">
           <xsd:element ref="elseif" />
           <xsd:group ref="executable.content minOccurs="0"
                      maxOccurs="unbounded" />
         </xsd:sequence>
         <xsd:sequence minOccurs="0" maxOccurs="1">
           <xsd:element ref="else" />
           <xsd:group ref="executable.content minOccurs="0"
                      maxOccurs="unbounded" />
         </xsd:sequence>
       </xsd:sequence>
       <xsd:attributeGroup ref="If.attribs" />
     </xsd:complexType>
   </xsd:element>

(In passing, we note that on general principles, we believe the
language would be easier to describe and use if the 'elseif' and
'else' elements (and a 'then' element) were not empty elements
followed by appropriate executable content, but non-empty elements
which contained the appropriate executable content.  We recognize
that this may not be a feasible change at this stage in the life of
VoiceXML.)

3. The element "output" in vxml.xsd is declared as abstract, and not
used or referenced anywhere else. The declaration may be removed.

4. The VariableName.datatype in vxml-datatypes.xsd has a pattern:

   xsd:pattern value="['$'\c]+" />

The character '$' in the range doesn't need the quotation mark, and as
written the value will accept single quotation marks where a dollar
sign or \c is expected.  We suspect this is not intended.

5. The ContentType.datatype in vxml-datatypes.xsd is defined as a list
of string. Since string may contain whitespaces, the definition should
perhaps be changed to a list of token; this is less subject to
misunderstanding by readers of the schema.

6. According to the comments in the annotations,
VariableNames.datatype, RestrictedVariableNames.datatype, and
EventNames.datatype are lists of atomic VariableName.datatype,
RestrictedVariableName.datatype and EventNames.datatype
respectively. We believe they should be defined as such rather than as
NMTOKENS or other types:

   <xsd:simpleType name="RestrictedVariableNames.datatype">
     <xsd:annotation>
       <xsd:documentation>space separated list of restricted
         variable names </xsd:documentation>
     </xsd:annotation>
     <xsd:list itmeType="RestrictedVariableName.datatype"/>
   </xsd:simpleType>

   <xsd:simpleType name="VariableNames.datatype">
     <xsd:annotation>
       <xsd:documentation>space separated list of variable names
         including shadow variables</xsd:documentation>
     </xsd:annotation>
     <xsd:list itemType="VariableName.datatype">
   </xsd:simpleType>

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

7. Some suggestions for simple type Repeat-prob.datatype in
grammar-core.xsd:

a. The base type might better be made decimal instead of float. It
should be noted that decimal is not a subtype of float and their
mappings from the lexical space to the value space are different. For
example, '1.1' may be rounded to some float value different from
exactly 1.1. Such behavior is not expected in decimal.

b. The maxInclusive value is 1.0, while the patterns allow any
positive values less than 10. They should be made consistent.

c. The pattern ([0-9]+)? should probably be replaced with the
equivalent pattern [0-9]*.

8. The commented-out pattern constraint in
RestrictedVariableName.datatype in vxml.xsd needs to be removed or
fixed.

Received on Friday, 7 March 2003 11:18:11 UTC