WSDL Usage Experience with XML Schema

Jonathan Marsh, Web Services Description Working Group

WSDL 2.0 (Web Services Description Language 2.0) makes substantial use of XML Schema 1.0. WSDL describes a set of message exchanges a Web Service endpoint may engage in. The format of the messages exchanged is described by a type system, such as XML Schema. WSDL augments the description of the message structure by describing an interaction pattern by which messages are exchanged to invoke a particular "operation", and how operations are grouped into an "interface". The details of how to transmit the message e.g. using SOAP over HTTP, are described in a protocol "binding". Because it adds additional information to a description of a set of message structures, WSDL can be considered as an extension to the core message type system. While WSDL 2.0 allows different type systems to be used to describe messages, use of XML Schema is given preferential treatment by the specification. In the common case, WSDL 2.0 documents can be considered as a framework extending XML Schema's descriptive capabilities.

WSDL has encountered a number of schema-related issues during its development.

  1. WSDL 2.0 found that XML Schema is a convenient way to specify normatively many of the structural aspects of a WSDL document. As such, conformance of a WSDL 2.0 document is primarily assessed by validation of that document against our normative schema. Complete conformance augments validation with additional WSDL-specific structural constraints. XML Schema 1.0 has become an intrinsic tool to the specification of the WSDL 2.0 language. However, since XML Schema 1.0 does not natively support many of the additional facilities of XML 1.1, we were limited in our ability to support XML 1.1 facilities in the WSDL language itself. In the end we decided that use of XML Schema 1.0 itself was more valuable than XML 1.1's new features (and that support for these features was a limitation that should be corrected in the XML Schema spec instead of in ours), and therefore XML 1.1's new features would not be supported in WSDL 2.0.
  2. The most obvious versioning strategy for a Web service is to allow messages that contain extra XML elements, which are to be ignored by older Web services. For instance, an operation that takes a message with a <name> element with <first> and <last> children might add a <suffix> element in a later version of the service. Since we rely on XML Schema describe the structure of the message, the well-known behaviors that make compatible evolution of schemas difficult also make it difficult to evolve Web services. As of this writing, the only outstanding non-editorial Last Call issue preventing us from publishing a second Last Call document is a proposal to provide a schema extension or other mechanism for enabling alternate schema processing models (specifically Henry Thompson's validate twice mechanism). One proposal calls for the WSDL spec to mandate support for such processing as the default, with an option to perform normal validation in cases where it is desired.
  3. The WSDL WG spent quite a while designing facilities for import and include. We modeled <wsdl:import> and <wsdl:include> after XML Schema's import and include concepts, trying to match the behavior as closely as possible except for chameleon includes and the ability to import components that aren't in a namespace (which cannot arise in WSDL). While we believe we have matched the behavior of XML Schema, it took us quite a while and several last call issues to reach this state. Even among the fairly sophisticated audience in our WG, we found the details of XML Schema's import and include not to be widely understood.
  4. One aspect of XML-based messages are difficult to fully capture in XML Schema is the meaning of base64-encoded binary data. XML Schema does provide facilities to describe that element content is base64-encoded binary (through the xs:base64Binary simple type), but it does not provide simple and user-accessible facilities to indicate the format of that binary data. The WSDL WG in conjunction with the XMLP WG, developed a W3C WG Note describing schema extensions that allow the media type (or a set of related media types) to be described. Using this facility, a WSDL consumer can determine not only that a specific message should contain base64-encoded binary data, but that that binary data represents a particular media type such as image/jpeg.
  5. Certain Web services find it useful to pass references to other Web services as part of a message exchange. WS-Addressing provides one such type of reference in the wsa:EndpointReference construct. When describing messages returning endpoint references, it is often useful to code generators to know not only that the construct represents and endpoint reference, but that the service to which the endpoint refers implements a particular interface and/or supports a particular protocol binding. Ideally XML Schema would be able to provide a mechanism by which parts of the wsa:EndpointReferenceType could be assigned fixed values when deriving and element from it, but the current structure of wsa:EndpointReference is such that XML Schema is unable to do this. Because of this, and because we wanted to be able to further constrain other types of references such as URIs (which don't have explicit fields indicating the interface and binding), the WSDL WG has decided to introduce schema extensions (two attributes named wsdlx:interface and wsdlx:binding) to annotate elements in the schema, asserting that the construct is an endpoint reference and providing the desired additional constraints.

Despite some of the limitations the WSDL Working Group has encountered, we universally recognize that XML Schema will provide the interoperable foundation for WSDL 2.0.

3 June 2005