WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts defines predefined extensions for use in WSDL 2.0:
Message exchange patterns
Operation styles
Binding Extensions
This
specification depends on WSDL Version 2.0
This is the
This Working Draft addresses all the comments received during
the first Last Call review period on the WSDL 2.0
drafts. Another Last Call Working Draft resulting from the merge
of the previous drafts of WSDL 2.0 Part 2 and 3 is being
published as substantive changes were made to the documents as a
result of this review. The detailed disposition of the comments
received can be found in the
The Working Group would like to add a defaulting rule for
one-way message exchange patterns in the SOAP 1.2 binding
defined in section
Comments on this document are to be sent to the public
A
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced under the
Last Modified: $Date: 2005/08/02 20:36:17 $ CET
The Web Services Description Language WSDL Version 2.0 (WSDL)
Message exchange patterns:
Operation styles:
Binding extensions:
A SOAP 1.2
An HTTP/1.1
WSDL 2.0 Primer
The Core Language
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 |
|
A normative XML Schema |
| wsdl-x |
|
A normative XML Schema |
| wsoap |
|
A normative XML Schema |
| whttp |
|
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
A
A node may be accessible via more than one physical address or transport.
Web Services Description Language (WSDL) message exchange patterns (hereafter simply
'patterns') define the sequence and 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.
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 like timing between messages, whether the pattern is synchronous or asynchronous, and whether the message 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; by some prior agreement, another node and/or the service may send other messages (to each other or to other nodes) that are not described by the pattern. For instance, even though a pattern may define a single message sent from a service to one other node, the Web Service may multicast that message to 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 here, after examination of existing predefined patterns.
This pattern consists of [number] message[s, in order] as follows:
[enumeration, specifying, for each message] A[n optional] message:
indicated by a
[received from|sent to] ['some' if first mention] node [node identifier]
This pattern uses the rule [fault ruleset reference].
An operation using this message exchange pattern has a
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 may occur. The most common patterns for fault propagation are defined here, and referenced by patterns later in the document. "Propagation" is defined as a best-effort attempt to transmit the fault message to its designated recipient.
WSDL patterns specify propagation of faults, not their generation.
Nodes which generate a fault 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. The
rulesets establish the direction of the fault message and the fault
recipient, they do not provide reliability or other delivery guarantees.
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. However, extensions or binding extensions
MAY modify these rulesets. For example, WS-Addressing
Generation of a fault, regardless of ruleset, terminates the exchange.
Binding extensions, features, or extension specifications may override the semantics of a fault propagation ruleset, but this practice is strongly discouraged.
Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical direction. 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.
Any message, including the first in the pattern, MAY trigger a fault message, which MUST have opposite direction. The fault message MUST be delivered to the originator of the triggering message, unless otherwise specified by an extension of 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.
No faults may be propagated.
WSDL patterns are described in terms of the WSDL component model,
specifically the
This pattern consists of exactly one message as follows:
A message:
indicated by a
received from some node N
This pattern uses the rule
An operation using this message exchange pattern has a
This pattern consists of exactly one message as follows:
A message:
indicated by a
received from some node N
This pattern uses the rule
An operation using this message exchange pattern has a
This pattern consists of exactly two messages, in order, as follows:
A message:
indicated by a
received from some node N
A message:
indicated by a
sent to node N
This pattern uses the rule
An operation using this message exchange pattern has
a
This pattern consists of one or two messages, in order, as follows:
A message:
indicated by a
received from some node N
An optional message:
indicated by a
sent to node N
This pattern uses the rule
An operation using this message exchange pattern has
a
This pattern consists of exactly one message as follows:
A message:
indicated by a
sent to some node N
This pattern uses the rule
An operation using this message exchange pattern has
a
This pattern consists of exactly one message as follows:
message:
indicated by a
sent to some node N
This pattern uses the rule
An operation using this message exchange pattern has
a
This pattern consists of exactly two messages, in order, as follows:
A message:
indicated by a
sent to some node N
A message:
indicated by a
sent from node N
This pattern uses the rule
An operation using this message exchange pattern has
a
This pattern consists of one or two messages, in order, as follows:
A message:
indicated by a
sent to some node N
An optional message:
indicated by a
sent from node N
This pattern uses the rule
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 may 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 may be obscured, or blame laid on a third party, or may enable or exacerbate denial-of-service attacks.
Security mechanisms addressing such attacks may 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 an HTTP binding per this specification (see
The safety extension adds the following property to the
The XML representation for the safety extension is an
An OPTIONAL
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 assigning to an
In order to conform with the specification for the RPC style,
an
The RPC style MUST NOT be used for
The RPC style places restrictions for Remote Procedure
Call-types of interactions. When this value is used, the
associated messages MUST conform to the rules below,
described using XML Schema
If the
The content model of input and output
The input sequence MUST only contain elements and element wildcards. It MUST NOT contain other structures such as xs:choice. 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. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element children. Note that these child elements MAY contain the following attributes: nillable, minOccurs and maxOccurs.
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. Extension attributes are allowed for purposes
of managing the message infrastructure (e.g. adding identifiers
to facilitate digitally signing the contents of the message).
They must not be considered as part of the application data
that is conveyed by the message. Therefore, they are never
included in an RPC signature (see
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
When present, the
The value of the
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
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/2005/08/wsdl/rpc"
The type of the
Additionally, each even-numbered item (0, 2, 4, ...) in the list
MUST be of type
A
| Property | Value |
|---|---|
| A list of |
The IRI style may be used for
The IRI style is selected by assigning the
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.
The sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element
children. These child elements MAY contain the
0 or 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 elements declared with the same local name.
If the children elements of the sequence are
defined using an XML Schema type, they 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 Multipart style may be used for
The Multipart style is selected by assigning the
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.
The sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element
children. These child elements MAY contain the
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.
The SOAP binding extension described in this section is SOAP version
independent ("1.2" as well as other versions) and 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 which apply for all
Notice that there are no default binding rules defined for
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
If the value is
If the value is
If the
This SOAP binding extension only allows one single element in SOAP body.
And, if the
SOAP header blocks other than the ones declared in the
Every SOAP binding MUST indicate what version of SOAP is in use for the operations of the interface that this binding applies to.
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 |
Every SOAP binding MUST indicate what underlying protocol is in use.
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 |
Every
The default SOAP MEP specification is a syntactic convenience and does not affect the underlying component model.
The XML representation for specifying the default SOAP
MEP is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
For every
The SOAP Fault binding extension adds the following
properties to the WSDL component model (as defined in
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 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 an Operation are two
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
See
| Property | Value |
|---|---|
| The actual value of the
|
|
| The actual value of the
|
In SOAP, it is permissible for specification interaction
to engage one or more additional features (typically
implemented as one or more SOAP header blocks), as defined
by SOAP Modules (see
The
The SOAP modules applicable for a particular operation of
any service consists of all 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 |
WSDL Version 2.0 Part 1: Core Language
A
wsdl.extension(http://www.w3.org/2005/08/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 ond on a per fault basis.
The SOAP Header Blocks binding extension specification adds the
following property to the WSDL component model (as defined
in
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
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 |
WSDL Version 2.0 Part 1: Core Language
A
wsdl.extension(http://www.w3.org/2005/08/wsdl/soap,
wsoap.header(
parent
namespace
name
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
The WSDL SOAP 1.2 binding extension supports
the SOAP 1.2 HTTP binding defined by the
Default rules in section
When the SOAP Message Exchange Pattern is the SOAP 1.2 Response
MEP and the underlying protocol is HTTP, the
These default binding rules are applicable to SOAP 1.2 bindings.
x-www-form-urlencoded is the only supported
serialization format for HTTP GET in the SOAP Response
Message Exchange Pattern.
x-www-form-urlencoded serialization
format (see 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 which apply for all
Notice that there are no default binding rules defined for
A
If the
Section
| HTTP Method | Default Input Serialization | Default Output Serialization |
|---|---|---|
| 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 stype of the interface
operation bound (see
The default values 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 of such mechanisms are other message exchange
patterns or binding extensions.
Accept header, the HTTP client MAY take into
account the
Only
Each such
The HTTP header name used is the
The HTTP header content is serialized from the
corresponding
Every
By default, HTTP/1.1
The HTTP binding extension specification adds the following
property to the WSDL component model (as defined in
The XML representation for specifying the HTTP version
is an optional
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the |
Every
The default HTTP method specification is a syntactic convenience and does not affect the underlying component model.
The XML representation for specifying the default HTTP method
is an optional
A [local name] of
A [namespace name] of
A type of
The
This binding extension specification provides a binding to HTTP of
Each of the supported message exchange patterns involves one to two messages or faults being exchanged. The first is transmitted using an HTTP request, and the second is transmitted using the corresponding HTTP response. In cases where only one message is being sent, the message body of the HTTP response MUST be empty.
For every
The HTTP binding extension adds the following property
to the
application/x-www-form-urlencoded serialization defined
in section
If the resulting IRI uses the https
scheme, then HTTP over TLS
The XML representation for binding an Operation are four
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
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
|
HTTP allows the use of headers in messages. This binding extension allows users to declare the HTTP headers in use on a per message ond on a per fault basis.
The HTTP Header binding extension specification adds the
following property to the WSDL component model (as defined
in
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
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 |
WSDL Version 2.0 Part 1: Core Language
An
wsdl.extension(http://www.w3.org/2005/08/wsdl/http,
whttp.header(
parent
namespace
name
For every
The fault definition SHOULD NOT go against the definition
of the HTTP error codes, as specified in section 8 of
The HTTP Fault binding extension adds the following
property to the WSDL component model (as defined in
Reason-Phrase
as defined by Reason-Phrase that the service will use in case the fault
is returned. If empty, no claim is made by the
service.
The XML representation for binding an HTTP Fault are two
a
A [local name] of
A [namespace name] of
A type of union of
a
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 following serialization formats can be used to encode the
Other serialization formats may be used. Those MAY place restrictions on the style of the Interface Operation bound.
This serialization format is designed to allow a Web service
to produce a IRI based on the
Elements from the instance data can be inserted into the path of the request IRI, or a query parameter, as shown in the example below:
The following instance data of an input message
with the following
and the following
will serialize the message in the IRI as follow:
In this serialization, the value of the
This 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
When constructing the request IRI, each pair of
curly braces (and enclosed element name) is replaced
by the possibly empty single value of the
corresponding element. It is an error for this element
to carry an
A double curly brace (i.e.
An element MUST NOT be cited more than once within
the
An element name MAY be followed by a slash (i.e. "/")
inside curly braces
(e.g.
Strings enclosed within single curly braces MUST be
element names from the
If not all elements from the
If an element name appears in the
Non-nil
elements with a possibly empty single value of the
It is an error for the
If 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.
In addition to the serialization in the request IRI
of the elements cited in the
The following instance data of an input message
with the following
and the following
will serialize the message in an IRI as follows:
which will be %-encoded as a URI as follows:
and in the message as follow:
The
The Content-Type HTTP header MUST have the value
application/xml, or a media type compatible with
application/xml. Other HTTP headers, such as
Content-Encoding or
Transfer-Encoding, MAY be used.
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:
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:
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
It is an error for 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
property to the WSDL component model (as defined in
The XML representation for specifying the default
transfer coding is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
The XML representation for specifying the
transfer coding is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| The actual value of the
|
Every
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): Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of Maryland), Ugo Corda (SeeBeyond), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Hugo Haas (W3C), Tom Jordahl (Macromedia), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (Microsoft Corporation), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, Inc.), David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Maryland), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (Independent), Ümit Yalçınalp (SAP AG).
Previous members were: 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), Charlton Barreto (webMethods, Inc.), Asir Vedamuthu (webMethods, Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin (Microsoft Corporation).
The people who have contributed to
| Component | Defined Properties |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Property | Where Defined |
| element | SOAP Header Block. |
| http authentication realm | Endpoint. |
| http authentication scheme | Endpoint. |
| http cookies | Binding. |
| http error reason phrase | Binding Fault. |
| http error status code | Binding Fault. |
| http fault serialization | Binding Operation. |
| http headers | Binding Message Reference. |
| http input serialization | Binding Operation. |
| http location | Binding Operation. |
| http method | Binding Operation. |
| http output serialization | Binding Operation. |
| http query parameter separator | Binding Operation. |
| http transfer coding | Binding Message Reference. |
| http version | Binding. |
| mustUnderstand | SOAP Header Block. |
| ref | SOAP Module. |
| required | SOAP Module. |
| rpc signature | Interface Operation. |
| safety | Interface Operation. |
| soap action | Binding Operation. |
| soap fault code | Binding Fault. |
| soap fault subcodes | Binding Fault. |
| soap headers | Binding Message Reference. |
| soap mep | Binding Operation. |
| soap modules | Binding. |
| soap underlying protocol | Binding. |
| soap version | Binding. |
| Date | Author | Description |
|---|---|---|
| 20050728 | HH | |
| 20050728 | HH | Clarified {soap action} scope for SOAP 1.2 binding. |
| 20050728 | HH | |
| 20050725 | RRC | |
| 20050707 | aal | Modified 2.2.2 per text supplied by Jean-Jacques. |
| 20050616 | AGR | Fixed component table. |
| 20050616 | JJM | Added markup to list all the components and properties used in Part 2 (although this currently [wrongly] shows those of Part 1). |
| 20050616 | JJM | Fixed wrong component names for properties. Renamed HTTP Header Block to HTTP Header. |
| 20050614 | RRC | |
| 20050615 | JJM | Further pass at adding markup for properties. Fixed issues with entities preventing validation. |
| 20050615 | JJM | Added <propdef> and <prop> markup around properties. |
| 20050614 | JJM | Finished adding <comp> markup around components. |
| 20050613 | JJM | Started adding <comp> markup around components. |
| 20050613 | JJM | |
| 20050613 | JJM | |
| 20050613 | RRC | |
| 20050606 | HH | |
| 20050606 | HH | wsoap:code is now optional, and aligned
whttp:code
|
| 20050602 | HH | |
| 20050527 | HH | |
| 20050527 | HH | |
| 20050520 | JJM | |
| 20050519 | aal | added template to guide readers when defining new message exchange patterns. |
| 20050512 | HH | |
| 20050512 | HH | application/x-www-url-encoded serialization |
| 20050509 | RRC | |
| 20050509 | RRC | |
| 20050505 | aal | LC52c: state that soap faults have no reasonable default. |
| 20050505 | aal | LC76a: allow extensions to override faults in rulesets; LC76b: define "propagate" in rulesets. |
| 20050429 | RRC | |
| 20050429 | RRC | |
| 20050422 | HH | |
| 20050420 | JJM | Fixed typos in RPC section (part of LC78). |
| 20050413 | AV | wsoap:header and whttp:header (removed required and changed default binding rules) |
| 20050412 | RRC | LC75h: added note on multiple return values in rpc style |
| 20050415 | HH | |
| 20050408 | HH | application/x-www-url-encoded serialization |
| 20050408 | HH | |
| 20050408 | HH | |
| 20050408 | HH | |
| 20050408 | HH |
Added |
| 20050407 | HH | |
| 20050406 | HH | |
| 20050331 | HH | |
| 20050331 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050317 | HH | |
| 20050316 | HH |
| Date | Author | Description |
|---|---|---|
| 20050613 | JJM |
|
| 20050222 | aal | Implement editorial changes for LC39, LC40, LC48c. |
| 20050220 | AGR |
|
| 20041209 | aal | add clarifying language for fault propagation, per LC54/76. |
| 20040713 | aal | implement editorial changes requested after review by GlenD, in application data feature and module. |
| 20040713 | aal | address issues 233 & 112 all at once, by increasing level of all divs, adding new intro div, adding new div to contain features, renaming spec. Lotsa changes, what fun. |
| 20040713 | aal | s/Label/Message Label/g and s/{label}/{message label}/g. issue 230. |
| 20040713 | aal | replace "fault generation" with "fault propagation" (in almost all cases; one case of "generate" remains to indicate that it ends an exchange). issue 234. |
| 20040713 | aal | add language to introduction describing relationship between these MEPs and the MEPs defined by SOAP 1.2 (issue 232). This replaces the language found two items down (issue 191). |
| 20040713 | aal | add (hereafter, simply 'patterns') to intro (issue 231). |
| 20040610 | aal | add language to introduction describing relationship between these MEPs and the MEPs defined by SOAP 1.2 (issue 191). |
| 20040225 | aal | add in-optional-out per minutes of 20 feb 2004 telecon |
| 20040212 | aal | change {messageReference} to {label} and "Message Reference component" to "Label component" per 20040212 teleconference |
| 20040205 | aal | change all 'A' and 'B' message labels into 'Out' or 'In', depending upon direction. |
| 20040205 | aal | s/message pattern/message exchange pattern/gi |
| 20031204 | jcs | Removed change marks; note that some were on div2 tag and did not show when transformed into HTML. |
| 20031204 | jcs | Per 4 Dec 2003 telecon, decided to rename 'Asynchronous Out-In' pattern to 'Output-Optional-Input'. |
| 20031105 | aal | Fix titles of added patterns. Move them to be in conjunction with similar patterns. |
| 20031022 | aal | Per action item from October 16 teleconference, added the three patterns using message-triggers-fault as published on the mailing list (robust-in-only, robust-out-only, asynch-out-in). |
| 20031022 | aal | Added internal linkage (using specref) from patterns to the fault rulesets which they use. |
| 20031022 | aal | Per 9 and 16 Oct 2003 teleconferences, marked in-multi-out and out-multi-in patterns deleted. |
| 20031022 | aal | Per 16 Oct 2003 teleconference, added a paragraph/sentence stating that generation of a fault terminates an exchange. |
| 20031007 | JCS | Per 2 Oct 2003 teleconference, changed "broadcast" to "multicast" in the introduction. |
| 20030922 | JCS | Per 22 Sep 2003 meeting in Palo Alto, CA, removed "Pattern Review" editorial note; added specific editorial notes for In-Multi-Out and Out-Multi-In. |
| 20030911 | RRC | Changed the "name" property of the message reference component to "messageReference". |
| 20030904 | JCS | Incorporated clarifications suggested by W3C\David Booth. |
| 20030801 | JCS | Per 30 July meeting, added recommendations from patterns task force. |
| 20030612 | AAL | Added fault generation rulesets and references to them from patterns. |
| 20030313 | MJG | Changed to Part 2 ( from Part 3 ) |
| 20030306 | JCS | Proposed name for MEP7. |
| 20030305 | JCS | Per 4 Mar 03 meeting, renamed 'message exchange pattern' to 'message pattern' or 'pattern', added pattern for request-response, added ednote about review of patterns. |
| 20030217 | MJG | Fixed some issues with entities and validity errors WRT ulists |
| 20030212 | JCS | Initial draft |
| Date | Author | Description |
|---|---|---|
| 20050310 | JJM | Replaced <definitions> with <description>. |
| 20050310 | JJM | Fixed missing fault pseudo-schema. |
| 20050301 | RRC | |
| 20050301 | RRC | |
| 20050221 | HH | |
| 20050211 | HH | |
| 20050120 | HH | |
| 20050120 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041208 | AV | Introduced SOAP version independent WSDL SOAP Binding. Added two new sections, "Specifying the SOAP Version" and "SOAP 1.2 Binding". Plus, lots of shuffling. |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040909 | HH | |
| 20040909 | HH | |
| 20040730 | HH | Removed |
| 20040730 | HH | Removed AD Feature HTTP serialization. |
| 20040729 | HH | Added AD Feature support in HTTP binding. |
| 20040727 | HH | Clarified interaction between SOAP binding and HTTP binding properties |
| 20040727 | HH | Renamed http prefix whttp |
| 20040727 | SW | Implemented Umit's proposal to mark MTOM as one optimization mechanism. |
| 20040726 | HH | Restricted URI style with regards to QNames and added trailing / in URL-encoded syntax |
| 20040723 | HH | Addressed issue 246: limited MEP to In-Out, In-Only and Robust In-Only |
| 20040723 | HH | Addressed issue 226. |
| 20040723 | HH | Addressed 249: major reorganization of the HTTP binding to be presented in a functional way like the SOAP binding rather than in a syntactical way. |
| 20040722 | SW | Moved SOAP binding syntax summary to the top per request. Also fixed the value of the binding/@type property in the pseudo-schema to show that its a SOAP binding. |
| 20040722 | HH | Added HTTP error code attribute on fault binding. Added relationship between instance data and properties in the component model. Addresses issue 166. |
| 20040722 | HH | Renamed SOAP protocol into underlying protocol. |
| 20040721 | HH | Set the {type} property of binding for HTTP binding. |
| 20040721 | HH | Fixes for issue 177. |
| 20040720 | HH | Cross-referenced Part 1 properties. |
| 20040720 | HH | Specified default serialization format for HTTP binding, as well as made clear how the defined serialization formats apply constraints on interface operation styles |
| 20040705 | JJM | Added note to indicate only one element per SOAP body. |
| 20040702 | SW | Corrected how the SOAP binding is indicated .. I had forgotten about binding/@type! |
| 20040625 | SW | Made pseudo-syntax consistent with part1 |
| 20040624 | SW | Update the rest of the SOAP binding stuff and consistified everything. |
| 20040624 | SW | Cleaned up how SOAP modules were described. Added default SOAP MEP stuff. |
| 20040623 | SW | Added default binding rules about HTTP URI generation. |
| 20040623 | SW | Added default binding rules about SOAP MEP selection and HTTP Method selection. |
| 20040623 | SW | Fixed up soapaction default rules |
| 20040623 | SW | Allowed use of MTOM for payload serialization |
| 20040623 | SW | Fixed up the wsoap:protocol section |
| 20040618 | SW | Re-introduced AII and EII entity refs. |
| 20040618 | SW | Made soap:module compose with nearest-wins rule. |
| 20040606 | DO | Cleanup on http binding section - had missed some properties. completed removal of @separator |
| 20040604 | DO | Major rewrite of http binding. Moved to component model, added http properties, added input/output serialization, removed @separator, added self as editor |
| 20040526 | SW | Removed wsoap:address |
| 20040526 | SW | Editorial/small corrections per F2F decisions |
| 20040526 | SW | Made soap binding be mostly attribute based per F2F decision |
| 20040519 | SW | removed spurious fault element inside binding/operation/{in,out}put from syntax summary |
| 20040519 | SW | Put in wsoap:module at operation level in the syntax summary (was missing) |
| 20040519 | SW | Removed old SOAP binding text |
| 20040519 | SW | Removed wsoap:header |
| 20040519 | JJM | Added SOAP Address section |
| 20040519 | JJM | Added SOAP Operation section |
| 20040519 | JJM | Replace reference to "XML" by "XML1.0" |
| 20040519 | JJM | Added SOAP Fault section |
| 20040519 | JJM | Added SOAP Header section |
| 20040519 | JJM | Added SOAP Module section |
| 20040516 | SW | Finished writing up soap:binding |
| 20040516 | SW | Added myself as an editor. |
| 20040514 | SW | Added default binding rules. |
| 20040514 | SW | Commented out old totally out of date SOAP binding. |
| 20040514 | JJM | Rework the binding and module sections. Reindent to match the structure of the HTTP binding. |
| 20040511 | JJM | Updated SOAP binding pseudo-schema, according to telcon 20040506. |
| 20040511 | JJM | Updated SOAP binding introduction. |
| 20040401 | JJM | Fixed one remaining occurrence of "verb" (instead of "method"). |
| 20040326 | JJM | Sanitized ednotes. Added new ednotes indicating the SOAP binding needs work and the HTTP binding is (mostly) OK. |
| 20040326 | JJM | Added Philippe's note on URIPath, as per telcon 20040325. |
| 20040305 | JJM | Removed the archaic MIME binding, now superseeded by the HTTP binding anyway. |
| 20040305 | JJM | Included Philippe's changes to the HTTP binding. |
| 20031103 | JJM | Fix new non-normative SOAP binding pseudo-schema. |
| 20031102 | SW | Updated SOAP binding. |
| 20031102 | SW | Change 1.2 to 2.0 per WG decision to rename. |
| 20030606 | JJM | Replaced <kw/> by <b/>. Indicated that pseudo-schemas are not normative |
| 20030604 | JJM | Reformated pseudo-syntax elements to match Part 1 layout |
| 20030529 | JCS | Incorporated text to resolve Issue 6e |
| 20030523 | JJM | Commented out MIME binding example; this is primer stuff. |
| 20030523 | JJM | Added pseudo-syntax to all sections. |
| 20030523 | JJM | Started converting the fault and headerfault sections to component model. |
| 20030523 | JJM | Complete the Multipart and x-www-form-urlencoded sections. |
| 20030523 | JJM | Fixed typos in HTTP binding (in particular added NOT in some section headers). |
| 20030522 | JCS | Added rules for serializing HTTP response |
| 20030522 | JCS | Added cardinality to pseudo schema for HTTP binding |
| 20030522 | JCS | Changes @transport to @protocol for SOAP binding |
| 20030522 | JJM | Incorporated remaining text from Philippe into the HTTP binding. |
| 20030522 | JJM | Polished the HTTP binding, split into subsections, added double curly brace escape mechanism, removed pseudo-schema. |
| 20030521 | JCS | Added rules for @verbDefault/@verb and @location. |
| 20030514 | JJM | Start converting the HTTP binding to the component model. The next thing to do will be to remove http:urlReplacement, etc. and incorporate instead Philippe's text. |
| 20030313 | MJG | Changed to Part 3 ( from Part 2 ) |
| 20030117 | JCS | Incorporated resolution for Issue 5 (@encodingStyle). Referenced (rather than in-lined XML Schema). |
| 20030117 | JJM | Various editorial fixes. |
| 20030116 | JCS | Updated pseudo and XML Schema. |
| 20030116 | JJM | Added propertyConstraint section. |
| 20030116 | JJM | Added soap:module section. |
| 20030115 | JCS | Incorporated resolutions for Issue 25 (drop @use and @encoding), Issue 51 (headers reference element/type), and attribute roll up into text and schema. Began reworking SOAP HTTP binding to use Infoset model. Removed informative appendices 'Notes on URIs' and example WSDL documents; expect them to appear in the primer. Updated SOAP 1.2 references to CR. |
| 20030114 | JJM | Removed ednote saying Part 2 is out of synch with Part 1. |
| 20030111 | JJM | Incorporated resolution for issue 17 (role AII). |
| 20030109 | JJM | Incorporated resolution for issue 4 (Namespaces). |
| 20020702 | JJM | Added summary to prefix table. |
| 20020628 | JJM | Added out-of-synch-with-Part2 and not-soap12-yet ednote. |
| 20020621 | JJM | Commented out the link to the previous version. There is no previous version for 1.2 right now. |
| 20020621 | JJM | Rewrote the Notation Conventions section. |
| 20020621 | JJM | Added reference to part 0 in introduction. Renumbered references. |
| 20020621 | JJM | Simplified abstract and introduction. |
| 20020621 | JJM | Obtain the list of WG members from a separate file. |
| 20020621 | JJM | Updated stylesheet and DTDs to latest XMLP stylesheet and DTDs. |
| 20020621 | JJM | Deleted placeholder for appendix C "Location of Extensibility Elements", since this is part 1 stuff and extensibility has been reworked anyway. |
| 20020621 | JJM | Corrected link to issues lists |
| 20020621 | JJM | Updated title from "WSDL" to "Web Services Description Language". Now refer to part 1 as "Web Services... Part 1: Framework |
| 20020621 | JJM | Added Jeffrey as an editor :-). Removed Gudge (now on Part 2) :-( |
| 20020411 | JJM | Fixed typos noticed by Kevin Liu |
| 20020301 | JJM | Converted the "Schemas" sections |
| 20020301 | JJM | Converted the "Wire WSDL examples" sections |
| 20020301 | JJM | Converted the "Notes on URIs" sections |
| 20020301 | JJM | Converted the "Notational Conventions" sections |
| 20020301 | JJM | Converted the "References" sections |
| 20020301 | JJM | Converted the "MIME Binding" section to XML |
| 20020221 | JJM | Converted the "HTTP Binding" section to XML |
| 20020221 | JJM | Added placeholders for the "Wire examples" and "Schema" sections |
| 20020221 | JJM | Converted the "SOAP Binding" section to XML |
| 20020221 | JJM | Added the Change Log |
| 20020221 | JJM | Added the Status section |
| 20020221 | JJM | Simplified the introduction; referred to Part1 for a longer introduction |
| 20020221 | JJM | Renamed to "Part 2: Bindings" |
| 20020221 | JJM | Created from http://www.w3.org/TR/2001/NOTE-wsdl-20010315 |