- From: McGlashan, Scott <scott.mcglashan@hp.com>
- Date: Wed, 19 Nov 2003 20:33:14 +0100
- To: <cmsmcq@acm.org>
- Cc: <www-voice@w3.org>
The Voice Browser Working Group (VBWG) is now completing its resolution
of
issues raised during the review of the Candidate Recommendation version
of
VoiceXML 2.0 [1]. Our apologies that it has taken so long to respond.
Following the process described in [2] for advancement to Proposed
Recommendation, this is the VBWG's formal response to the issues you
raised.
Please indicate before 26 November 2003 whether you are satisfied with
the
VBWG's resolutions, whether you think there has been a misunderstanding,
or
whether you wish to register an objection.
If you do not think you can respond before 26 November, please let me
know.
The Director will appreciate a response whether you agree with the
resolutions
or not. However, if we do not hear from you at all by 26 November 2003,
we
will assume that you accept our resolutions.
Below you will find a summary of the VBWG's responses to each of your
issues. Please use the issue identifiers when responding.
Thank you,
Scott McGlashan
Co-chair, Voice Browser Working Group
[1] http://www.w3.org/TR/2003/CR-voicexml20-20030220/
[2] http://www.w3.org/2003/06/Process-20030618/
-----------------------------------------------
Issues you raised and VBWG responses
-----------------------------------------------
Issues:
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0089.html
CR11-1, CR11-2, CR11-3, CR11-4, CR11-5, CR11-6, CR11-7, CR11-8
Issue CR11-1
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.
CR11-1 Resolution: accepted
Change applied.
-----------------------------------------------
Issue CR11-2
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.)
CR11-2 Resolution: accepted
Change applied. We will look into changing the if-then-else structure in
a future version of the language.
-----------------------------------------------
Issue CR11-3
3. The element "output" in vxml.xsd is declared as abstract, and not
used or referenced anywhere else. The declaration may be removed.
CR11-3 Resolution: accepted
Element removed.
-----------------------------------------------
Issue CR11-4
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.
CR11-4 Resolution: accepted
Change applied.
-----------------------------------------------
Issue CR11-5
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.
CR11-5 Resolution: accepted
Change applied.
-----------------------------------------------
Issue CR11-6
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>
CR11-6 Resolution: accepted
Change applied.
-----------------------------------------------
Issue CR11-7
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]*.
CR11-7 Resolution: accepted
Changes applied.
-----------------------------------------------
Issue CR11-8
8. The commented-out pattern constraint in
RestrictedVariableName.datatype in vxml.xsd needs to be removed or
fixed.
CR11-8 Resolution: accepted
Change applied.
Received on Wednesday, 19 November 2003 14:33:16 UTC