This directory contains the W3C WSDL 2.0 Test Suite. The purpose of this test suite is to provide a common set of test cases that can be used by any WSDL 2.0 implementation. The test cases are divided into good and bad buckets. The good test cases are correct examples of usage. Our goal is to have at least one good test case for each aspect of WSDL 2.0. For example, every XML element and attribute in WSDL 2.0 should be present in at least one good test case. The bad test cases are incorrect examples of usage. Our goal is to have at least one bad example that violates each constraint or rule in WSDL 2.0. For example, every rule that cannot be expressed in the XML schema for WSDL 2.0 should be violated in at least one bad document.
The structure of the Test Suite is described in Test Suite Contents. The test suite is contained in the following subdirectories:
documentcontains WSDL documents
exchangescontains message exchanges
All WSDL 2.0 documents in the test suite are required to be valid
with respect to the normative XML schema for WSDL 2.0. There is little
value in including non-valid documents, since any validating parser can
check the schema rules. An Ant
script is therefore provided to perform XML schema validation on all the
WSDL documents. The Xerces
parser is used for this purpose. Override the Ant
property to point to where you installed Xerces on your machine.
xmlcatalog subdirectory contains the XML schemas
for WSDL 2.0 and XSD 1.0.
We are mainly concerned with test documents that violate rules that cannot be expressed in the XML schema. Such rules must be checked by validators, for example the Java WSDL 2.0 validator that is part of the Apache Woden project
The results of running a WSDL validator are recorded in a document in the ValidationReport.xsd format. Results from each implementation (as identified in the implementations.xml document) are combined using validation-collect-results.xsl into an intermediary validation.xml file, and thence converted into Validation.html by the application of validation.xsl.
The Working Group has defined an XML serialization of the component model to assist in evaluating the construction of component models across implementation. The interchange format is defined using a set of schemas representing the core WSDL 2.0 component model, some base type definitions (e.g. QNames), and schemas representing each of the extension namespaces in Part 2.
Interchange results are canonicalized using a two-step process, wsdlcm-canonicalize-order.xsl sorts children in a canonical order, and wsdlcm-canonicalize-id.xsl normalizes ID and IDREF values to a canonical form. Canonicalized files are stored in the same directory as the original '.wsdlcm' file, with the naming convention '.canonical.wsdlcm'. Canonicalized interchange results are compared against a baseline using another stylesheet (wsdlcm-compare.xsl), which provides a summary of differences (ignoring namespace prefixes, whitespace, etc.) of the two files, stored as a document using the '.results.xml' naming convention. These individual results are rolled up into a summary format interchange.xml using the interchange-collect-results.xsl stylesheet. An overall test result summary is created using yet another stylesheet (interchange.xsl) in conjunction with a list of implementations contributing results and the test-suite.xml metadata.
The community is encouraged to contribute test cases. The best way to confirm your understanding of the specification is to contribute an illustrative test case. Test cases should be contributed by emailing them to the W3C Web Services Description Working Group mailing list.
This directory is stored in the W3C CVS repository. CVS users are requested to email modifications or additions to the test suite as patches. Access CVS using the following parameters:
Contributors who are looking for a convenient, free tool to access CVS and create patches can use Eclipse.