WSDL Usage Experience with XML Schema
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.
- 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.
- 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.
- 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.
- 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.
- 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