RE: XML Schema WG comments on SSML version 1.0 Last Call Working Draft

Dear Priscilla (and the XML Schema Working Group),

We would like to thank you for your careful review of the SSML

We have accepted and will apply all of your comments and
 suggestions except for 2d. For consistency with the other
 (related) specifications from the Voice Browser Working Group,
 we will retain the current restriction against leading and
 trailing whitespace in enumerated attribute values.

If you believe we have not adequately addressed your issues with this
response, please let us know as soon as possible.  If we do not hear
from you within 14 days, we will take this as tacit acceptance.

Once again, thank you for your thorough and considered input on
the specification.

-- Dan Burnett

Synthesis Team Leader, VBWG

-----Original Message-----
From: Priscilla Walmsley []
Sent: Tuesday, February 11, 2003 5:25 AM
Subject: XML Schema WG comments on SSML version 1.0 Last Call Working

Dear Colleagues:

The XML Schema WG congratulates the Voice Browser WG on the publication
of the Last Call working draft of SSML version 1.0 of 02 December, 
2002.  We apologize profusely for missing the deadline for comments.

We have now reviewed the document and listed some comments and
suggestions below.  Only the first of these do we consider significant; 
the rest are suggestions based on our experience with schema design.  

We congratulate you on your work and hope our comments are helpful.  
Please get back to us if you have any questions or if further 
discussion seems likely to be helpful.

-Priscilla Walmsley
 on behalf of the XML Schema WG
1. Significant Issue
There is a subtle error in the schema.  Because the speak.class group 
contains elements that have anonymous types, it cannot be used in a
restriction as it is in synthesis.xsd.  This is because a particle 
containing an anonymous type will never be considered a valid 
restriction of another particle with an anonymous type (even if they 
reuse the same type definition from a named model group).  This can 
be remedied by giving the metadata and lexicon elements named types, 
as in:

<xsd:group name="speak.class">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="metadata" type="metadata"/>
      <xsd:element name="lexicon" type="lexicon"/>
      <xsd:group ref="sentenceAndStructure.class"/>

<xsd:complexType name="metadata">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:any namespace="##other" processContents="lax"/>
  <xsd:anyAttribute namespace="##any" processContents="strict"/>

<xsd:complexType name="lexicon">
  <xsd:attribute name="uri" type="xsd:anyURI" use="required"/>
  <xsd:attribute name="type" type="xsd:string"/>

2. Suggestions
a. The prose says "The metadata and lexicon elements must occur 
   before all other elements and text contained within the root speak 
   element" but this is not enforced in the schema. The schema cannot 
   enforce that the metadata and lexicon children must appear before 
   any text, but it can enforce that they must appear before other 
   children, by changing speak.class as in:

	<xsd:group name="speak.class">
		 <xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:element name="metadata" type="metadata"/>
			<xsd:element name="lexicon" type="lexicon"/>
		 <xsd:group ref="sentenceAndStructure.class"
		            minOccurs="0" maxOccurs="unbounded"/>

b. Since the name attribute of the mark element is declared to be 
   of type ID, it may be useful to point out in the prose that this 
   means that it must be unique within the containing document and 
   must conform to the lexical rules for an NCName.

c. Since the name attribute of the voice element is really a 
   whitespace-separated list of names, it may be better to give 
   a type that represents a list of names, as in 
	<xs:simpleType name='voiceName'>
		<xs:restriction base='xs:token'>
			<xs:pattern value='\S+'/>
	<xs:simpleType name='listOfVoiceName'>
		<xs:list itemType='voiceName'/>
d. Most of the simple types in this schema that are derived from
   string would be more easily used if they were derived from
   token. This would allow leading and trailing whitespace 
   to be collapsed.

e. The type "number" was defined as a restriction of string.  It seems
   more natural to us that it should be defined as a restriction of 
   decimal, as in: 

	<xsd:simpleType name="number">
			  number: e.g. 10, 5.5, 1.5,9., .45
		<xsd:restriction base="xsd:decimal">

3. Minor problems with the examples
a. The example under "Pitch contour" in section 2.2.4 has the values 
   +20 and +10 which appear to be invalid according to both the schema 
   and the prose in the recommendation.
b. The examples starting in section 3.3 are all missing the required 
   version attribute of the speak element
c. The second and third examples in Appendix A are missing an end 
   quote on the encoding in the xml declaration

Received on Tuesday, 12 August 2003 14:20:45 UTC