WSDL 2.0 is the Web Services Description Language, an XML language for describing Web
services. This document,
Message exchange patterns
Operation safety
Operation styles
Binding extensions for SOAP and HTTP
This is the
Please send comments about this document to the public
The Working Group released a test suite along with an
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
This document is governed by the
Last Modified: $Date: 2007/06/22 20:33:39 $ CET
The Web Services Description Language Version 2.0 (WSDL 2.0)
This document,
Message exchange patterns:
Operation safety declaration:
Operation styles:
Binding extensions:
A SOAP 1.2
An HTTP/1.1
This document depends on Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language
Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119
This specification uses a number of namespace prefixes throughout;
they are listed in
| Prefix | Namespace | Notes |
|---|---|---|
| wsdl |
|
This namespace is defined in |
| wsdlx |
|
This specification extends in section |
| wsoap |
|
Defined by this
specification. A normative XML Schema |
| whttp |
|
Defined by this
specification. A normative XML Schema |
| wrpc |
|
Defined by this
specification. A normative XML Schema |
| xs |
|
Defined in the W3C XML Schema
specification |
Namespace names of the general form
All parts of this specification are normative, with the EXCEPTION
of pseudo-schemas, examples, and sections explicitly marked as
"Non-Normative". Pseudo-schemas are provided for each component,
before the description of this component. They provide visual help for
the XML
Assertions about WSDL 2.0 documents and components that are not enforced by the normative XML schema for WSDL 2.0 are marked by a dagger symbol (†) at the end of a sentence. Each assertion has been assigned a unique identifier that consists of a descriptive textual prefix and a unique numeric suffix. The numeric suffixes are assigned sequentially and never reused so there may be gaps in the sequence. The assertion identifiers MAY be used by implementations of this specification for any purpose, e.g. error reporting.
The assertions and their identifiers are summarized in
section
Web Services Description Language (WSDL) message exchange patterns (hereafter simply 'patterns') define the sequence and cardinality of abstract messages listed in an operation. Message exchange patterns also define which other nodes send messages to, and receive messages from, the service implementing the operation.
A
WSDL message exchange patterns describe the interaction at the abstract
(interface) level, which may be distinct from the pattern used by the
underlying protocol binding (e.g. SOAP Message Exchange
Patterns; section
By design, WSDL message exchange patterns abstract out specific message types. Patterns identify placeholders for messages, and placeholders are associated with specific message types by the operation using the pattern.
Unless explicitly stated otherwise, WSDL message exchange patterns also abstract out binding-specific information such as timing between messages, whether the pattern is synchronous or asynchronous, and whether the messages are sent over a single or multiple channels.
Like interfaces and operations, WSDL message exchange patterns do not
exhaustively describe the set of messages exchanged between a service
and other nodes;
To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web services, and contain only information that is relevant to both the Web service and another party.
This specification defines several message exchange patterns for
use with
New message exchange patterns may be defined by any organization able and
willing to do so. It is recommended that the patterns use the general
template provided in
This pattern consists of [number] message[s, in order] as follows:
[enumeration, specifying, for each message] A[n optional] message:
indicated by an
[received from|sent to] ['some' if first mention] node [node identifier]
This pattern uses the rule [fault ruleset reference].
An
Note: In the template, the bracketed items indicate a replacement operation. Substitute the correct terms for each bracketed item.
Note: the "received from" and "sent to" are always from the point of view of the service, and participating nodes other than the service are implicitly identified as the originators of or destinations for messages in the exchange.
WSDL patterns specify their fault propagation model using standard
rulesets to indicate where faults can occur. The most common patterns
for fault propagation are defined in the following subsections, and referenced by the patterns in
WSDL patterns specify propagation of faults, not their generation.
Binding extensions, features, or extension specifications can override the semantics of a fault propagation ruleset, but this practice is strongly discouraged.
The Fault Replaces Message propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/fault-replaces-message
The Message Triggers Fault propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/message-triggers-fault
The No Faults propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/no-faults
WSDL patterns are described in terms of the WSDL component model,
specifically the
A message:
indicated by a
received from some node N
An operation using this message exchange pattern has a
A message:
indicated by a
received from some node N
An operation using this message exchange pattern has a
A message:
indicated by a
received from some node N
A message:
indicated by a
sent to node N
An operation using this message exchange pattern has
a
Note that many of the message exchange patterns defined above describe responses to an initial message (either a normal response message or a fault.)
Such responses can be used in attempts to disrupt, attack, or map a network, host, or services. When such responses are directed to an address other than that originating the initial message, the source of an attack can be obscured, or blame laid on a third party, or denial-of-service attacks can be enabled or exacerbated.
Security mechanisms addressing such attacks can prevent the delivery of response messages to the receiving node. Conformance to the message exchange pattern is measured prior to the application of these security mechanisms.
This section defines an extension to WSDL 2.0
This extension MAY be used for setting defaults in bindings,
such as in the HTTP binding (see
The safety extension adds the following property to the
The XML representation for the safety extension is an
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
|
The actual value of the |
This section defines
The RPC style is selected by including the value
An
Furthermore, the
associated messages MUST conform to the rules below,
described using XML Schema
If the
The
When present, the
The value of the
The function signature defined by a
Start with the value of the
Filter the elements of this list into two lists, the first one
For ease of visualization, let's denote the two lists as:
(L1)
and
(L2)
respectively.
Then, if the input sequence ends with an element wildcard, the formal signature of the function is:
where
Otherwise the formal signature of the function is:
i.e.:
the list of formal arguments to the function is the direction the list of formal return parameters of the function is
each formal argument and formal return parameter is typed
according to the type of the child element identified by it
(unique per the conditions given above).
The
The XML representation for the RPC signature extension is an
A [local name] of
A [namespace name] of "http://www.w3.org/ns/wsdl/rpc"
The type of the
A
| Property | Value |
|---|---|
| A list of |
The IRI style is selected by including the value
Use of this value indicates that XML Schema
The content model of this element is defined using a complex type that contains a sequence from XML Schema.
xs:simpleType, and MUST NOT be of the type
or derive from xs:QName,
xs:NOTATION, xs:hexBinary or
xs:base64Binary.
The Multipart style is selected by including the value
Use of this value indicates that XML Schema
The content model of this element is defined using a complex type that contains a sequence from XML Schema.
1.
The SOAP binding extension described in this section is an extension
for
As allowed in
The SOAP binding extension is designed with the objective of minimizing
what needs to be explicitly declared for common cases. This is achieved
by defining a set of default rules that affect all
Note: As in other parts of this specification, one could have done away with "default" properties at the component model level, and have set the value for the corresponding non-default properties in the XML mapping section. However, default properties are required for interface-less binding. Indeed, an interface-less binding has no means to set the non-default version of the property at the operation-level, since there is precisely no operation (there is not even an interface). Hence the mapping needs to be done elsewhere.
A subset of the HTTP properties specified in the HTTP binding extension
defined in section
The double question marks ("??") after the
attributes in the
A
If the value of the
This SOAP binding extension only allows one single element in the SOAP body.
If the value of the
And, if the
SOAP header blocks other than the ones declared in the
By default, SOAP 1.2
The SOAP protocol specification adds the following
property to the WSDL component model (as defined in
The XML representation for specifying the SOAP version
is an optional
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the |
The SOAP protocol specification adds the following
property to the WSDL component model (as defined in
The XML representation for specifying the SOAP protocol
is a REQUIRED
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the |
The SOAP Fault binding extension adds the following
properties to the WSDL component model (as defined in
the allowed token value is
The value of this property
identifies a possible SOAP fault for the operations in
scope. If the value of this property is
The XML representation for binding a SOAP Fault are two
wsoap:code OPTIONAL
A [local name] of
A [namespace name] of
A type of union of
wsoap:subcodes OPTIONAL
A [local name] of
A [namespace name] of
A type of union of list of
See
| Property | Value |
|---|---|
| The actual value of the |
|
| The actual value of the |
For every
The SOAP Operation binding extension specification adds the
following property to the WSDL component model (as defined
in
The XML representation for binding a
wsoap:mep OPTIONAL
A [local name] of
A [namespace name] of
A type of
wsoap:action OPTIONAL
A [local name] of
A [namespace name] of
A type of
The following
wsoap:mepDefault OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the
|
|
| The actual value of the
|
|
| The actual value of the
|
The SOAP messaging framework allows a Web service
to engage one or more additional features (typically
implemented as one or more SOAP header blocks), as defined
by SOAP Modules (see
The
Similarly,
Similarly,
Similarly,
Similarly,
The SOAP modules applicable for a particular operation of
any service, consists of all the modules specified in the input
or output
The
The properties of the
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| The set of |
|
| The actual value of the |
|
| The actual value of the |
|
|
The |
WSDL Version 2.0 Part 1: Core Language
A
wsdl.extension(http://www.w3.org/ns/wsdl/soap,
wsoap.module(
parent
ref
SOAP allows the use of header blocks in the header part of the message. This binding extension allows users to declare the SOAP header blocks in use on a per-message and on a per-fault basis.
The SOAP Header Blocks binding extension specification adds the
following property to the WSDL component model (as defined
in
Similarly,
A
The properties of the
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| The set of |
|
| The element declaration
from the |
|
| The actual value of the |
|
| The actual value of the |
|
|
The |
WSDL Version 2.0 Part 1: Core Language
A
wsdl.extension(http://www.w3.org/ns/wsdl/soap,
wsoap.header(
parent
element declaration
This section describes the SOAP 1.2 binding for WSDL 2.0. This binding does NOT natively support the full range of capabilities from SOAP 1.2. Certain capabilities not widely used, or viewed as problematic in practice, are not available -in many cases because supporting them was considered as adding considerable complexity to the language. Here are examples of such unsupported capabilities:
multiple children of the SOAP Body;
multiple SOAP Fault Detail entries;
non-qualified elements as children of a SOAP Fault Detail.
A WSDL SOAP Binding is identified as a SOAP 1.2 binding by assigning the value
The WSDL SOAP 1.2 binding extension defined in this section is an extension of the SOAP binding defined in section
The WSDL SOAP 1.2 binding extension supports
the SOAP 1.2 HTTP binding defined by the
Default rules in section
These binding rules are applicable to SOAP 1.2 bindings.
This section describes the relationship between WSDL components and SOAP
1.2 MEP properties as described in
This section describes the mapping from the WSDL
As the client, the property
The SOAP
The WSDL
The WSDL
As the service, the property
The WSDL
The WSDL
This section describes the mapping from the WSDL
As the client, the property
The SOAP
The value of the
The SOAP
The WSDL
As the service, the property
The WSDL
The WSDL
This section describes the mapping from the WSDL
As the client, the property
The SOAP
The WSDL
The SOAP
As the service, the property
The WSDL
The SOAP
This section describes the mapping from the WSDL
As the client, the property
The SOAP
The WSDL
The SOAP
As the service, the property
The WSDL
The SOAP
An
The HTTP binding extension described in this section is an extension for
As allowed in
The HTTP binding extension is designed with the objective of minimizing
what needs to be explicitly declared for common cases. This is achieved
by defining a set of default rules that affect all
Note: As in other parts of this specification, one could have done away with "default" properties at the component model level, and have set the value for the corresponding non-default properties in the XML mapping section. However, default properties are required for interface-less binding. Indeed, an interface-less binding has no means to set the non-default version of the property at the operation-level, since there is precisely no operation (there is not even an interface). Hence the mapping needs to be done elsewhere.
A
An implementation of the HTTP binding extension MUST support the following extensions:
For a given
Otherwise, the value of the
Otherwise, if a
Otherwise, the value
If the
Otherwise, if the value of the parent
Otherwise, if the value of the grandparent
If the
If the
The body of the response message is encoded using the specified content encoding.
parameter production of media-range in Section 14.1 of
Section
If the value of the
If the value is Content-Type entity-header field as defined in section 14.17 of
If the
If the
If the
Otherwise, then the serialization of the Content-Type entity-header field is the
value of the
Section
| HTTP Method | Default Input Serialization | Default Output Serialization |
|---|---|---|
| Selected in |
||
| GET |
application/x-www-form-urlencoded
|
application/xml
|
| POST |
application/xml
|
application/xml
|
| PUT |
application/xml
|
application/xml |
| DELETE |
application/x-www-form-urlencoded
|
application/xml |
The
application/x-www-form-urlencoded serialization
format places constraints on the XML Schema definition of the
The default value for the application/xml.
Mechanisms other than setting the serialization properties
MAY modify the serialization format of the application/x-www-form-urlencoded. Other
examples are other message exchange
patterns or binding extensions.
The HTTP header field name used is the value of the
The HTTP header field value, whose XML Schema type
is declared by the field-value production of section 4.2 of
If the resulting IRI uses the https
scheme, then HTTP over TLS
The HTTP Request IRI identifies the resource upon
which to apply the request and is transmitted using
the Request-URI, and optionally the Host header field,
as defined in
This binding extension specification provides a binding to HTTP of
This HTTP binding extension MAY be used with other message exchange patterns, such as outbound message exchange patterns, provided that additional semantics are defined, for example through an extension.
Each of the three supported message exchange patterns above involves
one or two messages or faults being exchanged.
For successful responses, the HTTP response code MUST be:
For every
The HTTP binding extension adds the following properties
to the WSDL component model (as defined in
Accept HTTP header defined by the HTTP
1.1 specification, Section 14.1 (see
The prefix "Accept:" MUST NOT be used.
The rule qdtext is changed from:
qdtext = <any TEXT except<">>
to:
qdtext = <any CHAR except<">>
This change is made to disallow non-US-ASCII OCTETs.
These properties indicate the range of media types and
associated parameters with which an instance MAY be
serialized.
The use of
The XML representation for binding an Operation are six
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of "&" and ";" being the most frequently used
characters in practice.
The following
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the
|
|
| The actual value of the
|
|
| The actual value of the
|
|
| The actual value of the |
|
| The actual value of the |
|
| The actual value of the |
|
| The actual value of the
|
|
| The actual value of the
|
HTTP allows the use of headers in messages. This binding extension allows users to declare the HTTP headers in use on a per message and on a per-fault basis.
The HTTP Header binding extension specification adds the
following property to the WSDL component model (as defined
in
Similarly,
An
The properties of the
field-name production rules as specified
in section 4.2 of
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| The set of |
|
| The value of the |
|
| The |
|
| The actual value of the |
|
|
The |
WSDL Version 2.0 Part 1: Core Language
An
wsdl.extension(http://www.w3.org/ns/wsdl/http,
whttp.header(
parent
name
For every
The HTTP Fault binding extension adds the following
property to the WSDL component model (as defined in
The XML representation for binding an HTTP Fault is an
a
A [local name] of
A [namespace name] of
A type of union of
See
| Property | Value |
|---|---|
| The actual value of the
|
This section specifies three serialization formats defining rules to encode the
Other serialization formats may be defined. Those MAY place
restrictions on the style of the
| - | Serialization of the instance data in parts of an HTTP message | ||||
|---|---|---|---|---|---|
| In the request URI | In the message body | ||||
| HTTP request (input message) | Without message body: GET, DELETE, … | All, some or none | - | - | - |
| With message body: POST, PUT, … | All, some or none | Remainder | All | All | |
| HTTP response (output message) | - | - | - | All | |
| HTTP Method | Request | |||
|---|---|---|---|---|
| Request URI: query parameters or path components | Input serialization | |||
| Without message body: GET, DELETE, … | IRI style | IRI style | - | - |
| With message body: POST, PUT, … | IRI style, if any data is serialized as path components or query parameters | IRI style | Multipart style | None required |
This section defines templating rules for the
With this HTTP binding, part of the instance data for HTTP requests MAY be serialized in the HTTP request IRI, and another part MAY be serialized in the HTTP message body.
The
either by enclosing the element name within curly
braces. For example,
or by enclosing the element name within exclamated-curly
braces, to include the element without percent-encoding.
For example,
The request IRI is constructed as follows
(ALPHA and DIGIT below are defined as per
Each raw template (
Each encoded template (
The characters in the range: "&" | ";" | "!" | "$" | "'" | "(" |
")" | "*" | "+" | "," | "=" | ":" | "@"
SHOULD be percent-encoded.
The other characters, EXCEPT the ones in the range:
ALPHA | DIGIT | "-" | "." | "_" | "~",
MUST be percent-encoded.
Each encoded template
(
The value of the
The characters in the range: "&" | ";" | "!" | "$" | "'" | "(" |
")" | "*" | "+" | "," | "=" | ":" | "@" | "?" | "/"
SHOULD be percent-encoded.
The other characters, EXCEPT the ones in the range:
ALPHA | DIGIT | "-" | "." | "_" | "~",
MUST be percent-encoded.
Each uncited element (i.e. each element not referenced in a template) to be serialized, if any, is encoded as for an encoded template.
Percent-encoding MUST be performed using the UTF-8 representation of the character
as prescribed by section 6.4 of
Each double curly brace (
Note that the mechanism described in this section could be used to
indicate the entire absolute IRI, including the scheme, host, or port, for example:
This serialization format is designed to allow a client or
Web service to produce an IRI based on the application/x-www-form-urlencoded.
In this serialization, the rules for constructing the HTTP request IRI using elements cited in the
The remainder of the instance data is formatted as a
query string as defined in
If the HTTP method used for the request
does not allow a message body, then this query string is serialized as parameters in the request
IRI (see
Non-nil
elements with a possibly empty single value of the
Each parameter pair is separated by the value of the
Uncited elements with single values (non-list) are serialized as a single name-value parameter pair. The name of the parameter is the local name of the uncited element, and the value of the parameter is the value of the uncited element.
Uncited elements with list values are serialized as one name-value parameter pair per-list value. The name of each parameter is the local name of the uncited element, and the value of each parameter is the corresponding value in the list. The order of the list values is preserved.
Replacement values falling outside the range (ALPHA and DIGIT below are defined as per
ALPHA | DIGIT | "-" | "." | "_" | "~" | "!" | "$" | "&" | "'"
| "(" | ")" | "*" | "+" | "," | ";" | "=" | ":" | "@",
MUST be percent-encoded. Percent-encoding MUST be performed using the
UTF-8 representation of the character as prescribed by section 6.4 of
The following instance data of an input message:
with the following value of the
and the following value of the
will produce the following query string:
This serialization format adds the following property to the
The XML representation for this property is an
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
The mapping from the XML representation to component properties is as follows:
| Property | Value |
|---|---|
| The actual value of the
|
If the
Finally, the query string computed in
The instance data defined in
and the following
will serialize the message in the HTTP request as follows:
Finally, the query string computed in
Content-Type HTTP header field must
have the value
application/x-www-form-urlencoded.
The instance data defined in
and the following
will serialize the message in the HTTP request as follow:
In this serialization, for HTTP requests, the rules for constructing the HTTP request IRI
defined in
The
Content-Type
HTTP header MUST have the value
application/xml application/xml as specified in section
In this serialization, for HTTP requests, the rules for constructing the HTTP request IRI
defined in
This format is for legacy compatibility to permit the use of
XForms clients with
Each element in the sequence is serialized into a part as follow:
Content-Disposition header MUST have the
value form-data, and its name
parameter is the local name of the element.
Content-Type header MUST have the value:
application/xml (or a media type
compatible with application/xml) if the
element has a complex type;
application/octet-stream if the element
is of type
xs:base64Binary,
xs:hexBinary, or a derived type;
text/plain if the element has a simple
type; The charset MUST be set appropriately. UTF-8 or
UTF-16 MUST be at least supported.
If the type is xs:base64Binary,
xs:hexBinary, xs:anySimpleType
or a derived type, the content of the part is the content
of the element. If the type is a complex type, the element
is serialized following the rules defined in the
The following instance data of an input message:
with the following
will serialize the message as follow:
Every
The HTTP binding extension provides a mechanism for indicating a
default value at the
If no value is specified, no claim is being made.
The HTTP binding extension specification adds the following
properties to the WSDL component model (as defined in
Similarly,
These properties are not relevant when HTTP 1.0 is used.
The XML representation for specifying the content encoding
is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
The XML representation for specifying the default
content encoding is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the
|
|
| The actual value of the
|
|
| The actual value of the
|
|
| The actual value of the
|
The
The HTTP binding extension specification adds the following
property to the WSDL component model (as defined in
The XML representation for specifying the use of HTTP cookies
is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the |
Every
This binding extension specification allows the authentication scheme and realm to be specified.
The HTTP binding extension specification adds the following
property to the WSDL component model (as defined in
The XML representation for specifying the use of HTTP
access authentication
is two OPTIONAL
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the |
|
| The actual value of the |
An
This document is the work of the
Members of the Working Group are (at the time of writing, and by alphabetical order): Charlton Barreto (Adobe Systems, Inc), Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of Maryland), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe Systems), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Michael Shepherd (Xerox), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçınalp (SAP AG), Peter Zehler (Xerox).
Previous members were: Eran Chinthaka (WSO2), Mark Nottingham (BEA Systems, Inc.), Hugo Haas (W3C), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), Lily Liu (webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup), Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox), Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler Research and Technology), Tim Finin (University of Maryland), Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur), Mark Jones (AT&T), Steve Lind (AT&T), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret (W3C), Jim Hendler (University of Maryland), Dietmar Gaertner (Software AG), Michael Champion (Software AG), Don Mullen (TIBCO Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke (Global Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks & Associates), Ingo Melzer (DaimlerChrysler Research and Technology), Sandeep Kumar (Cisco Systems), Alan Davies (SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA Technologies), Mike McHugh (W. W. Grainger), Michael Mealling (Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland (BEA Systems, Inc.), Ümit Yalçınalp (Oracle Corporation), Peter Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft Corporation), Hao He (The Thomson Corporation), Erik Ackerman (Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods, Inc.), William Vambenepe (Hewlett-Packard Company), David Booth (W3C), Sanjiva Weerawarana (IBM), Asir Vedamuthu (webMethods, Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin (Microsoft Corporation), Rebecca Bergersen (IONA Technologies), Ugo Corda (SeeBeyond).
The people who have contributed to
| Component | Defined Properties |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Property | Where Defined |
| element declaration | SOAP Header Block. |
| http authentication realm | Endpoint. |
| http authentication scheme | Endpoint. |
| http content encoding | Binding Fault. |
| http content encoding default | Binding. |
| http cookies | Binding. |
| http error status code | Binding Fault. |
| http fault serialization | Binding Operation. |
| http headers | Binding Fault. |
| http input serialization | Binding Operation. |
| http location | Binding Operation. |
| http location ignore uncited | Binding Operation. |
| http method | Binding Operation. |
| http method default | Binding. |
| http output serialization | Binding Operation. |
| http query parameter separator | Binding Operation. |
| http query parameter separator default | Binding. |
| mustUnderstand | SOAP Header Block. |
| name | HTTP Header. |
| parent | HTTP Header. |
| ref | SOAP Module. |
| required | HTTP Header. |
| rpc signature | Interface Operation. |
| safe | Interface Operation. |
| soap action | Binding Operation. |
| soap fault code | Binding Fault. |
| soap fault subcodes | Binding Fault. |
| soap headers | Binding Fault. |
| soap mep | Binding Operation. |
| soap mep default | Binding. |
| soap modules | Binding. |
| soap underlying protocol | Binding. |
| soap version | Binding. |
| type definition | HTTP Header. |
This appendix summarizes assertions about WSDL 2.0 documents and components that are not enforced by the WSDL 2.0 schema. Each assertion is assigned a unique identifier which WSDL 2.0 processors may use to report errors.
| Id | Assertion |
|---|---|
|
|
An OPTIONAL |
|
|
Additionally, each even-numbered item (0, 2, 4, ...) in the list
MUST be of type |
| Id | Assertion |
|---|---|
|
|
However, extensions or binding extensions MAY modify these rulesets. |
|
|
If the
|
|
|
When formulating the HTTP message to be transmitted, the HTTP request method used MUST be selected using one of the following: |
|
|
When formulating the HTTP message to be
transmitted, content encoding for a given |
|
|
When formulating the HTTP fault message
to be transmitted, content encoding for a given |
|
|
When formulating the HTTP message to be transmitted, the
contents of the payload (i.e. the contents of the HTTP message
body) MUST be what is defined by the corresponding |
|
|
If the value is |
|
|
If the |
|
|
The serialization rules for messages whose |
|
|
The fault definition SHOULD agree with the definition
of the HTTP error codes, as specified in section 8 of |
|
|
An integer value
of this property identifies the error Status-Code as defined by |
|
|
When formulating the HTTP Request, the HTTP Request IRI
is an absolute IRI reference and is the value of the
|
|
|
The first one is transmitted using an HTTP request, and the second one is transmitted using the corresponding HTTP response. |
|
|
In cases where only one single message is being sent, the message body of the HTTP response MUST be empty. |
|
|
It MUST contain an IRI reference and MUST NOT include a fragment identifier component. |
|
|
The value of the |
|
|
Wild cards (for example, |
|
|
A value of |
|
|
If the
|
|
|
The HTTP binding MUST NOT set an HTTP
header field corresponding to the value of the |
|
|
If the value of an |
|
|
A |
|
|
This type MUST be a simple type. |
|
|
If the value is |
|
|
The |
|
|
When serializing an HTTP request that does not allow an HTTP message body,
and when |
|
|
The value of the Accept HTTP header defined by the HTTP
1.1 specification, Section 14.1 (see |
|
|
The
|
|
|
If the |
|
|
The resulting IRI MUST be mapped to an URI for use in
the HTTP Request as per section 3.1 "Mapping of IRIs to
URIs" of the IRI specification |
|
|
The local name in a template SHOULD match at least one element
from the |
|
|
If this format is used then the
|
|
|
For the HTTP binding defined in this section
( |
|
|
If not all elements from the |
|
|
For elements of the instance data not cited in the
|
|
|
If the HTTP request method used does not allow
HTTP message body (e.g. |
|
|
If the HTTP request method used does allow an
HTTP message body (e.g. |
|
|
The Content-Type HTTP header field must
have the value
application/x-www-form-urlencoded. |
|
|
The Content-Type
HTTP header MUST have the value
application/xml application/xml as specified in section |
|
|
this serialization format may only be used to serialize the HTTP request corresponding to the initial message of an interface operation. |
|
|
Specifically, for the HTTP binding defined in this section
( |
|
|
The Content-Disposition header MUST have the
value form-data, and its name
parameter is the local name of the element. |
|
|
The Content-Type header MUST have the value: |
|
|
The |
|
|
When using this style, the value of the |
|
|
The sequence MUST only contain elements. |
|
|
The sequence MUST contain only local element children. |
|
|
The localPart of the element's QName MUST be the same
as the |
|
|
The complex type that defines the body of the element or its children elements MUST NOT contain any attributes. |
|
|
The children elements of the sequence MUST derive from
xs:simpleType, and MUST NOT be of the type
or derive from xs:QName,
xs:NOTATION, xs:hexBinary or
xs:base64Binary. |
|
|
The |
|
|
The |
|
|
202 when the MEP is |
|
|
204 when the MEP is |
|
|
When using this style, the value of the |
|
|
The sequence MUST only contain elements. |
|
|
The sequence MUST contain only local element children. |
|
|
The attributes
1. |
|
|
The localPart of the element's QName MUST be the same
as the |
|
|
The complex type that defines the body of the element or its children elements MUST NOT contain any attributes. |
|
|
The sequence MUST NOT contain multiple children element declared with the same local name. |
|
|
However, an operation SHOULD be marked safe
if it meets the criteria for a safe interaction defined in
Section 3.4 of |
|
|
If the RPC style is used by an |
|
|
The value of the |
|
|
The content model of input and output
|
|
|
The input sequence MUST only contain elements and element wildcards. |
|
|
The input sequence MUST NOT contain more than one element wildcard. |
|
|
The element wildcard, if present, MUST appear after any elements. |
|
|
The output sequence MUST only contain elements. |
|
|
Both the input and output sequences MUST contain only local element children. |
|
|
The local name of input element's QName MUST be
the same as the |
|
|
Input and output elements MUST both be in the same namespace. |
|
|
The complex type that defines the body of an input or an output element MUST NOT contain any local attributes. |
|
|
If elements with the same qualified name appear as children of both the input and output elements, then they MUST both be declared using the same named type. |
|
|
The input or output sequence MUST NOT contain multiple children elements declared with the same name. |
|
|
The |
|
|
A |
|
|
When formulating
the SOAP envelope to be transmitted, the contents of the
payload (i.e., the contents of the SOAP Body |
|
|
If the |
|
|
Every SOAP binding MUST indicate what version of SOAP is in use for the operations of the interface that this binding applies to. |
|
|
Every SOAP binding MUST indicate what underlying protocol is in use. |
|
|
For every |
|
|
when the value of the |
|
|
These properties MUST NOT be used unless the underlying protocol is HTTP. |
|
|
This default
binding rule is applicable when the value of the
|
|
|
When its value is
|
|
|
If the value is |
|
|
The
value of the |
|
|
A |
|
|
A |
|
|
For a given |
|
|
A |
|
|
OPTIONAL, but MUST be present when the style is RPC |
|
|
Values for the second component MUST be chosen among the following four: "#in", "#out", "#inout" "#return". |
|
|
The value of the first component of each pair |
|
|
For each child element of the input and output messages of the operation,
a pair |
|
|
For each pair |
|
|
For each pair |
|
|
For each pair |
|
|
For each pair |
| Id | Assertion |
|---|---|
|
|
Cited elements (i.e.
elements referenced in templates) MUST NOT
carry an |
|
|
If any,
the value of the SOAP |
|
|
If the value is |
|
|
If the value is |
| Id | Assertion |
|---|---|
|
|
The fault message MUST be delivered to the same target node as the message it replaces, unless otherwise specified by an extension or binding extension. If there is no path to this node, the fault MUST be discarded. |
|
|
The fault message MUST be delivered to the originator of the triggering message, unless otherwise specified by an extension or binding extension. Any node MAY propagate a fault message, and MUST NOT do so more than once for each triggering message. If there is no path to the originator, the fault MUST be discarded. |
|
|
Nodes that generate faults MUST attempt to propagate the faults in accordance with the governing ruleset, but it is understood that any delivery of a network message is best effort, not guaranteed. |
|
|
When a fault is generated, the generating node MUST attempt to propagate the fault, and MUST do so in the direction and to the recipient specified by the ruleset. |
|
|
When the Fault Replaces Message propagation rule is in effect, any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical direction. |
|
|
The |
|
|
The |
|
|
by some prior agreement, another node and/or the service MAY send messages (to each other or to other nodes) that are not described by the pattern. |
|
|
Generation of a fault, regardless of ruleset, terminates the exchange. |
|
|
When the Message Triggers Fault propagation rule is in effect, any message, including the first in the pattern, MAY trigger a fault message, which MUST have opposite direction. |
|
|
When the No Faults propagation rule is in effect, faults MUST NOT be propagated. |
|
|
A node MAY be accessible via more than one physical address or transport. |
|
|
The |