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 an updated version of the
This version addresses the modest number of comments received to
date on the Candidate Recommendation of Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts, and primarily differs from
the previous version in the inclusion of marked test assertions
to help implementers, as well as the loosening of the IRI style
to allow repetition of query parameters and the removal of the
{http version} property which was judged unneeded. The detailed
disposition of the comments received can be found in the
The Working Group plans to submit
this specification for consideration as a
Two interoperable implementations of all the features, both mandatory and optional, of the specifications have been produced.
The Working Group releases a test suite along with an
The following features defined in this specification are considered
Serialization of the instance data in parts of the HTTP request IRI
(section
Definition of the Robust In-Only, In-Optional-Out, Out-Only,
Robust Out-Only, Out-In, Out-Optional-In message exchange
pattern (in section
Implementers are invited to
Issues about this document are recorded in the
Publication as a Candidate Recommendation 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 was produced by a group operating under the
Last Modified: $Date: 2006/03/27 17:06:18 $ CET
The Web Services Description Language WSDL Version 2.0 (WSDL)
Message exchange patterns:
Operation safety declaration:
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 |
|
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 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;
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.
Binding extensions, features, or extension specifications may override the semantics of a fault propagation ruleset, but this practice is strongly discouraged.
This fault propagation rule is identified by the following URI: http://www.w3.org/2006/01/wsdl/fault-replaces-message
This fault propagation rule is identified by the following URI: http://www.w3.org/2006/01/wsdl/message-triggers-fault
This fault propagation rule is identified by the following URI: http://www.w3.org/2006/01/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
A message:
indicated by a
received from some node N
An optional message:
indicated by a
sent to node N
An operation using this message exchange pattern has
a
A message:
indicated by a
sent to some node N
An operation using this message exchange pattern has
a
message:
indicated by a
sent to some node N
An operation using this message exchange pattern has
a
A message:
indicated by a
sent to some node N
A message:
indicated by a
sent from node N
An operation using this message exchange pattern has
a
A message:
indicated by a
sent to some node N
An optional message:
indicated by a
sent from 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 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 denial-of-service attacks may be enabled or exacerbated.
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
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 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
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/2006/01/wsdl/rpc"
The type of the
A
| Property | Value |
|---|---|
| A list of |
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.
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 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.
1.
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
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
This SOAP binding extension only allows one single element in 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 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 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
The following
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
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 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/2006/01/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/2006/01/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 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
When the SOAP Message Exchange Pattern is the SOAP 1.2 Response
MEP and the underlying protocol is HTTP, the
These binding rules are applicable to SOAP 1.2 bindings.
application/x-www-form-urlencoded is the only supported
serialization format for HTTP GET in the SOAP Response
Message Exchange Pattern.
This section describes the relationship between WSDL components and SOAP
1.2 MEP properties as described in
When using the WSDL
As the client, the property
The SOAP
The WSDL
The WSDL
As the service, the property
The WSDL
The WSDL
When using the WSDL
As the client, the property
The SOAP
The SOAP
The WSDL
As the service, the property
The WSDL
The WSDL
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
A
For a given
Otherwise, the value of the
Otherwise, if a
Otherwise, it is an ERROR.
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 of such mechanisms 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
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.
For every
The HTTP binding extension adds the following properties
to the WSDL component model (as defined in
If the resulting IRI uses the https
scheme, then HTTP over TLS
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 allow to indicate the range of media types and/or
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
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,
A
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/2006/01/wsdl/http,
whttp.header(
parent
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
The XML representation for binding an HTTP Fault are two
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 an
Other serialization formats may be defined. Those MAY place restrictions on the style of the Interface Operation bound.
| - | 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
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. If a local name appears more
than once, the elements are used in the order they
appear in the
A double curly brace (i.e.
This serialization format is designed to allow a client or
Web service to produce an IRI based on the application/x-www-form-urlencoded.
It may only be used when binding
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.
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 WSDL component model:
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, or a media type compatible with
application/xml as specified in section Content-Encoding or
Transfer-Encoding, MAY be used.
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
property 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 transfer coding
is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
The XML representation for specifying the default
transfer coding 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
|
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): Rebecca Bergersen (IONA Technologies), 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.), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), Gilbert Pilz (BEA Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ü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 declaration | SOAP Header Block. |
| http authentication realm | Endpoint. |
| http authentication scheme | Endpoint. |
| http cookies | Binding. |
| http error status code | Binding Fault. |
| http fault serialization | Binding Operation. |
| http headers | Binding Fault. |
| 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 transfer coding | Binding Fault. |
| mustUnderstand | SOAP Header Block. |
| name | HTTP Header. |
| parent | HTTP Header. |
| ref | SOAP Module. |
| required | HTTP Header. |
| rpc signature | Interface Operation. |
| safety | 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 modules | Binding. |
| soap version | Binding. |
| type definition | HTTP Header. |
| Date | Author | Description |
|---|---|---|
| 20060309 | HH | |
| 20060309 | HH | |
| 20060309 | HH | |
| 20060227 | HH | |
| 20060209 | HH | Added test assertions to HTTP binding. |
| 20060110 | AGR |
Applied patch,
|
| 20051122 | HH | |
| 20051117 | JJM | |
| 20051113 | HH | |
| 20051111 | HH | Added SOAP MEP / WSDL MEP mapping as per
|
| 20051111 | HH | |
| 20051111 | HH | |
| 20051111 | HH | |
| 20051111 | HH | |
| 20051111 | AGR | Added assertion tables. Added Fault Propagation Rule assertions. |
| 20051110 | HH | |
| 20051110 | HH | |
| 20051109 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051027 | HH | |
| 20051020 | HH | |
| 20051020 | HH | |
| 20051020 | HH | |
| 20051013 | HH | |
| 20051013 | HH | Fixed mark-up for declaring {soap modules}, {soap headers} and {http headers} |
| 20051013 | HH | |
| 20051013 | HH | |
| 20051012 | RRC | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050923 | HH | |
| 20050902 | RRC | |
| 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 superseded 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 |
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
|
|
|
a |
|
|
The serialization rules for messages whose |
|
|
When formulating the HTTP message to be transmitted, the HTTP request method used MUST be the following: |
|
|
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 |
|
|
An integer value
of this property identifies the error Status-Code as defined by |
|
|
The first is transmitted using an HTTP request, and the second is transmitted using the corresponding HTTP response. |
|
|
This
IRI is combined with the base IRI specified in the
|
|
|
The value of the |
|
|
In cases where only one message is being sent, the message body of the HTTP response MUST be empty. |
|
|
It MUST contain an absolute or a relative IRI, i.e. it MUST NOT include a fragment identifier in the IRI. |
|
|
If the
|
|
|
If the value of an |
|
|
If an HTTP
header field corresponding to the value of the |
|
|
It is an ERROR for a |
|
|
This type MUST be a simple type. |
|
|
If the value is |
|
|
It is an error for the |
|
|
If 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. |
|
|
this serialization format may only be used to serialize the HTTP request corresponding to the initial message of an interface operation. |
|
|
The value of the Accept HTTP header defined by the HTTP
1.1 specification, Section 14.1 (see |
|
|
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 |
|
|
Strings enclosed within single
curly braces MUST be element names from the |
|
|
The Content-Type HTTP header MUST have the value
application/xml, or a media type compatible with
application/xml as specified in section |
|
|
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: |
|
|
It is an error for the |
|
|
When using this style, the value of the |
|
|
The sequence MUST only contain elements. |
|
|
The sequence MUST contain only local element
children. These child elements MAY contain the
|
|
|
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. |
|
|
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. |
|
|
This pattern consists of exactly one message as follows: |
|
|
This pattern consists of one or two messages, in order, as follows: |
|
|
This pattern consists of exactly two messages, in order, as follows: |
|
|
When using this style, the value of the |
|
|
The sequence MUST only contain elements. |
|
|
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 sequence MUST contain only local element
children. These child elements MAY contain the
1. |
|
|
However, an operation SHOULD be marked safe
if it meets the criteria for a safe interaction defined in
Section 3.5 of |
|
|
This pattern consists of exactly two messages, in order, as follows: |
|
|
This pattern consists of exactly one message as follows: |
|
|
This pattern consists of one or two messages, in order, as follows: |
|
|
The RPC style MUST NOT be used for |
|
|
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. |
|
|
The sequence 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. |
|
|
This pattern consists of exactly one message as follows: |
|
|
This pattern consists of exactly one message as follows: |
|
|
A |
|
|
When formulating
the SOAP envelope to be transmitted, the contents of the
payload (i.e., the contents of the SOAP Body |
|
|
If the value is |
|
|
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 |
|
|
If
the SOAP MEP selected is
|
|
|
This default
binding rule is applicable when the value of the
|
|
|
When its value is
|
|
|
If the value is |
|
|
It is
an error for the |
|
|
A |
|
|
A |
|
|
For a given |
|
|
A |
|
|
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 |