This directory contains a test suite for the W3C XML Schema Component Designators specification. If you have implemented XML Schema Component Designators, using this test suite facility is a good way to ensure that your implementation follows the specification, and to identify aspects of the specification that should be changed if there are implementability issues. Sending us your test suite results helps the XML Schema Working Group to satisfy the requirements to progress toward W3C Recommendation status.
Use CVS to get the test suite:
$ export CVSROOT=":pserver:anonymous@dev.w3.org:/sources/public" $ cvs login (Logging in to anonymous@dev.w3.org) CVS password: anonymous $ cvs get 2009/xmlschema-ref-test-suite/
You can also browse the testsuite using CVSWeb at http://dev.w3.org/cvsweb/2009/xmlschema-ref-test-suite/.
Because the XML Schema Component Designators specification does not specific an API by which results can be compared in a consistent way, testing involves some manual or highly implementation-specific evaluation. The testsuite is therefore commensurately small, although each individual test constitutes a test of many component paths within a schema. In addition, this testsuite does not test the mapping of URIs to assembled schemas or the XPointer designator syntax, but instead focuses on the schema component path part of the specification.
Implementors are encouraged 1) to write a harness for this test suite and to test their implementations and 2) to report their results to the XML Schema Working Group. All of these areas are discussed in greater detail below.
This is the initial public release of this test suite.
| Version | Date |
| XML Schema Component Designators Test Suite 1.0.0 | 26 Feb 2010 |
We encourage you, the implementors of XML Schema Component Designators, to run these tests and send us your results. These results will help us exit Candidate Recommendation (described in the W3C Process).
As there is no de jure or de facto API for implementations of XML Schema Component Designators, we are not able to provide a test harness to execute these tests. You will have to write your own test harnesses.
Each test case consists of:
A catalog contains metadata describing each test case.
There are a number of ways of using this information:
A canonical SCP generator (CSG): For each testgroup, if there is a difference between the expected canonical SCPs and the set of SCPs generated, report that as "failure" with the differences (i.e, which paths were missing or added).
A canonical SCP interpreter (CGI): For each canonical SCP in the list, verify that the interpreter identifies the correct component (this is a manual step, highly implementation-specific). The id attributes are intended to provide a relevant clue. If the interpreter does not identify the correct component, report that as a "failure" with a comment indicating the variance.
A non-canonical SCP interpreter (NCSI): As a canonical SCP interpreter, except the non-canonical SCPs should be checked and reported on as well.
A non-canonical SCP generator (NCSG): The NCSG could perhaps report which of the paths it could not generate, or which were incorrect (in the sense they were not for the right component). In general it will be difficult for an NCSG to report much via the testsuite, but we welcome any feedback you have in any case.
<testcase>
<name>example1</name>
<creator>Mary Holstege</creator>
<category>minimal</category>
<description>Example 1. Schema covers a variety of components situations include simple types with facets, complex type extension and restriction, substitution groups, and annotations.</description>
<section number="4.4.2" spec="SchemaRef" title="The annotation Axis"/>
<section number="4.4.3" spec="SchemaRef" title="The schemaAttribute Axis"/>
<section number="4.4.4" spec="SchemaRef" title="The schemaElement Axis"/>
<section number="4.4.5" spec="SchemaRef" title="The type Axis"/>
<section number="4.4.12" spec="SchemaRef" title="The model Axis"/>
<section number="4.4.13" spec="SchemaRef" title="The anyAttribute Axis"/>
<section number="4.4.15" spec="SchemaRef" title="The facet Axis"/>
<section number="4.4.18" spec="SchemaRef" title="The substitutionGroup Axis"/>
<section number="4.4.25" spec="SchemaRef" title="The particle Axis"/>
<section number="4.4.26" spec="SchemaRef" title="The component Axis"/>
<section number="4.4.27" spec="SchemaRef" title="The elided-component Axis"/>
<test isXSD11="false" include-builtins="false">
<schema file="example1.xsd"/>
<paths file="example1.xml"/>
</test>
</testcase>
This catalog entry indicates that the test named 'example1' (a unique name),
makes use of the schema 'example1.xsd' and has a set of path descriptions in
'example1.xml' which do not include canonical paths for the XML Schema built-in
components. The path description file is not an document instance of the
given schema, but is an XML document valid according to the paths
element in the schema catalog.xsd. This particular
test covers the axes described in the referenced sections, uses the XML
Schema 1.0 component model rather than the XML Schema 1.1 component model.
<xs:schema targetNamespace="http://www.w3.org/xmlschema-ref/example1"
xmlns="http://www.w3.org/xmlschema-ref/example1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" id="i0">
<xs:complexType name="registered-query" id="i1">
<xs:annotation id="i2">
<xs:documentation>
A registered-query.
</xs:documentation>
<xs:appinfo/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="query">
<xs:sequence id="i3">
<xs:element ref="id" minOccurs="0" maxOccurs="unbounded" id="i4"/>
<xs:element ref="option" minOccurs="0" maxOccurs="unbounded" id="i5"/>
</xs:sequence>
<xs:attribute name="weight" type="weight" use="optional" id="i6"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="registered-query" type="registered-query"
substitutionGroup="query" id="i7"/>
<xs:simpleType name="id" id="i8">
<xs:restriction base="xs:unsignedLong"/>
</xs:simpleType>
<xs:element name="id" type="id" id="i9"/>
<xs:element name="option" type="option" id="i10"/>
<xs:simpleType name="option" id="i11">
<xs:restriction base="xs:string">
<xs:enumeration value="stemmed" id="i12"/>
<xs:enumeration value="unstemmed" id="i13"/>
<xs:enumeration value="wildcarded" id="i14"/>
<xs:enumeration value="unwildcarded" id="i15"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="query" id="i16">
<xs:annotation id="i17">
<xs:documentation>
Any query.
</xs:documentation>
<xs:appinfo/>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:anyAttribute processContents="lax" id="i18"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="query" type="query" abstract="true" id="i19"/>
<xs:simpleType name="weight" id="i20">
<xs:restriction base="xs:double">
<xs:minInclusive value="0" id="i21"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Each canonical path associated with the schema has an entry in the
canonical-section part of the path description document. For example, the
second canonical-path below is the canonical path to the
complex type named 'registered-query', which corresponds to the
complexType element with the id id1 in the schema
document.
<canonical-section> <canonical-path> <canonical>/</canonical> <ids>i0</ids> </canonical-path> <canonical-path> <canonical>/type::p:registered-query</canonical> <ids>i1</ids> </canonical-path> <canonical-path> <canonical>/type::p:registered-query/annotation::*</canonical> <ids>i2</ids> </canonical-path> <canonical-path> <canonical>/type::p:registered-query/model::sequence</canonical> <ids>i3</ids> </canonical-path> <canonical-path> <canonical>/type::p:registered-query/schemaAttribute::weight</canonical> <ids>i6</ids> </canonical-path> <canonical-path> <canonical>/schemaElement::p:registered-query</canonical> <ids>i7</ids> </canonical-path> <canonical-path> <canonical>/type::p:ids</canonical> <ids>i8</ids> </canonical-path> <canonical-path> <canonical>/schemaElement::p:ids</canonical> <ids>i9</ids> </canonical-path> <canonical-path> <canonical>/schemaElement::p:option</canonical> <ids>i10</ids> </canonical-path> <canonical-path> <canonical>/type::p:option</canonical> <ids>i11</ids> </canonical-path> <canonical-path> <canonical>/type::p:option/facet::enumeration</canonical> <ids>i12 i13 i14 i15</ids> </canonical-path> <canonical-path> <canonical>/type::p:query</canonical> <ids>i16</ids> </canonical-path> <canonical-path> <canonical>/type::p:query/annotation::*</canonical> <ids>i17</ids> </canonical-path> <canonical-path> <canonical>/type::p:query/anyAttribute::*</canonical> <ids>i18</ids> </canonical-path> <canonical-path> <canonical>/schemaElement::p:query</canonical> <ids>i19:</ids> </canonical-path> <canonical-path> <canonical>/type::p:weight</canonical> <ids>i20</ids> </canonical-path> <canonical-path> <canonical>/type::p:weight/facet::minInclusive</canonical> <ids>i21</ids> </canonical-path> </canonical-section>
The paths in the selected-section element in the path
description file do not constitute an exhaustive set of paths (that set is
infinite). Each selected path has a set of mappings which indicate both the
canonical path of a component selected by the path. If the path selects no
components, the mapping set will be empty.
<selected-section> <selected-path> <select>/p:registered-query/substitutionGroup::*</select> <mapping> <canonical>/p:query</canonical> <ids>i19</ids> </mapping> </selected-path> <selected-path> <select>/~p:registered-query/anyAttribute::*</select> <mapping> <canonical>/type::p:query/anyAttribute::*</canonical> <ids>i16</ids> </mapping> </selected-path> <selected-path> <select>/~p:option/annotation::*</select> </selected-path> <selected-path> <select>/p:registered-query/type::*</select> <mapping> <canonical>/type::p:registered-query</canonical> <ids>i1</ids> </mapping> </selected-path> <selected-path> <select>//type::*</select> <mapping> <canonical>/type::p:registered-query</canonical> <ids>i1</ids> </mapping> <mapping> <canonical>/type::p:id</canonical> <ids>i8</ids> </mapping> <mapping> <canonical>/type::p:option</canonical> <ids>i11</ids> </mapping> <mapping> <canonical>/type::p:query</canonical> <ids>i16</ids> </mapping> <mapping> <canonical>/type::p:weight</canonical> <ids>i20</ids> </mapping> </selected-path> <selected-path> <select>/~p:registered-query/model::sequence/particle::*</select> <mapping> <ids>i4</ids> </mapping> <mapping> <ids>i5</ids> </mapping> </selected-path> </selected-section>
If you believe that some of the queries or their expected results are incorrect, then we encourage you to enter bug reports in the public instance of Bugzilla at W3C, http://www.w3.org/Bugs/Public/. Please include the query and test results you believe are correct as attachments to the bug report.
To enter a bug report you will need a Bugzilla signon (email address and password). You can create this signon by following the Open a new Bugzilla account link on the Bugzilla Main Page. General information on Bugzilla, an open-source bug tracking system, is available at http://www.bugzilla.org/. The standard documentation for the version currently being run on the W3C server is available at http://www.bugzilla.org/docs/2.20/html/.
To enter a bug report in Bugzilla you will need to log in, choose the action "New", and then choose the "XML Schema" Product and the "SCDS: Schema Component Designators" Component. Enter a short description of the problem in the Summary field; it would be very helpful if every Summary started with the string "[XSCDTS]". Detailed information should be entered in the Description field. Please be specific about the problem that you are reporting. Clearly identify the test case or test cases that are problematic. If you believe that the expected result is wrong, then tell us what result you believe is correct. If you believe that another result for a test case is justified, then please tell us what it is. In both cases, please cite portions of one or more of the XML Schema specifications that support your position.
When you are ready to submit your results to us, we ask that you generate an XML report in accordance with the schema results.xsd. The file sample-report.xml is a sample results report to give you guidance. A report should indicate what type of implementation it is, information about how it does perform the namespace binding and context setting, what extensions it performs, whether and how it manages the left hand side, whether it supports just paths or full designators (XPointer).
If you have indicated that you wish your results to be displayed as “Anonymous”, then please send them to the XML Schema WG Team Contact, Liam Quin. Otherwise, please send them to Mary Holstege, cc'ing www-archive@w3.org.
We encourage you to send us results early, and then to send us updates as the XML Schema Component Designators Test Suite progresses and as your implementation progresses.
Distributed under both the W3C Test Suite License and the W3C 3-clause BSD License. To contribute to a W3C Test Suite, see the policies and contribution forms.
We will post reports on the results that we receive in this section.
Questions about the XML Schema Component Designators Test Suite can be sent to the XML Schema public mailing list. Messages sent to this list can be seen in www-xml-schema-comments@w3.org Mail Archives.
The following members of the XML Schema Group participated in the development of this test suite:
Mary Holstege (Mark Logic)