W3C
Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts
W3C Working Draft 26 March 2007
This version:
http://www.w3.org/TR/2007/WD-wsdl20-adjuncts-20070326
Latest version:
http://www.w3.org/TR/wsdl20-adjuncts
Previous version:
http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060327
Editors:
Roberto Chinnici, Sun Microsystems
Hugo Haas, W3C
Amelia A. Lewis, TIBCO Software
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Sanjiva Weerawarana, WSO2
This document is also available in these non-normative formats: PDF, PostScript
, XML, and plain text.
Copyright © 2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability,
trademark and document use rules apply.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Abstract
WSDL 2.0 is the Web Services Description Language, an XML language for
describing Web services. This document, "Web Services Description Language
(WSDL) Version 2.0 Part 2: Adjuncts", specifies predefined extensions for use
in WSDL 2.0:
• Message exchange patterns
• Operation safety
• Operation styles
• Binding extensions for SOAP and HTTP
Status of this Document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current W3C
publications and the latest revision of this technical report can be found in
the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Last Call Working of Web Services Description Language (WSDL)
Version 2.0 Part 2: Adjuncts for review by W3C Members and other interested
parties. It has been produced by the Web Services Description Working Group,
which is part of the W3C Web Services Activity. This document is published to
give an opportunity to the community to review the new namespace for WSDL 2.0.
The Working Group plans to request to move to W3C Proposed Recommendation
shortly after the end of the Last Call period.
As a result of implementer and community feedback the Working Group made a
number of changes since the Candidate Recommendation publication. These changes
include:
• The namespace of the language specified in the document, and identifiers
within it, have changed to a shorter, undated form.
• Numerous consistency and editorial improvements.
• Improved the granularity and orthogonality of test assertions within the
document, and between the assertions and the normative schema, by variously
adding, removing and factoring assertion markup.
• Factored MEPs not supported by the SOAP or HTTP bindings to a separate
specification.
• Renamed the boolean-valued {safety} property to {safe}.
• Added {http query parameter separator}, {http query parameter separator
default}, and {http location ignore uncited} properties to the SOAP
binding.
• Specified mapping of in-only and robust-in-only MEPs to the SOAP 1.2
request-response MEP as clarified in the PER.
• Clarified when properties from the HTTP binding appear, and have meaning,
in the SOAP Binding.
• Allowed #none as an input content model when using the SOAP Response MEP.
• Added an explicit dependency from the HTTP Binding to the wsdlx:safe
annotation.
• The HTTP method defaults to POST if is is not set explicitly, or by the
wsdlx:safe annotation.
• Clarified the relationship of {http location} and {address} as a relative
URI and a base URI.
• Renamed whttp:authenticationType to whttp:authenticationScheme.
• Added explicit rules about encoding data when populating an HTTP location
template.
• Added syntax for suppressing any encoding when populating an HTTP location
template.
• Added BNF to clarify parsing rules for HTTP location templates.
• Replaced {http transfer coding} with {http content encoding} and described
its effects more precisely.
• Constrained the values allowed in {http query parameter separator} and
{http query parameter separator default} properties.
Individuals are invited to send feedback on this document to the public
public-ws-desc-comments@w3.org mailing list (public archive) through 15 April
2007.
The Working Group releases a test suite along with an implementation report.
Issues about this document are recorded in the issues list maintained by the
Working Group. A diff-marked version against the previous version of this
document is available.
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 is governed by the 24 January 2002 CPP as amended by the W3C
Patent Policy Transition Procedure. W3C maintains a public list of any patent
disclosures made in connection with the deliverables of the group; that page
also includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains Essential
Claim(s) must disclose the information in accordance with section 6 of the W3C
Patent Policy.
Table of Contents
1. Introduction
1.1 Notational Conventions
1.2 Assertions
2. Predefined Message Exchange Patterns
2.1 Template for Message Exchange Patterns
2.1.1 Pattern Name
2.2 Fault Propagation Rules
2.2.1 Fault Replaces Message propagation rule
2.2.2 Message Triggers Fault propagation rule
2.2.3 No Faults propagation rule
2.3 Message Exchange Patterns
2.3.1 In-Only message exchange pattern
2.3.2 Robust In-Only message exchange pattern
2.3.3 In-Out message exchange pattern
2.4 Security Considerations
3. Predefined Extensions
3.1 Operation safety
3.1.1 Relationship to WSDL Component Model
3.1.2 XML Representation
3.1.3 Mapping from XML Representation to Component Properties
4. Predefined Operation Styles
4.1 RPC Style
4.1.1 wrpc:signature Extension
4.1.2 XML Representation of the wrpc:signature Extension
4.1.3 wrpc:signature Extension Mapping To Properties of an Interface
Operation component
4.2 IRI Style
4.3 Multipart style
5. WSDL SOAP Binding Extension
5.1 SOAP Syntax Summary (Non-Normative)
5.2 Identifying the use of the SOAP Binding
5.3 SOAP Binding Rules
5.4 Specifying the SOAP Version
5.4.1 Description
5.4.2 Relationship to WSDL Component Model
5.4.3 XML Representation
5.4.4 Mapping from XML Representation to Component properties
5.5 Specifying the SOAP Underlying Protocol
5.5.1 Description
5.5.2 Relationship to WSDL Component Model
5.5.3 XML Representation
5.5.4 Mapping from XML Representation to Component Properties
5.6 Binding Faults
5.6.1 Description
5.6.2 Relationship to WSDL Component Model
5.6.3 XML Representation
5.6.4 Mapping XML Representation to Component Properties
5.7 Binding Operations
5.7.1 Description
5.7.2 Relationship to WSDL Component Model
5.7.3 XML Representation
5.7.4 Mapping from XML Representation to Component Properties
5.8 Declaring SOAP Modules
5.8.1 Description
5.8.2 Relationship to WSDL Component Model
5.8.3 SOAP Module component
5.8.4 XML Representation
5.8.5 Mapping from XML Representation to Component Properties
5.8.6 IRI Identification Of A SOAP Module component
5.9 Declaring SOAP Header Blocks
5.9.1 Description
5.9.2 Relationship to WSDL Component Model
5.9.3 SOAP Header Block component
5.9.4 XML Representation
5.9.5 Mapping XML Representation to Component Properties
5.9.6 IRI Identification Of A SOAP Header Block component
5.10 WSDL SOAP 1.2 Binding
5.10.1 Identifying a WSDL SOAP 1.2 Binding
5.10.2 Description
5.10.3 SOAP 1.2 Binding Rules
5.10.4 Binding WSDL 2.0 MEPs to SOAP 1.2 MEPs
5.10.4.1 WSDL In-Out to SOAP Request-Response
5.10.4.1.1 The Client
5.10.4.1.2 The Service
5.10.4.2 WSDL In-Out to SOAP SOAP-Response
5.10.4.2.1 The Client
5.10.4.2.2 The Service
5.10.4.3 WSDL In-Only to SOAP Request-Response
5.10.4.3.1 The Client
5.10.4.3.2 The Service
5.10.4.4 WSDL Robust-In-Only to SOAP Request-Response
5.10.4.4.1 The Client
5.10.4.4.2 The Service
5.11 Conformance
6. WSDL HTTP Binding Extension
6.1 Identifying the use of the HTTP Binding
6.2 HTTP Syntax Summary (Non-Normative)
6.3 Supported Extensions
6.4 HTTP Binding Rules
6.4.1 HTTP Method Selection
6.4.2 HTTP Content Encoding Selection
6.4.3 Payload Construction And Serialization Format
6.4.3.1 Serialization rules for XML messages
6.4.4 Default input and output serialization format
6.4.5 HTTP Header Construction
6.4.6 HTTP Request IRI
6.5 Binding Operations
6.5.1 Description
6.5.2 Relationship to WSDL Component Model
6.5.3 Specification of serialization rules allowed
6.5.4 XML Representation
6.5.5 Mapping from XML Representation to Component Properties
6.6 Declaring HTTP Headers
6.6.1 Description
6.6.2 Relationship to WSDL Component Model
6.6.3 HTTP Header component
6.6.4 XML Representation
6.6.5 Mapping from XML Representation to Component Properties
6.6.6 IRI Identification Of An HTTP Header component
6.7 Specifying HTTP Error Code for Faults
6.7.1 Description
6.7.2 Relationship to WSDL Component Model
6.7.3 XML Representation
6.7.4 Mapping from XML Representation to Component Properties
6.8 Serialization Format of Instance Data
6.8.1 Serialization of the instance data in parts of the HTTP request
IRI
6.8.1.1 Construction of the request IRI using the {http location}
property
6.8.2 Serialization as application/x-www-form-urlencoded
6.8.2.1 Case of elements cited in the {http location} property
6.8.2.2 Serialization of content of the instance data not cited in
the {http location} property
6.8.2.2.1 Construction of the query string
6.8.2.2.2 Controlling the serialization of the query string in
the request IRI
6.8.2.2.3 Serialization in the request IRI
6.8.2.2.4 Serialization in the message body
6.8.3 Serialization as application/xml
6.8.4 Serialization as multipart/form-data
6.9 Specifying the Content Encoding
6.9.1 Description
6.9.2 Relationship to WSDL Component Model
6.9.3 XML Representation
6.9.4 Mapping from XML Representation to Component Properties
6.10 Specifying the Use of HTTP Cookies
6.10.1 Description
6.10.2 Relationship to WSDL Component Model
6.10.3 XML Representation
6.10.4 Mapping from XML Representation to Component Properties
6.11 Specifying HTTP Access Authentication
6.11.1 Description
6.11.2 Relationship to WSDL Component Model
6.11.3 XML Representation
6.11.4 Mapping from XML Representation to Component Properties
6.12 Conformance
7. References
7.1 Normative References
7.2 Informative References
Appendices
A. Acknowledgements (Non-Normative)
B. Component Summary (Non-Normative)
C. Assertion Summary (Non-Normative)
D. Part 2 Change Log (Non-Normative)
D.1 WSDL 2.0 Extensions Change Log
D.2 WSDL 2.0 Bindings Change Log
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Introduction
The Web Services Description Language Version 2.0 (WSDL 2.0) [WSDL 2.0 Core
Language] provides a model and an XML format for describing Web services. WSDL
2.0 enables one to separate the description of the abstract functionality
offered by a service from concrete details of a service description such as
"how" and "where" that functionality is offered.
This document, "Web Services Description Language (WSDL) Version 2.0 Part 2:
Adjuncts", specifies predefined extensions for use in WSDL 2.0:
• Message exchange patterns: 2. Predefined Message Exchange Patterns
• Operation safety declaration: 3. Predefined Extensions
• Operation styles: 4. Predefined Operation Styles
• Binding extensions:
□ A SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)]
binding extension: 5. WSDL SOAP Binding Extension
□ An HTTP/1.1 [IETF RFC 2616] binding extension: 6. WSDL HTTP Binding
Extension
This document depends on WSDL Version 2.0 [WSDL 2.0 Core Language].
1.1 Notational Conventions
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 [IETF RFC 2119].
This specification uses a number of namespace prefixes throughout; they are
listed in Table 1-1. Note that the choice of any namespace prefix is arbitrary
and not semantically significant (see [XML Information Set]).
Table 1-1. Prefixes and Namespaces used in this specification
┌──────┬────────────────┬─────────────────────────────────────────────────────┐
│Prefix│ Namespace │ Notes │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │ │This namespace is defined in [WSDL 2.0 Core Language │
│ │"http:// │]. A normative XML Schema [XML Schema Structures], [ │
│wsdl │www.w3.org/ns/ │XML Schema Datatypes] document for the "http:// │
│ │wsdl" │www.w3.org/ns/wsdl" namespace can be found at http://│
│ │ │www.w3.org/ns/wsdl. This namespace is used as the │
│ │ │default namespace throughout this specification. │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │ │This specification extends in section 3. Predefined │
│ │ │Extensions the "http://www.w3.org/ns/wsdl-extensions"│
│ │"http:// │namespace defined in [WSDL 2.0 Core Language]. A │
│wsdlx │www.w3.org/ns/ │normative XML Schema [XML Schema Structures], [XML │
│ │wsdl-extensions"│Schema Datatypes] document for the "http://www.w3.org│
│ │ │/ns/wsdl-extensions" namespace can be found at http:/│
│ │ │/www.w3.org/ns/wsdl-extensions. │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │ │Defined by this specification. A normative XML Schema│
│ │"http:// │[XML Schema Structures], [XML Schema Datatypes] │
│wsoap │www.w3.org/ns/ │document for the "http://www.w3.org/ns/wsdl/soap" │
│ │wsdl/soap" │namespace can be found at http://www.w3.org/ns/wsdl/ │
│ │ │soap. │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │ │Defined by this specification. A normative XML Schema│
│ │"http:// │[XML Schema Structures], [XML Schema Datatypes] │
│whttp │www.w3.org/ns/ │document for the "http://www.w3.org/ns/wsdl/http" │
│ │wsdl/http" │namespace can be found at http://www.w3.org/ns/wsdl/ │
│ │ │http. │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │ │Defined by this specification. A normative XML Schema│
│ │"http:// │[XML Schema Structures], [XML Schema Datatypes] │
│wrpc │www.w3.org/ns/ │document for the "http://www.w3.org/ns/wsdl/rpc" │
│ │wsdl/rpc" │namespace can be found at http://www.w3.org/ns/wsdl/ │
│ │ │rpc. │
├──────┼────────────────┼─────────────────────────────────────────────────────┤
│ │"http:// │Defined in the W3C XML Schema specification [XML │
│xs │www.w3.org/2001/│Schema Structures], [XML Schema Datatypes]. │
│ │XMLSchema" │ │
└──────┴────────────────┴─────────────────────────────────────────────────────┘
Namespace names of the general form "http://example.org/..." and "http://
example.com/..." represent application or context-dependent URIs [IETF RFC 3986
].
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 [XML 1.0] serialization. The
syntax of BNF pseudo-schemas is the same as the one used in [WSDL 2.0 Core
Language].
1.2 Assertions
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 C. Assertion
Summary.
2. Predefined Message Exchange Patterns
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 node is an agent (section 2.3.2.2 Agent of the Web Services Architecture [Web
Services Architecture]) that can transmit and/or receive message(s) described
in WSDL description(s) and process them.
Note:
A node MAY be accessible via more than one physical address or transport.^†
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
5.10.3 SOAP 1.2 Binding Rules contains the binding rules for the selection of a
SOAP 1.2 message exchange pattern, based on the WSDL message exchange pattern
in use for the SOAP binding extension defined in section 5. WSDL SOAP Binding
Extension).
By design, WSDL message exchange patterns abstract out specific message types.
Patterns identify placeholders for messages, and placeholders are associated
with specific message types by the operation using the pattern.
Unless explicitly stated otherwise, WSDL message exchange patterns also
abstract out binding-specific information such as timing between messages,
whether the pattern is synchronous or asynchronous, and whether the messages
are sent over a single or multiple channels.
Like interfaces and operations, WSDL message exchange patterns do not
exhaustively describe the set of messages exchanged between a service and other
nodes; by some prior agreement, another node and/or the service MAY send
messages (to each other or to other nodes) that are not described by the
pattern.^† For instance, even though a pattern can define a single message sent
from a service to one other node, the Web service can in practice 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 WSDL
Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language]. Additional,
non-normative patterns are available in [WSDL 2.0 Additional MEPs].
2.1 Template for Message Exchange Patterns
New message exchange patterns may be defined by any organization able and
willing to do so. It is recommended that the patterns use the general template
provided in 2.1.1 Pattern Name, after examination of existing predefined
patterns.
2.1.1 Pattern Name
This pattern consists of [number] message[s, in order] as follows:
[enumeration, specifying, for each message] A[n optional] message:
1. indicated by an Interface Message Reference component whose {message label}
is "[label]" and {direction} is "[direction]"
2. [received from|sent to] ['some' if first mention] node [node identifier]
This pattern uses the rule [fault ruleset reference].
An Interface Operation using this message exchange pattern has a {message
exchange pattern} property with the value "[pattern IRI]".
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.
2.2 Fault Propagation Rules
WSDL patterns specify their fault propagation model using standard rulesets to
indicate where faults can occur. The most common patterns for fault propagation
are defined in the following subsections, and referenced by the patterns in 2.3
Message Exchange Patterns. "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 that
generate faults MUST attempt to propagate the faults in accordance with the
governing ruleset, but it is understood that any delivery of a network message
is best effort, not guaranteed.^† 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 [WSA 1.0 Core] defines
a "FaultTo" address for messages, which is used in lieu of the recipient
nominated by the ruleset.
Generation of a fault, regardless of ruleset, terminates the exchange.^†
Binding extensions, features, or extension specifications can override the
semantics of a fault propagation ruleset, but this practice is strongly
discouraged.
2.2.1 Fault Replaces Message propagation rule
When the Fault Replaces Message propagation rule is in effect, any message
after the first in the pattern MAY be replaced with a fault message, which MUST
have identical direction. ^† The fault message MUST be delivered to the same
target node as the message it replaces, unless otherwise specified by an
extension or binding extension. If there is no path to this node, the fault
MUST be discarded.^†
The Fault Replaces Message propagation rule is identified by the following URI:
http://www.w3.org/ns/wsdl/fault-replaces-message
2.2.2 Message Triggers Fault propagation rule
When the Message Triggers Fault propagation rule is in effect, any message,
including the first in the pattern, MAY trigger a fault message, which MUST
have opposite direction. ^† The fault message MUST be delivered to the
originator of the triggering message, unless otherwise specified by an
extension or binding extension. Any node MAY propagate a fault message, and
MUST NOT do so more than once for each triggering message. If there is no path
to the originator, the fault MUST be discarded.^†
The Message Triggers Fault propagation rule is identified by the following URI:
http://www.w3.org/ns/wsdl/message-triggers-fault
2.2.3 No Faults propagation rule
When the No Faults propagation rule is in effect, faults MUST NOT be
propagated. ^†
The No Faults propagation rule is identified by the following URI: http://
www.w3.org/ns/wsdl/no-faults
2.3 Message Exchange Patterns
WSDL patterns are described in terms of the WSDL component model, specifically
the Interface Message Reference and Interface Fault Reference components.
2.3.1 In-Only message exchange pattern
The in-only message exchange pattern consists of exactly one message as
follows:^†
1. A message:
□ indicated by a Interface Message Reference component whose {message
label} is "In" and {direction} is "in"
□ received from some node N
The in-only message exchange pattern uses the rule 2.2.3 No Faults propagation
rule.^†
An operation using this message exchange pattern has a {message exchange
pattern} property with the value "http://www.w3.org/ns/wsdl/in-only".
2.3.2 Robust In-Only message exchange pattern
The robust-in-only message exchange pattern consists of exactly one message as
follows:^†
1. A message:
□ indicated by a Interface Message Reference component whose {message
label} is "In" and {direction} is "in"
□ received from some node N
The robust in-only message exchange pattern uses the rule 2.2.2 Message
Triggers Fault propagation rule.^†
An operation using this message exchange pattern has a {message exchange
pattern} property with the value "http://www.w3.org/ns/wsdl/robust-in-only".
2.3.3 In-Out message exchange pattern
The in-out message exchange pattern consists of exactly two messages, in order,
as follows:^†
1. A message:
□ indicated by a Interface Message Reference component whose {message
label} is "In" and {direction} is "in"
□ received from some node N
2. A message:
□ indicated by a Interface Message Reference component whose {message
label} is "Out" and {direction} is "out"
□ sent to node N
The in-out message exchange pattern uses the rule 2.2.1 Fault Replaces Message
propagation rule.^†
An operation using this message exchange pattern has a {message exchange
pattern} property with the value "http://www.w3.org/ns/wsdl/in-out".
2.4 Security Considerations
Note that many of the message exchange patterns defined above describe
responses to an initial message (either a normal response message or a fault.)
Such responses can be used in attempts to disrupt, attack, or map a network,
host, or services. When such responses are directed to an address other than
that originating the initial message, the source of an attack can be obscured,
or blame laid on a third party, or denial-of-service attacks can be enabled or
exacerbated.
Security mechanisms addressing such attacks can prevent the delivery of
response messages to the receiving node. Conformance to the message exchange
pattern is measured prior to the application of these security mechanisms.
3. Predefined Extensions
3.1 Operation safety
This section defines an extension to WSDL 2.0 [WSDL 2.0 Core Language] that
allows marking an operation as a safe interaction, as defined in section 3.4.
Safe Interactions of [Web Architecture].
This extension MAY be used for setting defaults in bindings, such as in the
HTTP binding (see 6.5.5 Mapping from XML Representation to Component Properties
).
3.1.1 Relationship to WSDL Component Model
The safety extension adds the following property to the Interface Operation
component model (defined in [WSDL 2.0 Core Language]):
• {safe} REQUIRED. An xs:boolean indicating whether the operation is asserted
to be safe for users to invoke. If this property is "false", then no
assertion has been made about the safety of the operation, thus the
operation MAY or MAY NOT be safe. However, an operation SHOULD be marked
safe if it meets the criteria for a safe interaction defined in Section 3.4
of [Web Architecture].^†
3.1.2 XML Representation
The XML representation for the safety extension is an attribute information
item with the following Infoset properties:
• An OPTIONAL safe attribute information item with the following Infoset
properties:^†
□ A [local name] of safe
□ A [namespace name] of "http://www.w3.org/ns/wsdl-extensions"
□ A type of xs:boolean
3.1.3 Mapping from XML Representation to Component Properties
See Table 3-1.
Table 3-1. Mapping from XML Representation to Interface Operation component
Extension Properties
┌────────┬────────────────────────────────────────────────────────────────────┐
│Property│ Value │
├────────┼────────────────────────────────────────────────────────────────────┤
│{safe} │The actual value of the safe attribute information item, if present;│
│ │otherwise the value "false". │
└────────┴────────────────────────────────────────────────────────────────────┘
4. Predefined Operation Styles
This section defines operation styles that can be used to place constraints on
Interface Operation components, in particular with respect to the format of the
messages they refer to. The serialization formats defined in section 6.8
Serialization Format of Instance Data require bound Interface Operation
components to have one or more of the styles defined in this section.
4.1 RPC Style
The RPC style is selected by including the value "http://www.w3.org/ns/wsdl/
style/rpc" in the {style} property of an Interface Operation component.
An Interface Operation component conforming to the RPC style MUST obey the
constraints listed further below. Furthermore, if the wrpc:signature extension
is engaged simulatenously, the corresponding attribute information item MUST be
valid according to the schema for the extension and additionally MUST obey the
constraints listed in 4.1.1 wrpc:signature Extension and 4.1.2 XML
Representation of the wrpc:signature Extension.
If the RPC style is used by an Interface Operation component then its {message
exchange pattern} property MUST have the value either "http://www.w3.org/ns/
wsdl/in-only" or "http://www.w3.org/ns/wsdl/in-out".^†
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 [XML Schema Structures]. Note that
operations containing messages described by other type systems may also
indicate use of the RPC style, as long as they are constructed in such a way as
to follow these rules.
If the Interface Operation component uses a {message exchange pattern} for
which there is no output element, i.e. "http://www.w3.org/ns/wsdl/in-only",
then the conditions stated below that refer to output elements MUST be
considered to be implicitly satisfied.
• The value of the {message content model} property for the Interface Message
Reference components of the {interface message references} property MUST be
"#element".^†
• The content model of input and output {element declaration} elements MUST
be defined using a complex type that contains a sequence from XML Schema.^†
• 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.
• Both the input and output sequences 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 Interface
Operation component's name.^†
• 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 4.1.1 wrpc:signature Extension).
• 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.^†
4.1.1 wrpc:signature Extension
The wrpc:signature extension attribute information item MAY be used in
conjunction with the RPC style to describe the exact signature of the function
represented by an operation that uses the RPC style.
When present, the wrpc:signature extension contributes the following property
to the Interface Operation component it is applied to:
• {rpc signature} OPTIONAL, but MUST be present when the style is RPC^†. A
list of pairs (q, t) whose first component is of type xs:QName and whose
second component is of type xs:token. Values for the second component MUST
be chosen among the following four: "#in", "#out", "#inout" "#return".^†
The value of the {rpc signature} property MUST satisfy the following
conditions:
• The value of the first component of each pair (q, t) MUST be unique within
the list.^†
• For each child element of the input and output messages of the operation, a
pair (q, t), whose first component q is equal to the qualified name of that
element, MUST be present in the list, with the caveat that elements that
appear with cardinality greater than one MUST be treated as a single
element.^†
• For each pair (q, #in), there MUST be a child element of the input element
with a name of q. There MUST NOT be a child element of the output element
with the name of q.^†
• For each pair (q, #out), there MUST be a child element of the output
element with a name of q. There MUST NOT be a child element of the input
element with the name of q.^†
• For each pair (q, #inout), there MUST be a child element of the input
element with a name of q. There MUST also be a child element of the output
element with the name of q.^†
• For each pair (q, #return), there MUST be a child element of the output
element with a name of q. There MUST NOT be a child element of the input
element with the name of q.^†
The function signature defined by a wrpc:signature extension is determined as
follows:
1. Start with the value of the {rpc signature} property, a (possibly empty)
list of pairs of this form:
[(q0, t0), (q1, t1), ...]
2. Filter the elements of this list into two lists, the first one (L1)
comprising pairs whose t component is one of {#in, #out, #inout}, the
second (L2) pairs whose t component is #return. During the composition of
L1 and L2, the relative order of members in the original list MUST be
preserved.
For ease of visualization, let's denote the two lists as:
(L1) [(a0, u0), (a1, u1), ...]
and
(L2) [(r0, #return), (r1, #return), ...]
respectively.
3. Then, if the input sequence ends with an element wildcard, the formal
signature of the function is:
f([d0] a0, [d1] a1, ..., rest) => (r0, r1, ...)
where rest is a formal parameter representing the elements in the input
message matched by the element wildcard.
Otherwise the formal signature of the function is:
f([d0] a0, [d1] a1, ...) => (r0, r1, ...)
i.e.:
□ the list of formal arguments to the function is [a0, a1, ...];
□ the direction d of each formal argument a is one of [in], [out],
[inout], determined according to the value of its corresponding u
token;
□ the list of formal return parameters of the function is [r0, r1, ...];
□ 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).
Note:
The wrpc:signature extension allows the specification of multiple return values
for an operation. Several popular programming languages support multiple return
values for a function. Moreover, for languages which do not, the burden on
implementers should be small, as typically multiple return values will be
mapped to a single return value of a structure type (or its closest
language-specific equivalent).
4.1.2 XML Representation of the wrpc:signature Extension
The XML representation for the RPC signature extension is an attribute
information item with the following Infoset properties:
• A [local name] of signature
• A [namespace name] of "http://www.w3.org/ns/wsdl/rpc"
The type of the name attribute information item is a list type whose item type
is the union of the xs:QName type and the subtype of the xs:token type
restricted to the following four values: "#in", "#out", "#inout", "#return".
See Example 4-1 for an excerpt from the normative schema definition of this
type.
Additionally, each even-numbered item (0, 2, 4, ...) in the list MUST be of
type xs:QName and each odd-numbered item (1, 3, 5, ...) in the list MUST be of
the subtype of xs:token described in the previous paragraph.^†
Example 4-1. Definition of the wrpc:signature extension
4.1.3 wrpc:signature Extension Mapping To Properties of an Interface Operation
component
A wrpc:signature extension attribute information item is mapped to the
following property of the Interface Operation component defined by its [owner].
Table 4-1. Mapping of a wrpc:signature Extension to Interface Operation
component Properties
┌──────────┬──────────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────┼──────────────────────────────────────────────────────────────────┤
│{rpc │A list of (xs:QName, xs:token) pairs formed by grouping the items │
│signature}│present in the actual value of the wrpc:signature attribute │
│ │information item in the order in which they appear there. │
└──────────┴──────────────────────────────────────────────────────────────────┘
4.2 IRI Style
The IRI style is selected by including the value "http://www.w3.org/ns/wsdl/
style/iri" in the {style} property of an Interface Operation component.
When using this style, the value of the {message content model} property of the
Interface Message Reference component corresponding to the initial message of
the message exchange pattern MUST be "#element".^†
Use of this value indicates that XML Schema [XML Schema Structures] was used to
define the schema of the {element declaration} property of the Interface
Message Reference component of the Interface Operation component corresponding
to the initial message of the message exchange pattern. This schema MUST adhere
to the rules below:
• 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. There are no occurence constraints on the
sequence.
• The sequence MUST contain only local element children.^† Note these child
elements can contain the nillable attribute.
• The localPart of the element's QName MUST be the same as the Interface
Operation component's {name}.^†
• The complex type that defines the body of the element or its children
elements MUST NOT contain any attributes.^†
• The children elements of the sequence MUST derive from xs:simpleType, and
MUST NOT be of the type or derive from xs:QName, xs:NOTATION, xs:hexBinary
or xs:base64Binary.^†
4.3 Multipart style
The Multipart style is selected by including the value "http://www.w3.org/ns/
wsdl/style/multipart" in the {style} property of an Interface Operation
component.
When using this style, the value of the {message content model} property of the
Interface Message Reference component corresponding to the initial message of
the message exchange pattern MUST be "#element".^†
Use of this value indicates that XML Schema [XML Schema Structures] was used to
define the schema of the {element declaration} property of the Interface
Message Reference component of the Interface Operation component corresponding
to the initial message of the message exchange pattern. This schema MUST adhere
to the rules below:
• 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.^† The attributes
minOccurs and maxOccurs for these child elements MUST have a value 1.^†
Note these child elements can contain the nillable attribute.
• The localPart of the element's QName MUST be the same as the Interface
Operation component's {name}.^†
• 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.^†
5. WSDL SOAP Binding Extension
The SOAP binding extension described in this section is an extension for [WSDL
2.0 Core Language] to enable Web services applications to use SOAP. This
binding extension is SOAP version independent ("1.2" as well as other versions)
and extends WSDL 2.0 by adding properties to the Binding component, and its
related components, as defined in [WSDL 2.0 Core Language]. In addition, an XML
Infoset representation for these additional properties is provided, along with
a mapping from that representation to the various component properties.
As allowed in [WSDL 2.0 Core Language], a Binding component can exist without
indicating a specific Interface component that it applies to. In this case, no
Binding Operation or Binding Fault component can be present in the Binding
component.
The SOAP binding extension is designed with the objective of minimizing what
needs to be explicitly declared for common cases. This is achieved by defining
a set of default rules that affect all Interface Operation components of an
Interface component to which the SOAP binding extension is applied, unless
specifically overridden by a Binding Operation component. Thus, if a given
Interface Operation component is not referred to specifically by a Binding
Operation component, then all the default rules apply to that Interface
Operation component. As a result, in accordance with the requirements of [WSDL
2.0 Core Language], all operations of an Interface component will be bound by
this binding extension.
Note: As in other parts of this specification, one could have done away with
"default" properties at the component model level, and have set the value for
the corresponding non-default properties in the XML mapping section. However,
default properties are required for interface-less binding. Indeed, an
interface-less binding has no means to set the non-default version of the
property at the operation-level, since there is precisely no operation (there
is not even an interface). Hence the mapping needs to be done elsewhere.
A subset of the HTTP properties specified in the HTTP binding extension defined
in section 6. WSDL HTTP Binding Extension are present in a SOAP binding when
the SOAP binding uses HTTP as the underlying protocol, for example, when the
value of the {soap underlying protocol} property of the Binding component is
"http://www.w3.org/2003/05/soap/bindings/HTTP/". These properties MUST NOT be
used unless the underlying protocol is HTTP.^† The allowed properties are the
ones that describe the underlying protocol (HTTP):
• {http location} and {http location ignore uncited} on Binding Operation
components, as defined in 6.5 Binding Operations and 6.8.2.2.2 Controlling
the serialization of the query string in the request IRI, respectively.
• {http headers} on Binding Message Reference and Binding Fault components,
as defined in 6.6 Declaring HTTP Headers
• {http query parameter separator default} on Binding components, {http query
parameter separator} on Binding Operation components, as defined in 6.5.2
Relationship to WSDL Component Model
• {http content encoding default} on Binding and Binding Operation
components, {http content encoding} on Binding Message Reference and
Binding Fault components, as defined in 6.9 Specifying the Content Encoding
• {http cookies} on Binding components, as defined in 6.10 Specifying the Use
of HTTP Cookies.
• {http authentication scheme} and {http authentication realm} on Endpoint
components, as defined in 6.11 Specifying HTTP Access Authentication
5.1 SOAP Syntax Summary (Non-Normative)
*
*
*
*
*
*
*
*??
*
*
*
*
*
*
*??
*
*
*
*
*
*
*
*
*
*
Note:
The double question marks ("??") after the attributes in the whttp namespace
indicates that those optional attributes only make sense when the SOAP binding
uses HTTP as the underlying protocol, for example, when the value of the
wsoap:protocol attribute is "http://www.w3.org/2003/05/soap/bindings/HTTP/".
5.2 Identifying the use of the SOAP Binding
A Binding component (defined in [WSDL 2.0 Core Language]) is identified as a
SOAP binding by assigning the value "http://www.w3.org/ns/wsdl/soap" to the {
type} property of the Binding component.
5.3 SOAP Binding Rules
• Payload Construction. When formulating the SOAP envelope to be transmitted,
the contents of the payload (i.e., the contents of the SOAP Body element
information item of the SOAP envelope) MUST be what is defined by the
corresponding Interface Message Reference component.^† This is further
subject to optimization by a feature in use which affects serialization,
such as MTOM [SOAP Message Transmission Optimization Mechanism]. The
following binding rules MUST be adhered to:
□ If the value of the {message content model} property of the Interface
Message Reference component is "#any", then the payload MAY be any one
XML element.
□ If the value is "#none", then the payload MUST be empty.^†
□ If the value is "#element", then the payload MUST be the element
information item identified by the {element declaration} property of
the Interface Message Reference component.^†
□ If the Interface Message Reference component is declared using a
non-XML type system (as considered in the Types section of [WSDL 2.0
Core Language]), then additional binding rules MUST be defined to
indicate how to map those components into the SOAP envelope.^†
Note:
This SOAP binding extension only allows one single element in the SOAP
body.
• SOAP Header Construction. If the {soap headers} property as defined in
section 5.9 Declaring SOAP Header Blocks exists and is not empty in a
Binding Message Reference or Binding Fault component, then an element
information item conforming to the element declaration of a SOAP Header
Block component's {element declaration} property, in the {soap headers}
property, MAY be turned into a SOAP header block for the corresponding
message.
If the value of the SOAP Header Block component's {required} property is
"true", the inclusion of this SOAP header block is REQUIRED, otherwise it
is OPTIONAL.
And, if the SOAP Header Block component's {mustUnderstand} property is
present and its value is "true", that particular SOAP header block MUST be
marked with a mustUnderstand attribute information item with a value of
"true" or "1" as per the SOAP specification.
SOAP header blocks other than the ones declared in the {soap headers}
property may be present at run-time, such as the SOAP header blocks
resulting from SOAP modules declared as explained in section 5.8 Declaring
SOAP Modules.
5.4 Specifying the SOAP Version
5.4.1 Description
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 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] is
used.
5.4.2 Relationship to WSDL Component Model
The SOAP protocol specification adds the following property to the WSDL
component model (as defined in [WSDL 2.0 Core Language]):
• {soap version} REQUIRED. A xs:string, to the Binding component.
5.4.3 XML Representation
...
The XML representation for specifying the SOAP version is an optional attribute
information item with the following Infoset properties:
• A [local name] of version
• A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
• A type of xs:string
5.4.4 Mapping from XML Representation to Component properties
See Table 5-1.
Table 5-1. Mapping from XML Representation to Binding component Extension
Properties
┌──────────┬──────────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────┼──────────────────────────────────────────────────────────────────┤
│{soap │The actual value of the wsoap:version attribute information item, │
│version} │if present; otherwise "1.2". │
└──────────┴──────────────────────────────────────────────────────────────────┘
5.5 Specifying the SOAP Underlying Protocol
5.5.1 Description
Every SOAP binding MUST indicate what underlying protocol is in use.^†
5.5.2 Relationship to WSDL Component Model
The SOAP protocol specification adds the following property to the WSDL
component model (as defined in [WSDL 2.0 Core Language]):
• {soap underlying protocol} REQUIRED. A xs:anyURI, which is an absolute IRI
as defined by [IETF RFC 3987], to the Binding component. This IRI refers to
an appropriate SOAP underlying protocol binding (see SOAP Protocol Binding
Framework in [SOAP 1.2 Part 1: Messaging Framework (Second Edition)]),
which is to be used for any of the SOAP interactions described by this
binding.
5.5.3 XML Representation
...
The XML representation for specifying the SOAP protocol is a REQUIRED attribute
information item with the following Infoset properties:
• A [local name] of protocol
• A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
• A type of xs:anyURI
5.5.4 Mapping from XML Representation to Component Properties
See Table 5-2.
Table 5-2. Mapping from XML Representation to Binding component Extension
Properties
┌─────────────────────┬───────────────────────────────────────────────────────┐
│ Property │ Value │
├─────────────────────┼───────────────────────────────────────────────────────┤
│{soap underlying │The actual value of the wsoap:protocol attribute │
│protocol} │information item. │
└─────────────────────┴───────────────────────────────────────────────────────┘
5.6 Binding Faults
5.6.1 Description
For every Interface Fault component contained in an Interface component, a
mapping to a SOAP Fault MUST be described.^† This binding extension
specification allows the user to indicate the SOAP fault code and subcodes that
are transmitted for a given Interface Fault component.
5.6.2 Relationship to WSDL Component Model
The SOAP Fault binding extension adds the following properties to the WSDL
component model (as defined in [WSDL 2.0 Core Language]):
• {soap fault code} REQUIRED. A union of xs:QName and xs:token, to the
Binding Fault component, where:
□ when the value of the {soap version} is "1.2", the allowed QNames MUST
be the ones defined by [SOAP 1.2 Part 1: Messaging Framework (Second
Edition)], section 5.4.6^†;
□ the allowed token value is "#any".
The value of this property identifies a possible SOAP fault for the
operations in scope. If the value of this property is "#any", no assertion
is made about the possible value of the SOAP fault code.
• {soap fault subcodes} REQUIRED. A union of list of xs:QName, and xs:token
where the allowed token value is "#any", to the Binding Fault component.
The value of this property identifies one or more subcodes for this SOAP
fault. The list of subcodes is the nested sequence of subcodes. An empty
list represents a fault code without subcodes.
5.6.3 XML Representation
*
*
The XML representation for binding a SOAP Fault are two attribute information
items with the following Infoset properties:
• wsoap:code OPTIONAL attribute information item
□ A [local name] of code
□ A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
□ A type of union of xs:QName and xs:token where the allowed token value
is "#any"
• wsoap:subcodes OPTIONAL attribute information item
□ A [local name] of subcodes
□ A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
□ A type of union of list of xs:QName, and xs:token where the allowed
token value is "#any"
5.6.4 Mapping XML Representation to Component Properties
See Table 5-3.
Table 5-3. Mapping from XML Representation to SOAP Fault component Properties
┌──────────────┬──────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{soap fault │The actual value of the code attribute information item, if │
│code} │present; otherwise "#any". │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{soap fault │The actual value of the subcodes attribute information item, │
│subcodes} │if present; otherwise "#any". │
└──────────────┴──────────────────────────────────────────────────────────────┘
5.7 Binding Operations
5.7.1 Description
For every Interface Operation component contained in an Interface component, in
addition to the binding rules (for SOAP 1.2, see 5.10.3 SOAP 1.2 Binding Rules
), there may be additional binding information to be specified. This binding
extension specification allows the user to indicate the SOAP Message Exchange
Pattern (MEP) and a value for the SOAP Action Feature on a per-operation basis.
5.7.2 Relationship to WSDL Component Model
The SOAP Operation binding extension specification adds the following property
to the WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {soap mep default} OPTIONAL. A xs:anyURI, which is an absolute IRI as
defined by [IETF RFC 3987], to the Binding component.^† The value of this
property identifies the default SOAP Message Exchange Pattern (MEP) for all
the Interface Operation components of any Interface component to which this
Binding is applied.
• {soap mep} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by [
IETF RFC 3987], to the Binding Operation component.^† The value of this
property identifies the SOAP Message Exchange Pattern (MEP) for this
specific operation (see 5.10.3 SOAP 1.2 Binding Rules, paragraph "SOAP MEP
Selection", for constraints on bindings).
• {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by
[IETF RFC 3987], to the Binding Operation component.^† The value of this
property identifies the value of the SOAP Action Feature for the initial
message of the message exchange pattern of the Interface Operation bound,
as specified in the binding rules of bindings to specific versions of SOAP
(see 5.10.3 SOAP 1.2 Binding Rules for the SOAP 1.2 binding when the value
of the {soap version} property of the Binding component is "1.2").
5.7.3 XML Representation
The XML representation for binding a Binding Operation are two attribute
information items with the following Infoset properties:
• wsoap:mep OPTIONAL attribute information item
□ A [local name] of mep
□ A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
□ A type of xs:anyURI
• wsoap:action OPTIONAL attribute information item
□ A [local name] of action
□ A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
□ A type of xs:anyURI
The following attribute information item for the binding element information
item is defined:
• wsoap:mepDefault OPTIONAL attribute information item
□ A [local name] of mepDefault
□ A [namespace name] of " http://www.w3.org/ns/wsdl/soap "
□ A type of xs:anyURI
5.7.4 Mapping from XML Representation to Component Properties
See Table 5-4.
Table 5-4. Mapping from XML Representation to SOAP Operation Component
Properties
┌──────────────┬──────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{soap mep │The actual value of the wsoap:mepDefault attribute information│
│default} │item, if present. │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{soap mep} │The actual value of the wsoap:mep attribute information item, │
│ │if present. │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{soap action} │The actual value of the wsoap:action attribute information │
│ │item, if any. │
└──────────────┴──────────────────────────────────────────────────────────────┘
5.8 Declaring SOAP Modules
5.8.1 Description
The SOAP messaging framework allows a Web service to engage one or more
additional features (typically implemented as one or more SOAP header blocks),
as defined by SOAP Modules (see [SOAP 1.2 Part 1: Messaging Framework (Second
Edition)]). This binding extension specification allows description of which
SOAP Modules are in use across an entire binding, on a per operation basis or
on a per-message basis.
5.8.2 Relationship to WSDL Component Model
The SOAP Module component adds the following property to the WSDL component
model (as defined in [WSDL 2.0 Core Language]):
• {soap modules} OPTIONAL. A set of SOAP Module components as defined in
5.8.3 SOAP Module component to the Binding component
• Similarly, {soap modules} OPTIONAL, to the Binding Operation component
• Similarly, {soap modules} OPTIONAL, to the Binding Message Reference
component
• Similarly, {soap modules} OPTIONAL, to the Binding Fault component
• Similarly, {soap modules} OPTIONAL, to the Binding Fault Reference
component
The SOAP modules applicable for a particular operation of any service, consists
of all the modules specified in the input or output Binding Message Reference
components, the infault or outfault Binding Fault Reference components, those
specified within the Binding Fault components, those specified within the
Binding Operation components and those specified within the Binding component.
If any module is declared in multiple components, then the requiredness of that
module is defined by the closest declaration, where closeness is defined by
whether it is specified directly at the Binding Message Reference component or
Binding Fault Reference component level, the Binding Fault level or the Binding
Operation component level or the Binding component level, respectively.
5.8.3 SOAP Module component
The SOAP Module component identifies a SOAP module that is in use.
The properties of the SOAP Module component are as follows:
• {ref} REQUIRED. A xs:anyURI, which is an absolute IRI as defined by [IETF
RFC 3987].^† The value of this property uniquely identifies the SOAP module
that is in use (as per the SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework
(Second Edition)] processing model).
• {required} REQUIRED. A xs:boolean indicating if the SOAP module is
required.
• {parent} REQUIRED. The Binding, Binding Operation, Binding Message
Reference, Binding Fault or Binding Fault Reference components that
contains this component in its {soap modules} property.
5.8.4 XML Representation
*
*
*
*
*
*
The XML representation for a SOAP Module component is an element information
item with the following Infoset properties:
• A [local name] of module
• A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
• One or more attribute information items amongst its [attributes] as
follows:
□ A REQUIRED ref attribute information item with the following Infoset
properties:
☆ A [local name] of ref
☆ A [namespace name] which has no value
☆ A type of xs:anyURI
□ An OPTIONAL required attribute information item with the following
Infoset properties:
☆ A [local name] of required
☆ A [namespace name] which has no value
☆ A type of xs:boolean
□ Zero or more namespace qualified attribute information items. The
[namespace name] of such attribute information items MUST NOT be "http:
//www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".
• Zero or more element information item amongst its [children], in order, as
follows:
1. Zero or more documentation element information items as defined in [
WSDL 2.0 Core Language].
2. Zero or more namespace-qualified element information items amongst its
[children]. The [namespace name] of such element information items MUST
NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/
ns/wsdl/soap".
5.8.5 Mapping from XML Representation to Component Properties
See Table 5-5.
Table 5-5. Mapping from XML Representation to SOAP Module component-related
Properties
┌──────────┬──────────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ │The set of SOAP Module components corresponding to all the module │
│{soap │element information item in the [children] of the binding, │
│modules} │operation, fault, input, output, infault, outfault element │
│ │information items, if any. │
├──────────┼──────────────────────────────────────────────────────────────────┤
│{ref} │The actual value of the ref attribute information item. │
├──────────┼──────────────────────────────────────────────────────────────────┤
│{required}│The actual value of the required attribute information item, if │
│ │present; otherwise "false". │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ │The Binding, Binding Operation, Binding Message Reference, Binding│
│{parent} │Fault or Binding Fault Reference component corresponding to the │
│ │binding, operation, fault, input, output, infault or outfault │
│ │element information item in [parent]. │
└──────────┴──────────────────────────────────────────────────────────────────┘
5.8.6 IRI Identification Of A SOAP Module component
WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a
fragment identifier syntax for identifying components of a WSDL 2.0 document.
A SOAP Module component can be identified using the wsdl.extension XPointer
Framework scheme:
wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.module(parent/ref))
1. parent is the pointer part of the {parent} component, as specified in WSDL
Version 2.0 Part 1: Core Language.
2. ref is the value of the {ref} property of the component.
5.9 Declaring SOAP Header Blocks
5.9.1 Description
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.
5.9.2 Relationship to WSDL Component Model
The SOAP Header Blocks binding extension specification adds the following
property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {soap headers} OPTIONAL. A set of SOAP Header Block components as defined
in 5.9.3 SOAP Header Block component, to the Binding Message Reference
component.
• Similarly, {soap headers} OPTIONAL, to the Binding Fault component.
5.9.3 SOAP Header Block component
A SOAP Header Block component describes an abstract piece of header data (SOAP
header block) that is associated with the exchange of messages between the
communicating parties. The presence of a SOAP Header Block component in a WSDL
description indicates that the service supports headers, and MAY require a
client interacting with the service to use the described header block. Zero or
one such header block may be used.
The properties of the SOAP Header Block component are as follows:
• {element declaration} REQUIRED. An XML element declaration in the {element
declarations} property of the Description component. This XML element
declaration uniquely represents a specific SOAP header block.
• {mustUnderstand} REQUIRED. A xs:boolean. When its value is "true", the SOAP
header block MUST be decorated with a SOAP mustUnderstand attribute
information item with a value of "true"; if so, the XML element declaration
referenced by the {element declaration} property MUST allow this SOAP
mustUnderstand attribute information item.^† Otherwise, no additional
constraint is placed on the presence and value of a SOAP mustUnderstand
attribute information item.
• {required} REQUIRED. A xs:boolean indicating if the SOAP header block is
required. If the value is "true", then the SOAP header block MUST be
included in the message.^† If it is "false", then the SOAP header block MAY
be included.
• {parent} REQUIRED. The Binding Fault or Binding Message Reference component
that contains this component in its {soap headers} property.
5.9.4 XML Representation
*
*
...
*
*
...
*
*
*
The XML representation for a SOAP Header Block component is an element
information item with the following Infoset properties:
• A [local name] of header
• A [namespace name] of "http://www.w3.org/ns/wsdl/soap"
• One or more attribute information items amongst its [attributes] as
follows:
□ A REQUIRED element attribute information item with the following
Infoset properties:
☆ A [local name] of element
☆ A [namespace name] which has no value
☆ A type of xs:QName
□ An OPTIONAL mustUnderstand attribute information item with the
following Infoset properties:
☆ A [local name] of mustUnderstand
☆ A [namespace name] which has no value
☆ A type of xs:boolean
□ An OPTIONAL required attribute information item with the following
Infoset properties:
☆ A [local name] of required
☆ A [namespace name] which has no value
☆ A type of xs:boolean
□ Zero or more namespace qualified attribute information items. The
[namespace name] of such attribute information items MUST NOT be "http:
//www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".
• Zero or more element information item amongst its [children], in order, as
follows:
1. Zero or more documentation element information items as defined in [
WSDL 2.0 Core Language].
2. Zero or more namespace-qualified element information items amongst its
[children]. The [namespace name] of such element information items MUST
NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/
ns/wsdl/soap".
5.9.5 Mapping XML Representation to Component Properties
See Table 5-6.
Table 5-6. Mapping from XML Representation to SOAP Header Block
component-related Properties
┌────────────────┬────────────────────────────────────────────────────────────┐
│ Property │ Value │
├────────────────┼────────────────────────────────────────────────────────────┤
│ │The set of SOAP Header Block components corresponding to all│
│{soap headers} │the header element information item in the [children] of the│
│ │fault, input or output element information item, if any. │
├────────────────┼────────────────────────────────────────────────────────────┤
│ │The element declaration from the {element declarations} │
│ │resolved to by the value of the element attribute │
│{element │information item. The value of the element attribute │
│declaration} │information item MUST resolve to a global element │
│ │declaration from the {element declarations} property of the │
│ │Description component.^† │
├────────────────┼────────────────────────────────────────────────────────────┤
│{mustUnderstand}│The actual value of the mustUnderstand attribute information│
│ │item, if present; otherwise "false". │
├────────────────┼────────────────────────────────────────────────────────────┤
│{required} │The actual value of the required attribute information item,│
│ │if present; otherwise "false". │
├────────────────┼────────────────────────────────────────────────────────────┤
│ │The Binding Fault or Binding Message Reference component │
│{parent} │corresponding to the fault, input or output element │
│ │information item in [parent]. │
└────────────────┴────────────────────────────────────────────────────────────┘
5.9.6 IRI Identification Of A SOAP Header Block component
WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a
fragment identifier syntax for identifying components of a WSDL 2.0 document.
A SOAP Header Block component can be identified using the wsdl.extension
XPointer Framework scheme:
wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.header(parent/element
declaration))
1. parent is the pointer part of the {parent} component, as specified in WSDL
Version 2.0 Part 1: Core Language.
2. element declaration is the value of the {element declaration} property.
5.10 WSDL SOAP 1.2 Binding
This section describes the SOAP 1.2 binding for WSDL 2.0. This binding does NOT
natively support the full range of capabilities from SOAP 1.2. Certain
capabilities not widely used, or viewed as problematic in practice, are not
available -in many cases because supporting them was considered as adding
considerable complexity to the language. Here are examples of such unsupported
capabilities:
• multiple children of the SOAP Body;
• multiple SOAP Fault Detail entries;
• non-qualified elements as children of a SOAP Fault Detail.
5.10.1 Identifying a WSDL SOAP 1.2 Binding
A WSDL SOAP Binding is identified as a SOAP 1.2 binding by assigning the value
"1.2" to the {soap version} property of the Binding component.
5.10.2 Description
The WSDL SOAP 1.2 binding extension defined in this section is an extension of
the SOAP binding defined in section 5. WSDL SOAP Binding Extension to enable
Web service applications to use SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework
(Second Edition)].
The WSDL SOAP 1.2 binding extension supports the SOAP 1.2 HTTP binding defined
by the [SOAP 1.2 Part 2: Adjuncts (Second Edition)] specification. This is
indicated by assigning the URI "http://www.w3.org/2003/05/soap/bindings/HTTP/"
(as defined by [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) to the {soap
underlying protocol} property. Other values MAY be used for this property in
conjunction with the SOAP 1.2 binding extension defined by this specification
provided that the semantics of such protocols are consistent with this binding
extension.
Default rules in section 5.10.3 SOAP 1.2 Binding Rules define the relationship
between SOAP message exchange patterns defined in [SOAP 1.2 Part 2: Adjuncts
(Second Edition)] and WSDL message exchange patterns defined in section 2.
Predefined Message Exchange Patterns.
5.10.3 SOAP 1.2 Binding Rules
These binding rules are applicable to SOAP 1.2 bindings.
• SOAP Action Feature. The value of the SOAP Action Feature for the initial
message of the message exchange pattern of the Interface Operation bound is
specified by the {soap action} property of this Binding Operation
component. If the Binding Operation component does NOT have a {soap action}
property defined, then the SOAP Action Feature (see [SOAP 1.2 Part 2:
Adjuncts (Second Edition)]) has NO value. Otherwise, its value is the value
of the SOAP Action Feature for the initial message of the message exchange
pattern. The {soap action} property has NO effect when binding to the
SOAP-Response MEP.
• SOAP MEP Selection. For a given Interface Operation component, if there is
a Binding Operation component whose {interface operation} property matches
the component in question and its {soap mep} property has a value, then the
SOAP MEP is the value of the {soap mep} property. Otherwise, the SOAP MEP
is the value of the Binding component's {soap mep default}, if any.
Otherwise, the Interface Operation component's {message exchange pattern}
property MUST have the value "http://www.w3.org/ns/wsdl/in-out", and the
SOAP MEP is the URI "http://www.w3.org/2003/05/soap/mep/request-response/"
identifying the SOAP Request-Response Message Exchange Pattern as defined
in [SOAP 1.2 Part 2: Adjuncts (Second Edition)].^†
• SOAP Detail Element. If any, the value of the SOAP "Detail" element MUST be
the element information item identified by the {element declaration}
property of the Interface Fault component.^†
• HTTP Method Selection. This default binding rule is applicable when the
value of the {soap underlying protocol} property of the Binding component
is "http://www.w3.org/2003/05/soap/bindings/HTTP/". If the SOAP MEP
selected as specified above has the value "http://www.w3.org/2003/05/soap/
mep/request-response/" then the HTTP method used is "POST". If the SOAP MEP
selected has the value "http://www.w3.org/2003/05/soap/mep/soap-response/"
then the HTTP method used is "GET".^†
5.10.4 Binding WSDL 2.0 MEPs to SOAP 1.2 MEPs
This section describes the relationship between WSDL components and SOAP 1.2
MEP properties as described in [SOAP 1.2 Part 2: Adjuncts (Second Edition)].
5.10.4.1 WSDL In-Out to SOAP Request-Response
This section describes the mapping from the WSDL "http://www.w3.org/ns/wsdl/
in-out" Message Exchange Pattern (MEP) to the SOAP "http://www.w3.org/2003/05/
soap/mep/request-response/" MEP (as would be the case for a usual
SOAP-over-HTTP In-Out operation). Extensions (such as [WSA 1.0 Core]) MAY alter
these mappings.
5.10.4.1.1 The Client
As the client, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RequestingSOAPNode".
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property
takes the value of the HTTP Request IRI, as defined in 6.4.6 HTTP Request IRI,
and modified as described in section 6.8.1 Serialization of the instance data
in parts of the HTTP request IRI.
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/OutboundMessage" property.
The WSDL "Out" message maps to the SOAP "http://www.w3.org/2003/05/soap/mep/
InboundMessage" property.
5.10.4.1.2 The Service
As the service, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RespondingSOAPNode".
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/InboundMessage" property.
The WSDL "Out" message maps to the SOAP "http://www.w3.org/2003/05/soap/mep/
OutboundMessage" property.
5.10.4.2 WSDL In-Out to SOAP SOAP-Response
This section describes the mapping from the WSDL "http://www.w3.org/ns/wsdl/
in-out" MEP to the "http://www.w3.org/2003/05/soap/mep/soap-response/" SOAP
MEP. Extensions (such as [WSA 1.0 Core]) MAY alter these mappings.
5.10.4.2.1 The Client
As the client, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RequestingSOAPNode".
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property
takes the value of the HTTP Request IRI, as defined in 6.4.6 HTTP Request IRI,
and modified as described in section 6.8.1 Serialization of the instance data
in parts of the HTTP request IRI.
The value of the {message content model} property for the Interface Message
Reference components of the {interface message references} property MUST be
either "#element" or "#none". When the value is:
• "#element", the WSDL "In" message is mapped to the destination URI, as per
the rules in section 6.8.2 Serialization as application/
x-www-form-urlencoded .
• "#none", the WSDL "In" message is empty.
The SOAP "http://www.w3.org/2003/05/soap/mep/OutboundMessage" property has no
value.
The WSDL "Out" message maps to the SOAP "http://www.w3.org/2003/05/soap/mep/
InboundMessage" property.
5.10.4.2.2 The Service
As the service, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RespondingSOAPNode".
The WSDL "In" message is constructed from the destination URI as per the rules
in section 6.8.2 Serialization as application/x-www-form-urlencoded , WHEN the
value of the {message content model} property for the Interface Message
Reference components of the {interface message references} property is "#
element".
The WSDL "Out" message maps to the SOAP "http://www.w3.org/2003/05/soap/mep/
OutboundMessage" property.
5.10.4.3 WSDL In-Only to SOAP Request-Response
This section describes the mapping from the WSDL "http://www.w3.org/ns/wsdl/
in-only" MEP to the SOAP "http://www.w3.org/2003/05/soap/mep/request-response/"
MEP. Extensions (such as [WSA 1.0 Core]) MAY alter these mappings.
5.10.4.3.1 The Client
As the client, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RequestingSOAPNode".
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property
takes the value of the HTTP Request IRI, as defined in 6.4.6 HTTP Request IRI,
and modified as described in section 6.8.1 Serialization of the instance data
in parts of the HTTP request IRI.
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/OutboundMessage" property.
The SOAP "http://www.w3.org/2003/05/soap/mep/InboundMessage" property has no
value.
5.10.4.3.2 The Service
As the service, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RespondingSOAPNode".
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/InboundMessage" property.
The SOAP "http://www.w3.org/2003/05/soap/mep/OutboundMessage" property has no
value.
5.10.4.4 WSDL Robust-In-Only to SOAP Request-Response
This section describes the mapping from the WSDL "http://www.w3.org/ns/wsdl/
robust-in-only" MEP to the SOAP "http://www.w3.org/2003/05/soap/mep/
request-response/" MEP. Extensions (such as [WSA 1.0 Core]) MAY alter these
mappings.
5.10.4.4.1 The Client
As the client, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RequestingSOAPNode".
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property
takes the value of the HTTP Request IRI, as defined in 6.4.6 HTTP Request IRI,
and modified as described in section 6.8.1 Serialization of the instance data
in parts of the HTTP request IRI.
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/OutboundMessage" property.
The SOAP "http://www.w3.org/2003/05/soap/mep/InboundMessage" can contain a SOAP
fault.
5.10.4.4.2 The Service
As the service, the property "http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/Role" takes the value "RespondingSOAPNode".
The WSDL "In" message is mapped to the SOAP "http://www.w3.org/2003/05/soap/mep
/InboundMessage" property.
The SOAP "http://www.w3.org/2003/05/soap/mep/OutboundMessage" can contain a
SOAP fault.
5.11 Conformance
An element information item whose namespace name is "http://www.w3.org/ns/wsdl"
and whose local part is description conforms to this binding extension
specification if the element information items and attribute information items
whose namespace is http://www.w3.org/ns/wsdl/soap conform to the XML Schema for
that element or attribute as defined by this specification and additionally
adheres to all the constraints contained in this specification.
6. WSDL HTTP Binding Extension
The HTTP binding extension described in this section is an extension for [WSDL
2.0 Core Language] to enable Web services applications to use HTTP 1.1 [IETF
RFC 2616] (as well as other versions of HTTP) and HTTPS [IETF RFC 2818]. This
binding extension extends WSDL 2.0 by adding properties to the component model
defined in [WSDL 2.0 Core Language]. In addition an XML Infoset representation
for these additional properties is provided, along with a mapping from that
representation to the various component properties.
As allowed in [WSDL 2.0 Core Language], a Binding component can exist without
indicating a specific Interface component that it applies to and, in this case,
no Binding Operation or Binding Fault components can be present in the Binding
component.
The HTTP binding extension is designed with the objective of minimizing what
needs to be explicitly declared for common cases. This is achieved by defining
a set of default rules that affect all Interface Operation components of an
Interface component to which the HTTP binding extension is applied, unless
specifically overridden by a Binding Operation component. Thus, if a given
Interface Operation component is not referred to specifically by a Binding
Operation component, then all the default rules apply to that Interface
Operation component. As a result, in accordance with the requirements of [WSDL
2.0 Core Language], all operations of an Interface component will be bound by
this binding extension.
Note: As in other parts of this specification, one could have done away with
"default" properties at the component model level, and have set the value for
the corresponding non-default properties in the XML mapping section. However,
default properties are required for interface-less binding. Indeed, an
interface-less binding has no means to set the non-default version of the
property at the operation-level, since there is precisely no operation (there
is not even an interface). Hence the mapping needs to be done elsewhere.
[Definition: The internal tree representation of an input, output or fault
message is called an instance data, and is constrained by the schema definition
associated with the message: the XML element referenced in the {element
declaration} property of the Interface Message Reference component for input
and output messages (unless the {message content model} is "#any"), and in the
{element declaration} property of an Interface Fault component for faults.]
6.1 Identifying the use of the HTTP Binding
A Binding component (defined in [WSDL 2.0 Core Language]) is identified as an
HTTP binding by assigning the value "http://www.w3.org/ns/wsdl/http" to the {
type} property of the Binding component.
6.2 HTTP Syntax Summary (Non-Normative)
?
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
6.3 Supported Extensions
An implementation of the HTTP binding extension MUST support the following
extensions:
• "http://www.w3.org/ns/wsdl-extensions/safe" (see 3.1 Operation safety)
6.4 HTTP Binding Rules
6.4.1 HTTP Method Selection
When formulating the HTTP message to be transmitted, the HTTP request method
used MUST be selected using one of the following:^†
• For a given Interface Operation component, if there is a Binding Operation
component whose {interface operation} property matches the component in
question and its {http method} property has a value, then the value of the
{http method} property.
• Otherwise, the value of the Binding component's {http method default}, if
any.
• Otherwise, if a {safe} property as defined in 3.1 Operation safety is
present on the bound Interface Operation component and has a value of
"true", the value "GET".
• Otherwise, the value "POST".
6.4.2 HTTP Content Encoding Selection
When formulating the HTTP message to be transmitted, content encoding for a
given Binding Message Reference component is determined as follows:^†
• If the {http content encoding} property has a non-empty value, a
Content-Encoding header-field MUST be inserted with the value of this
property.
• Otherwise, if the value of the parent Binding Operation component's {http
content encoding default} property has a non-empty value, a
Content-Encoding header-field MUST be inserted with the value of this
property.
• Otherwise, if the value of the grandparent Binding component's {http
content encoding default} property has a non-empty value, a
Content-Encoding header-field MUST be inserted with the value of this
property.
When formulating the HTTP fault message to be transmitted, content encoding for
a given Binding Fault component is determined as follows:^†
• If the {http content encoding} property has a non-empty value, then a
Content-Encoding header-field MUST be inserted with the value of this
property.
• If the {http content encoding default} property has a non-empty value, then
a Content-Encoding header-field MUST be inserted with the value of this
property.
The body of the response message is encoded using the specified content
encoding.
6.4.3 Payload Construction And Serialization Format
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 Interface Message Reference or Interface Fault components,
serialized as specified by the serialization format used.^†
[Definition: The serialization format is a media type token ("type/subtype").
It identifies rules to serialize the payload in an HTTP message. Its value is
defined by the following rules. The HTTP request serialization format MUST be
in the media type range specified by the {http input serialization} property.
The HTTP response serialization format MUST be in the media type range
specified by the {http output serialization} property. The HTTP serialization
format of a fault MUST be in the media type range specified by the {http fault
serialization} property. The concept of media type range is defined in Section
14.1 of [IETF RFC 2616]. The serialization format MAY have associated media
type parameters (specified with the parameter production of media-range in
Section 14.1 of [IETF RFC 2616]. ]
Section 6.8 Serialization Format of Instance Data defines serialization formats
supported by this binding extension along with their constraints.
• Interface Message Reference component:
□ If the value of the {message content model} property of the Interface
Message Reference bound is "#any" or "#element", the serialization of
the instance data is specified as defined in section 6.4.3.1
Serialization rules for XML messages.
□ If the value is "#none", then the payload MUST be empty and the value
of the corresponding serialization property ({http input serialization}
or {http output serialization}) is ignored.^†
□ If the value is "#other", then the serialization format and its
associated media type parameters, if any, specifies the value of the
HTTP Content-Type entity-header field as defined in section 14.17 of [
IETF RFC 2616]. The serialization of the payload is undefined.
• Interface Fault component: the serialization of the instance data is
specified as defined in section 6.4.3.1 Serialization rules for XML
messages.
If the Interface Message Reference component or the Interface Fault component
is declared using a non-XML type system (as considered in the Types section of
[WSDL 2.0 Core Language]), then additional binding rules MUST be defined in an
extension specification to indicate how to map those components into the HTTP
envelope.^†
6.4.3.1 Serialization rules for XML messages
The serialization rules for messages whose {message content model} is either "#
element" or "#any", AND the serialization rules for fault messages, are as
follows:^†
• If the serialization format is "application/x-www-form-urlencoded", then
the serialization of the instance data is defined by section 6.8.2
Serialization as application/x-www-form-urlencoded .
• If the serialization format is "multipart/form-data", then the
serialization of the instance data is defined by section 6.8.4
Serialization as multipart/form-data .
• If the serialization format is "application/xml", then the serialization of
the instance data is defined by section 6.8.3 Serialization as application/
xml .
• Otherwise, then the serialization of the instance data is defined by
section 6.8.3 Serialization as application/xml with the following
additional rule: the value of the HTTP Content-Type entity-header field is
the value of the serialization format and its associated media type
parameters, if any.
6.4.4 Default input and output serialization format
Section Table 6-1 defines the default values for the GET, POST, PUT and DELETE
values of the HTTP method as selected in section 6.4.1 HTTP Method Selection.
Table 6-1. Default values for GET, POST, PUT and DELETE
┌─────────────────────────────┬─────────────────────────┬─────────────────────┐
│ HTTP Method │ Default Input │ Default Output │
│ │ Serialization │ Serialization │
├─────────────────────────────┼─────────────────────────┼─────────────────────┤
│Selected in 6.4.1 HTTP Method│{http input serialization│ {http output │
│ Selection │ } │ serialization} │
├─────────────────────────────┼─────────────────────────┼─────────────────────┤
│GET │application/ │application/xml │
│ │x-www-form-urlencoded │ │
├─────────────────────────────┼─────────────────────────┼─────────────────────┤
│POST │application/xml │application/xml │
├─────────────────────────────┼─────────────────────────┼─────────────────────┤
│PUT │application/xml │application/xml │
├─────────────────────────────┼─────────────────────────┼─────────────────────┤
│DELETE │application/ │application/xml │
│ │x-www-form-urlencoded │ │
└─────────────────────────────┴─────────────────────────┴─────────────────────┘
Note:
The application/x-www-form-urlencoded serialization format places constraints
on the XML Schema definition of the {element declaration} property of the
Interface Message Reference components of the Interface Operation component
bound (see 6.8.2 Serialization as application/x-www-form-urlencoded ).
The default value for the {http input serialization} and {http output
serialization} properties for any other HTTP method selected is application/
xml.
Mechanisms other than setting the serialization properties MAY modify the
serialization format of the instance data corresponding to the message. An
example of such modification is the WSDL SOAP Binding HTTP IRI Serialization
rules specified in 5.3 SOAP Binding Rules. This binding extension specifies
that the SOAP-Response Message Exchange Pattern ([SOAP 1.2 Part 2: Adjuncts
(Second Edition)], Section 6.3) supports input message serialization only as
application/x-www-form-urlencoded. Other examples are other message exchange
patterns or binding extensions.
6.4.5 HTTP Header Construction
If the {http headers} property as defined in section 6.6 Declaring HTTP Headers
exists and is not empty in a Binding Message Reference or Binding Fault
component, HTTP headers conforming to each HTTP Header component contained in
this {http headers} property MAY be serialized as follows:^†
• The HTTP header field name used is the value of the {name} property of the
HTTP Header component. The HTTP binding MUST NOT set an HTTP header field
corresponding to the value of the {name} property already set by another
mechanism, such as the HTTP stack or another feature.^†
• The HTTP header field value, whose XML Schema type is declared by the {type
definition} property of the HTTP Header component, is serialized following
the rules of the field-value production of section 4.2 of [IETF RFC 2616].
If the value of an HTTP Header component's {required} property is "true", the
inclusion of this HTTP header field is REQUIRED^†, otherwise it is OPTIONAL.
6.4.6 HTTP Request IRI
When formulating the HTTP Request, the HTTP Request IRI is an absolute IRI
reference and is the value of the {http location} property of the Binding
Operation component, resolved using the value of the {address} property of the
Endpoint component (see section 5 of [IETF RFC 3986]).^† If the {http location}
property is set, the HTTP Request IRI is the value of the {address} property of
the Endpoint component. Input serializations may define additional processing
rules to be applied to the value of {http location} before applying the process
of reference resolution, i.e. before combining it with the {address} property
of the endpoint element to form the HTTP Request IRI. For example, the three
serialization formats defined in section 6.8 Serialization Format of Instance
Data define a syntax to use the {http location} as a template using elements of
the instance data.
If the resulting IRI uses the https scheme, then HTTP over TLS [IETF RFC 2818]
is used to send the HTTP request.
The HTTP Request IRI identifies the resource upon which to apply the request
and is transmitted using the Request-URI, and optionally the Host header field,
as defined in [IETF RFC 2616].
6.5 Binding Operations
6.5.1 Description
This binding extension specification provides a binding to HTTP of Interface
Operation components whose {message exchange pattern} property has a value
amongst:
• "http://www.w3.org/ns/wsdl/in-only"
• "http://www.w3.org/ns/wsdl/robust-in-only"
• "http://www.w3.org/ns/wsdl/in-out"
This HTTP binding extension MAY be used with other message exchange patterns,
such as outbound message exchange patterns, provided that additional semantics
are defined, for example through an extension.
Each of the three supported message exchange patterns above involves one or two
messages or faults being exchanged. The first one is transmitted using an HTTP
request, and the second one is transmitted using the corresponding HTTP
response.^† In cases where only one single message is being sent, the message
body of the HTTP response MUST be empty.^†
For successful responses, the HTTP response code MUST be:
• 202 when the MEP is "http://www.w3.org/ns/wsdl/in-only"^†
• 204 when the MEP is "http://www.w3.org/ns/wsdl/robust-in-only"^†
For every Binding Operation component corresponding to such Interface Operation
components, this binding extension specification allows the user to indicate
the HTTP method to use, the input, output and fault serialization, and the
location of the bound operation.
6.5.2 Relationship to WSDL Component Model
The HTTP binding extension adds the following properties to the WSDL component
model (as defined in [WSDL 2.0 Core Language]):
• {http location} OPTIONAL. An xs:anyURI, to the Binding Operation component.
It MUST contain an IRI reference and MUST NOT include a fragment identifier
component.^†
• {http method default} OPTIONAL. A xs:string, to the Binding component,
indicating the default value for the HTTP Request Method for all the
Interface Operation components of any Interface component to which this
Binding is applied.
• {http method} OPTIONAL. A xs:string, to the Binding Operation component,
indicating the value for the HTTP Request Method for this specific Binding
Operation.
• {http input serialization} REQUIRED. A xs:string, to the Binding Operation
component, indicating allowed serialization rules of the HTTP Request
message for this specific operation, as described in section 6.5.3
Specification of serialization rules allowed.
• {http output serialization} REQUIRED. A xs:string, to the Binding Operation
component, indicating allowed serialization rules of the HTTP Response
message for this specific operation, as described in section 6.5.3
Specification of serialization rules allowed.
• {http fault serialization} REQUIRED. A xs:string, to the Binding Operation
component, indicating allowed serialization rules of the HTTP Response
message for this specific operation in case a fault is returned, as
described in section 6.5.3 Specification of serialization rules allowed.
• {http query parameter separator default} REQUIRED. A xs:string, to the
Binding component, indicating the default query parameter separator
character for all the Interface Operation components of any Interface
component to which this Binding is applied to.
• {http query parameter separator} OPTIONAL. A xs:string, to the Binding
Operation component, indicating the query parameter separator character for
this Binding Operation.
6.5.3 Specification of serialization rules allowed
The value of the {http input serialization}, {http output serialization} and {
http fault serialization} properties is similar to the value allowed for the
Accept HTTP header defined by the HTTP 1.1 specification, Section 14.1 (see [
IETF RFC 2616]) and MUST follow the production rules defined in that section
except for the following:^†
1. The prefix "Accept:" MUST NOT be used.
2. The rule qdtext is changed from:
qdtext = >
to:
qdtext = >
This change is made to disallow non-US-ASCII OCTETs.
These properties indicate the range of media types and associated parameters
with which an instance MAY be serialized. The value of the serialization format
used for a message is a media type which MUST be covered by this range.^† Wild
cards (for example, "application/*") SHOULD NOT be used in this attribute
information item since they may lead to interoperability problems.^†
The use of {http input serialization}, {http output serialization} and {http
fault serialization} is specified in section 6.4.3 Payload Construction And
Serialization Format.
6.5.4 XML Representation
The XML representation for binding an Operation are six attribute information
items with the following Infoset properties:
• An OPTIONAL location attribute information item with the following Infoset
properties:
□ A [local name] of location
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:anyURI
• An OPTIONAL method attribute information item with the following Infoset
properties:
□ A [local name] of method
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
• An OPTIONAL inputSerialization attribute information item with the
following Infoset properties:
□ A [local name] of inputSerialization
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
• An OPTIONAL outputSerialization attribute information item with the
following Infoset properties:
□ A [local name] of outputSerialization
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
• An OPTIONAL faultSerialization attribute information item with the
following Infoset properties:
□ A [local name] of faultSerialization
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
• An OPTIONAL queryParameterSeparator attribute information item with the
following Infoset properties:
□ A [local name] of queryParameterSeparator
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string whose pattern facet is "[&;a-zA-Z0-9\-\._~!$'\(\):@
/\?\*\+,]{1,1}", "&" and ";" being the most frequently used characters
in practice.
The following attribute information items for the binding element information
item are defined:
• An OPTIONAL methodDefault attribute information item with the following
Infoset properties:
□ A [local name] of methodDefault
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
• An OPTIONAL queryParameterSeparatorDefault attribute information item with
the following Infoset properties:
□ A [local name] of queryParameterSeparatorDefault
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string whose length facet value is "1". The allowed
characters are the same as for the {http query parameter separator}
property above.
6.5.5 Mapping from XML Representation to Component Properties
See Table 6-2.
Table 6-2. Mapping from XML Representation to Binding Operation component
Extension Properties
┌──────────────────┬──────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http location} │The actual value of the whttp:location attribute │
│ │information item, if present. │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http method │The actual value of the whttp:methodDefault attribute │
│default} │information item, if present. │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http method} │The actual value of the whttp:method attribute information│
│ │item, if present. │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http input │The actual value of the whttp:inputSerialization attribute│
│serialization} │information item, if present; otherwise, the default value│
│ │as defined in 6.4 HTTP Binding Rules. │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http output │The actual value of the whttp:outputSerialization │
│serialization} │attribute information item, if present; otherwise, the │
│ │default value as defined in 6.4 HTTP Binding Rules. │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http fault │The actual value of the whttp:faultSerialization attribute│
│serialization} │information item, if present; otherwise "application/xml".│
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http query │The actual value of the │
│parameter │whttp:queryParameterSeparatorDefault attribute information│
│separator default}│item, if present; otherwise, "&". │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http query │The actual value of the whttp:queryParameterSeparator │
│parameter │attribute information item, if present. │
│separator} │ │
└──────────────────┴──────────────────────────────────────────────────────────┘
6.6 Declaring HTTP Headers
6.6.1 Description
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.
6.6.2 Relationship to WSDL Component Model
The HTTP Header binding extension specification adds the following property to
the WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {http headers} OPTIONAL. A set of HTTP Header components as defined in
6.6.3 HTTP Header component, to the Binding Message Reference component.
• Similarly, {http headers} OPTIONAL, to the Binding Fault component.
A Binding Message Reference or a Binding Fault component's {http headers}
property MUST NOT contain multiple HTTP Header components with the same {name}
property.^†
6.6.3 HTTP Header component
An HTTP Header component describes an abstract piece of header data (HTTP
header field) that is associated with the exchange of messages between the
communicating parties. The presence of a HTTP Header component in a WSDL
description indicates that the service support headers, and MAY require a
client interacting with the service to use the described header field. Zero or
one such header field may be used.
The properties of the HTTP Header component are as follows:
• {name} REQUIRED. An xs:string whose pattern facet is "[!#-'*+\-.0-9A-Z^-z|
~]+", the name of the HTTP header field. The value of this property follows
the field-name production rules as specified in section 4.2 of [IETF RFC
2616].
• {type definition} REQUIRED. A Type Definition component, in the {type
definitions} property of the Description component, constraining the value
of the HTTP header field. This type MUST be a simple type.^†
• {required} REQUIRED. An xs:boolean indicating if the HTTP header field is
required. If the value is "true", then the HTTP header field MUST be
included in the message.^† If it is "false", then the HTTP header field MAY
be included.
• {parent} REQUIRED. The Binding Fault or Binding Message Reference component
that contains this component in its {http headers} property.
6.6.4 XML Representation
*
*
...
*
*
...
*
*
*
The XML representation for a HTTP Header component is an element information
item with the following Infoset properties:
• A [local name] of header
• A [namespace name] of "http://www.w3.org/ns/wsdl/http"
• One or more attribute information items amongst its [attributes] as
follows:
□ A REQUIRED name attribute information item with the following Infoset
properties:
☆ A [local name] of name
☆ A [namespace name] which has no value
☆ A type of xs:string whose pattern facet is "[!#-'*+\-.0-9A-Z^-z|~]
+".
□ A REQUIRED type attribute information item with the following Infoset
properties:
☆ A [local name] of type
☆ A [namespace name] which has no value
☆ A type of xs:QName
□ An OPTIONAL required attribute information item with the following
Infoset properties:
☆ A [local name] of required
☆ A [namespace name] which has no value
☆ A type of xs:boolean
□ Zero or more namespace qualified attribute information items. The
[namespace name] of such attribute information items MUST NOT be "http:
//www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/http".
• Zero or more element information item amongst its [children], in order, as
follows:
1. Zero or more documentation element information items as defined in [
WSDL 2.0 Core Language].
2. Zero or more namespace-qualified element information items amongst its
[children]. The [namespace name] of such element information items MUST
NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/
ns/wsdl/http".
6.6.5 Mapping from XML Representation to Component Properties
See Table 6-3.
Table 6-3. Mapping from XML Representation to HTTP Header component-related
Properties
┌───────────┬─────────────────────────────────────────────────────────────────┐
│ Property │ Value │
├───────────┼─────────────────────────────────────────────────────────────────┤
│{http │The set of HTTP Header components corresponding to all the header│
│headers} │element information item in the [children] of the fault, input or│
│ │output element information item, if any. │
├───────────┼─────────────────────────────────────────────────────────────────┤
│{name} │The value of the name attribute information item. │
├───────────┼─────────────────────────────────────────────────────────────────┤
│{type │The Type Definition component from the {type definitions} │
│definition}│property of the Description component resolved to by the value of│
│ │the type attribute information item. │
├───────────┼─────────────────────────────────────────────────────────────────┤
│{required} │The actual value of the required attribute information item, if │
│ │present; otherwise "false". │
├───────────┼─────────────────────────────────────────────────────────────────┤
│ │The Binding Fault or Binding Message Reference component │
│{parent} │corresponding to the fault, input or output element information │
│ │item in [parent]. │
└───────────┴─────────────────────────────────────────────────────────────────┘
6.6.6 IRI Identification Of An HTTP Header component
WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a
fragment identifier syntax for identifying components of a WSDL 2.0 document.
An HTTP Header component can be identified using the wsdl.extension XPointer
Framework scheme:
wsdl.extension(http://www.w3.org/ns/wsdl/http, whttp.header(parent/name))
1. parent is the pointer part of the {parent} component, as specified in WSDL
Version 2.0 Part 1: Core Language.
2. name is the {name} property value.
6.7 Specifying HTTP Error Code for Faults
6.7.1 Description
For every Interface Fault component contained in an Interface component, an
HTTP error code MAY be defined. It represents the error code that will be used
by the service in case the fault needs to be returned.
The fault definition SHOULD agree with the definition of the HTTP error codes,
as specified in section 8 of [IETF RFC 3205].^†
6.7.2 Relationship to WSDL Component Model
The HTTP Fault binding extension adds the following property to the WSDL
component model (as defined in [WSDL 2.0 Core Language]):
• {http error status code} REQUIRED. A union of xs:int and xs:token where the
allowed token value is "#any", to the Binding Fault component. An integer
value of this property identifies the error Status-Code as defined by [IETF
RFC 2616] that the service will use in case the fault is returned.^† If the
value of this property is "#any", no claim is made by the service.
6.7.3 XML Representation
*
The XML representation for binding an HTTP Fault is an attribute information
item with the following Infoset properties:
• a code OPTIONAL attribute information item
□ A [local name] of code
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of union of xs:int and xs:token where the allowed token value is
"#any"
6.7.4 Mapping from XML Representation to Component Properties
See Table 6-4.
Table 6-4. Mapping from XML Representation to Binding Fault component Extension
Properties
┌────────────────┬────────────────────────────────────────────────────────────┐
│ Property │ Value │
├────────────────┼────────────────────────────────────────────────────────────┤
│{http error │The actual value of the whttp:code attribute information │
│status code} │item, if present; otherwise "#any". │
└────────────────┴────────────────────────────────────────────────────────────┘
6.8 Serialization Format of Instance Data
This section specifies three serialization formats defining rules to encode the
instance data of an input or output message as an HTTP message. Table 6-5 and
Table 6-6 give an overview of those serialization formats and their
constraints. All of them allow serialization of parts of the instance data in
the HTTP Request IRI, as defined in section 6.8.1 Serialization of the instance
data in parts of the HTTP request IRI.
Other serialization formats may be defined. Those MAY place restrictions on the
style of the Interface Operation bound.
Table 6-5. Applicability of the serialization formats defined in this section
for this HTTP binding
┌─────────────────────────┬───────────────────────────────────────────────────┐
│ │ Serialization of the instance data in parts of an │
│ │ HTTP message │
│ ├───────┬───────────────────────────────────────────┤
│ - │ │ In the message body │
│ │In the ├─────────────────────┬─────────┬───────────┤
│ │request│ application/ │multipart│application│
│ │ URI │x-www-form-urlencoded│ / │ /xml │
│ │ │ │form-data│ │
├──────────┬──────────────┼───────┼─────────────────────┼─────────┼───────────┤
│ │ Without │ All, │ │ │ │
│ HTTP │message body: │some or│ - │ - │ - │
│ request │GET, DELETE, …│ none │ │ │ │
│ (input ├──────────────┼───────┼─────────────────────┼─────────┼───────────┤
│ message) │ With message │ All, │ │ │ │
│ │ body: POST, │some or│ Remainder │ All │ All │
│ │ PUT, … │ none │ │ │ │
├──────────┴──────────────┼───────┼─────────────────────┼─────────┼───────────┤
│ HTTP response (output │ - │ - │ - │ All │
│ message) │ │ │ │ │
└─────────────────────────┴───────┴─────────────────────┴─────────┴───────────┘
Table 6-6. Operation styles required for using serialization formats defined
below as input serialization
┌──────────┬──────────────────────────────────────────────────────────────────┐
│ │ Request │
│ ├──────────────────────┬───────────────────────────────────────────┤
│ HTTP │ │ Input serialization │
│ Method │ Request URI: query ├─────────────────────┬─────────┬───────────┤
│ │ parameters or path │ application/ │multipart│application│
│ │ components │x-www-form-urlencoded│ / │ /xml │
│ │ │ │form-data│ │
├──────────┼──────────────────────┼─────────────────────┼─────────┼───────────┤
│ Without │ │ │ │ │
│ message │ IRI style │ IRI style │ - │ - │
│body: GET,│ │ │ │ │
│DELETE, … │ │ │ │ │
├──────────┼──────────────────────┼─────────────────────┼─────────┼───────────┤
│ With │IRI style, if any data│ │ │ │
│ message │is serialized as path │ │Multipart│ None │
│ body: │ components or query │ IRI style │ style │ required │
│POST, PUT,│ parameters │ │ │ │
│ … │ │ │ │ │
└──────────┴──────────────────────┴─────────────────────┴─────────┴───────────┘
6.8.1 Serialization of the instance data in parts of the HTTP request IRI
This section defines templating rules for the {http location} property of the
Binding Operation component. Templating is used by the serialization formats
defined in section 6.8 Serialization Format of Instance Data, and MAY be reused
by other serialization formats.
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.
If the {style} property of the Interface Operation bound has a value of "http:/
/www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI Style, and if the {http
location} property of the Binding Operation component is present, the value of
the {http location} property component is used as a template^† which is
combined with the {address} property of the endpoint element to form the full
IRI to be used in an HTTP request, as specified in section 6.5.2 Relationship
to WSDL Component Model.
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 [IETF RFC 3987].
^† Additional rules for the serialization of the HTTP request IRI MAY be
defined by a serialization format.
6.8.1.1 Construction of the request IRI using the {http location} property
The {http location} property MAY cite local names of elements from the instance
data of the message to be serialized in request IRI. Citing is performed:
• either by enclosing the element name within curly braces. For example,
"temperature/{town}". See Example 6-1 for additional details;
• or by enclosing the element name within exclamated-curly braces, to include
the element without percent-encoding. For example, "temperature/{!town}".
Detailed rules follow.
The following EBNF [ISO/IEC 14977:1996] grammar represents the patterns for
constructing the request IRI:
httpLocation ::= charData? (( openBrace | closeBrace | template ) charData?)*
charData ::= [^{}]*
openBrace ::= '{{'
closeBrace ::= '}}'
template ::= rawTemplate | encodedTemplate
rawTemplate ::= '{!' NCName '}'
encodedTemplate ::= '{' NCName '}'
The request IRI is constructed as follows (ALPHA and DIGIT below are defined as
per [IETF RFC 2234]):
• The local name in a template SHOULD match at least one element from the
instance data of the input message.^† When there is no match, the template
is replaced by an empty string. Otherwise, the template consumes the first
non-consumed matching element from the instance data. The next occurrence
of the template consumes the next non-consumed matching element, and so on
until all templates are processed. Matching elements are consumed in the
order in which they appear in the instance data. Cited elements (i.e.
elements referenced in templates) MUST NOT carry an xs:nil attribute whose
value is "true"^†.
• Each raw template (rawTemplate production in the grammar above) is replaced
by the possibly empty single value of the corresponding element from the
instance data. No percent-encoding is performed.
• Each encoded template (encodedTemplate production in the grammar above) NOT
preceded in the {http location} property by a "?" character is replaced by
the possibly empty single value of the corresponding element from the
instance data. Encoding is performed as follows:
□ The characters in the range: "&" | ";" | "!" | "$" | "'" | "(" | ")" |
"*" | "+" | "," | "=" | ":" | "@" SHOULD be percent-encoded.
□ The other characters, EXCEPT the ones in the range: ALPHA | DIGIT | "-"
| "." | "_" | "~", MUST be percent-encoded.
• Each encoded template (encodedTemplate production in the grammar above)
preceded in the {http location} property by a "?" character is replaced by
the possibly empty single value of the corresponding element from the
instance data. Encoding is performed as follows:
□ The value of the {http query parameter separator} property, if present;
otherwise the value of the {http query parameter separator default}
property, MUST be percent-encoded.
□ The characters in the range: "&" | ";" | "!" | "$" | "'" | "(" | ")" |
"*" | "+" | "," | "=" | ":" | "@" | "?" | "/" SHOULD be
percent-encoded.
□ The other characters, EXCEPT the ones in the range: ALPHA | DIGIT | "-"
| "." | "_" | "~", MUST be percent-encoded.
• Each uncited element (i.e. each element not referenced in a template) to be
serialized, if any, is encoded as for an encoded template.
• Percent-encoding MUST be performed using the UTF-8 representation of the
character as prescribed by section 6.4 of [IETF RFC 3987].
• Each double curly brace (openBrace or closeBrace production in the grammar
above) is replaced by a single literal curly brace ("{" or "}"
respectively). This provides a simple escaping mechanism.
Note that the mechanism described in this section could be used to indicate the
entire absolute IRI, including the scheme, host, or port, for example:
{scheme}://{host}:{port}/temperature/{town}
or even:
{!myIRI}
6.8.2 Serialization as "application/x-www-form-urlencoded"
This serialization format is designed to allow a client or Web service to
produce an IRI based on the instance data of a message and serialize a query
string in the HTTP message body as application/x-www-form-urlencoded.
If this format is used then the {style} property of Interface Operation
component being bound MUST contain a value of "http://www.w3.org/ns/wsdl/style/
iri" as defined in 4.2 IRI Style, i.e. this serialization format may only be
used to serialize the HTTP request corresponding to the initial message of an
interface operation.^†
For the HTTP binding defined in this section (6. WSDL HTTP Binding Extension),
"application/x-www-form-urlencoded" MAY be used as a serialization format for
an input message (HTTP Request), but MUST NOT be used as a serialization format
for an output or fault message (HTTP Response).^†
6.8.2.1 Case of elements cited in the {http location} property
In this serialization, the rules for constructing the HTTP request IRI using
elements cited in the {http location} property defined in 6.8.1 Serialization
of the instance data in parts of the HTTP request IRI apply. Additional rules
for constructing the HTTP request IRI follow.
6.8.2.2 Serialization of content of the instance data not cited in the {http
location} property
If not all elements from the instance data are cited in the {http location}
property, or if the property is not present on the Binding Operation component,
then additional serialization rules apply.^†
The remainder of the instance data is formatted as a query string as defined in
6.8.2.2.1 Construction of the query string.
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 6.8.2.2.3
Serialization in the request IRI), otherwise it is serialized in the message
body (see 6.8.2.2.4 Serialization in the message body).
6.8.2.2.1 Construction of the query string
For elements of the instance data not cited in the {http location} property, a
query string is constructed as follows.^†
Non-nil elements with a possibly empty single value of the instance data not
cited are serialized as query parameters in the order they appear in the
instance data.
The instance data MUST NOT contain elements with an xs:nil attribute whose
value is "true".^†
Each parameter pair is separated by the value of the {http query parameter
separator} property, if present, or the value of the {http query parameter
separator default} property.
• Uncited elements with single values (non-list) are serialized as a single
name-value parameter pair. The name of the parameter is the local name of
the uncited element, and the value of the parameter is the value of the
uncited element.
• Uncited elements with list values are serialized as one name-value
parameter pair per-list value. The name of each parameter is the local name
of the uncited element, and the value of each parameter is the
corresponding value in the list. The order of the list values is preserved.
• Replacement values falling outside the range (ALPHA and DIGIT below are
defined as per [IETF RFC 2234]): ALPHA | DIGIT | "-" | "." | "_" | "~" | "!
" | "$" | "&" | "'" | "(" | ")" | "*" | "+" | "," | ";" | "=" | ":" | "@",
MUST be percent-encoded. Percent-encoding MUST be performed using the UTF-8
representation of the character as prescribed by section 6.4 of [IETF RFC
3987].
Example 6-1. Query string generation
The following instance data of an input message:
Fréjus
2007-03-26
C
with the following value of the {http location} property:
'temperature/{town}'
and the following value of the {http query parameter separator default}
property:
'&'
will produce the following query string:
date=2007-03-26&unit=C
6.8.2.2.2 Controlling the serialization of the query string in the request IRI
This serialization format adds the following property to the Binding Operation
component:
• {http location ignore uncited} REQUIRED. A xs:boolean. This boolean
indicates whether elements not cited in the {http location} property MUST
be appended to the request IRI or ignored. If the value of this property is
"false", the rules defined in section 6.8.2.2.3 Serialization in the
request IRI dictate how to serialize elements not cited in {http location}
in the request IRI. Otherwise, those are NOT serialized in the request IRI.
When serializing an HTTP request that does not allow an HTTP message body, and
when {http location ignore uncited} is "true", any element NOT cited in the {
http location} property MUST be defined in the schema as nillable, or have a
default value, or appear no less frequently than specified by the minOccurs
value. The element declaration SHOULD NOT combine a default value with
nillable.^†
The XML representation for this property is an attribute information item with
the following Infoset properties:
• An OPTIONAL ignoreUncited attribute information item with the following
Infoset properties:
□ A [local name] of ignoreUncited
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:boolean
The mapping from the XML representation to component properties is as follows:
Table 6-7. Mapping from XML Representation to Binding Operation component
Extension Properties
┌──────────────────┬──────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────────┼──────────────────────────────────────────────────────────┤
│{http location │The actual value of the whttp:ignoreUncited attribute │
│ignore uncited} │information item, if present; otherwise, "false". │
└──────────────────┴──────────────────────────────────────────────────────────┘
6.8.2.2.3 Serialization in the request IRI
If the HTTP request method used does not allow HTTP message body (e.g. "GET"
and "DELETE"), and if the value of the {http location ignore uncited} property
is "false", then the following rules apply.^†
If the {http location} property is not present, or if it is present and its
value does not contain a "?" (question mark) character, a "?" is appended to
the request IRI. If it does already contain a question mark character, then the
value of the {http query parameter separator} property, if present, or the
value of the {http query parameter separator default} property otherwise, is
appended.
Finally, the query string computed in 6.8.2.2.1 Construction of the query
string is appended.
Example 6-2. Instance data serialized in an IRI
The instance data defined in Example 6-1 with the following operation
declaration:
and the following endpoint declaration:
will serialize the message in the HTTP request as follows:
GET http://ws.example.com/service1/temperature/Fr%C3%A9jus?date=2007-03-26&unit=C HTTP/1.1
Host: ws.example.com
6.8.2.2.4 Serialization in the message body
If the HTTP request method used does allow an HTTP message body (e.g. "POST"
and "PUT"), then the following rules apply.^†
Finally, the query string computed in 6.8.2.2.1 Construction of the query
string is used as the value of the HTTP message body.
The Content-Type HTTP header field must have the value application/
x-www-form-urlencoded.^†
Example 6-3. Instance data serialized in the HTTP Request IRI and message body
The instance data defined in Example 6-1 with the following operation
declaration:
and the following endpoint declaration:
will serialize the message in the HTTP request as follow:
POST http://ws.example.com/service1/temperature/Fr%C3%A9jus HTTP/1.1
Host: ws.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: …
date=2007-03-26&unit=C
6.8.3 Serialization as "application/xml"
In this serialization, for HTTP requests, the rules for constructing the HTTP
request IRI defined in 6.8.1 Serialization of the instance data in parts of the
HTTP request IRI apply if the {style} property of the Interface Operation bound
has a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI
Style.
The instance data of the input, output or fault message is serialized as an XML
document in the message body of the HTTP message, following the serialization
defined in [Canonical XML]. Therefore, it is only suitable for HTTP requests
using methods allowing message bodies (i.e., for the HTTP binding defined in
this specification, input messages where the HTTP method selected has a body),
and for HTTP responses (i.e. output and fault messages for the HTTP binding
defined in this specification).
The Content-Type HTTP header MUST have the value application/xml, or a media
type compatible with application/xml as specified in section 6.4.3.1
Serialization rules for XML messages.^† Other HTTP headers MAY be used.
6.8.4 Serialization as "multipart/form-data"
In this serialization, for HTTP requests, the rules for constructing the HTTP
request IRI defined in 6.8.1 Serialization of the instance data in parts of the
HTTP request IRI apply if the {style} property of the Interface Operation bound
has a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI
Style.
This format is for legacy compatibility to permit the use of XForms clients
with [IETF RFC 2388] servers. This serialization format may only be used when
binding Interface Operation components whose {style} property has a value of
"http://www.w3.org/ns/wsdl/style/multipart" as defined in 4.3 Multipart style,
i.e. this serialization format may only be used to serialize the HTTP request
corresponding to the initial message of an interface operation.^†
Specifically, for the HTTP binding defined in this section (6. WSDL HTTP
Binding Extension), "multipart/form-data" MAY be used as a serialization format
for an input message (HTTP Request), but MUST NOT be used as a serialization
format for an output or fault message (HTTP Response).^† This format serializes
the instance data in the HTTP message body, making it only suitable for HTTP
requests using methods allowing message bodies.
Each element in the sequence is serialized into a part as follow:
1. The Content-Disposition header MUST have the value form-data, and its name
parameter is the local name of the element.^†
2. 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.
3. 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 6.8.3 Serialization as application/xml .
The instance data MUST NOT contain elements with an xs:nil attribute whose
value is "true".^†
Example 6-4. Example of multipart/form-data
The following instance data of an input message:
Fréjus
France
2007-03-26
with the following operation element:
will serialize the message as follow:
Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: xxx
--AaB03x
Content-Disposition: form-data; name="town"
Content-Type: application/xml
Fréjus
France
--AaB03x
Content-Disposition: form-data; name="date"
Content-Type: text/plain; charset=utf-8
2007-03-26
--AaB03x--
6.9 Specifying the Content Encoding
6.9.1 Description
Every Binding Message Reference and Binding Fault component MAY indicate which
content encodings, as defined in section 3.5 of [IETF RFC 2616], are available
for this particular message.
The HTTP binding extension provides a mechanism for indicating a default value
at the Binding component and Binding Operation levels.
If no value is specified, no claim is being made.
6.9.2 Relationship to WSDL Component Model
The HTTP binding extension specification adds the following properties to the
WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {http content encoding default} OPTIONAL. A xs:string to the Binding
component. This property indicates the default content encodings available
for all Binding Message Reference and Binding Fault components of this
Binding.
• {http content encoding default} OPTIONAL. A xs:string to the Binding
Operation component. This property indicates the default content encodings
available for all Binding Message Reference of this Binding Operation.
• {http content encoding} OPTIONAL. A xs:string to the Binding Message
Reference component. This property indicates the content encodings
available for this Binding Message Reference component. If this property
does not have a value, the value of the {http content encoding default}
property of the parent Binding Operation component is used instead. If that
itself has no value, the value from the Binding Operation component's
parent Binding component is used instead.
• Similarly, {http content encoding} OPTIONAL, to the Binding Fault component
These properties are not relevant when HTTP 1.0 is used.
6.9.3 XML Representation
*
The XML representation for specifying the content encoding is an OPTIONAL
attribute information item for the input, output, and fault element information
items with the following Infoset properties:
• A [local name] of contentEncoding
• A [namespace name] of "http://www.w3.org/ns/wsdl/http"
• A type of xs:string
The XML representation for specifying the default content encoding is an
OPTIONAL attribute information item for the binding element information item or
binding's child operation element information items with the following Infoset
properties:
• A [local name] of contentEncodingDefault
• A [namespace name] of "http://www.w3.org/ns/wsdl/http"
• A type of xs:string
6.9.4 Mapping from XML Representation to Component Properties
See Table 6-8.
Table 6-8. Mapping from XML Representation to Interface Message Reference
component Extension Properties
┌───────────────────────────┬─────────────────────────────────────────────────┐
│ Property │ Value │
├───────────────────────────┼─────────────────────────────────────────────────┤
│{http content encoding │The actual value of the │
│default} of the Binding │whttp:contentEncodingDefault attribute │
│component │information item of the binding element │
│ │information item, if present. │
├───────────────────────────┼─────────────────────────────────────────────────┤
│{http content encoding │The actual value of the │
│default} of the Binding │whttp:contentEncodingDefault attribute │
│Operation component │information item of the operation element │
│ │information item, if present. │
├───────────────────────────┼─────────────────────────────────────────────────┤
│{http content encoding} of │The actual value of the whttp:contentEncoding │
│the Binding Message │attribute information item of the input or output│
│Reference component │element information item, if present. │
├───────────────────────────┼─────────────────────────────────────────────────┤
│{http content encoding} of │The actual value of the whttp:contentEncoding │
│the Binding Fault component│attribute information item of the fault element │
│ │information item, if present. │
└───────────────────────────┴─────────────────────────────────────────────────┘
6.10 Specifying the Use of HTTP Cookies
6.10.1 Description
The {http cookies} property allows Binding components to indicate that HTTP
cookies (as defined by [IETF RFC 2965]) are used by specific operations of the
interface that this binding applies to.
6.10.2 Relationship to WSDL Component Model
The HTTP binding extension specification adds the following property to the
WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {http cookies} REQUIRED. A xs:boolean to the Binding component.
6.10.3 XML Representation
The XML representation for specifying the use of HTTP cookies is an OPTIONAL
attribute information item with the following Infoset properties:
• A [local name] of cookies
• A [namespace name] of "http://www.w3.org/ns/wsdl/http"
• A type of xs:boolean
6.10.4 Mapping from XML Representation to Component Properties
See Table 6-9.
Table 6-9. Mapping from XML Representation to Binding component Extension
Properties
┌────────┬────────────────────────────────────────────────────────────────────┐
│Property│ Value │
├────────┼────────────────────────────────────────────────────────────────────┤
│{http │The actual value of the whttp:cookies attribute information item; │
│cookies}│otherwise, "false". A value of "true" means that the service relies │
│ │on cookies and that the client MUST understand them.^† │
└────────┴────────────────────────────────────────────────────────────────────┘
6.11 Specifying HTTP Access Authentication
6.11.1 Description
Every Endpoint component MAY indicate the use of an HTTP access authentication
mechanism (as defined by [IETF RFC 2616]) for the endpoint described.
This binding extension specification allows the authentication scheme and realm
to be specified.
6.11.2 Relationship to WSDL Component Model
The HTTP binding extension specification adds the following property to the
WSDL component model (as defined in [WSDL 2.0 Core Language]):
• {http authentication scheme} OPTIONAL. A xs:token with one of the values
"basic" or "digest", to the Endpoint component, corresponding to the HTTP
authentication scheme used. When present, this property indicates the
authentication scheme in use: "basic" indicates the Basic Access
Authentication scheme defined in [IETF RFC 2617], and "digest" indicates
the Digest Access Authentication scheme as defined in [IETF RFC 2617].
• {http authentication realm} OPTIONAL. A xs:string to the Endpoint
component. It corresponds to the realm authentication parameter defined in
[IETF RFC 2617]. If the {http authentication scheme} property is present,
then this property MUST be present.^†
6.11.3 XML Representation
whttp:authenticationScheme="xs:token"?
whttp:authenticationRealm="xs:string"? />
The XML representation for specifying the use of HTTP access authentication is
two OPTIONAL attribute information items with the following Infoset properties:
• An OPTIONAL authenticationScheme attribute information item with the
following Infoset properties:
□ A [local name] of authenticationScheme
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:token where the allowed token values are "basic" and
"digest".
• An OPTIONAL authenticationRealm attribute information item with the
following Infoset properties:
□ A [local name] of authenticationRealm
□ A [namespace name] of "http://www.w3.org/ns/wsdl/http"
□ A type of xs:string
6.11.4 Mapping from XML Representation to Component Properties
See Table 6-10.
Table 6-10. Mapping from XML Representation to Endpoint component Extension
Properties
┌──────────────┬──────────────────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{http │The actual value of the whttp:authenticationScheme attribute │
│authentication│information item, if present. │
│scheme} │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│{http │The actual value of the whttp:authenticationRealm attribute │
│authentication│information item, if present; otherwise, if the │
│realm} │whttp:authenticationScheme attribute information item is │
│ │present, "" (the empty value). │
└──────────────┴──────────────────────────────────────────────────────────────┘
6.12 Conformance
An element information item, whose namespace name is "http://www.w3.org/ns/
wsdl" and whose local part is description, conforms to this binding extension
specification if: the element information items and attribute information item
s, whose namespace is http://www.w3.org/ns/wsdl/http, conform to the XML Schema
for that element or attribute, as defined by this specification and,
additionally, adheres to all the constraints contained in this specification.
7. References
7.1 Normative References
[ISO/IEC 14977:1996]
Extended BNF, IS0 (the International Organization for Standardization) and
IEC (the International Electrotechnical Commission), Dec 1996. Available at
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/
PubliclyAvailableStandards.htm.
[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
Author. Internet Engineering Task Force, June 1999. Available at http://
www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 2234]
Augmented BNF for Syntax Specifications: ABNF, D. Crocker, P. Overell,
Authors. Internet Engineering Task Force, November 1997. Available at http:
//www.ietf.org/rfc/rfc2234.txt.
[IETF RFC 2388]
Returning Values from Forms: multipart/form-data, L. Masinter, Author.
Internet Engineering Task Force, August 1998. Available at http://
www.ietf.org/rfc/rfc2388.txt.
[IETF RFC 2616]
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Authors. Internet
Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/
rfc2616.txt.
[IETF RFC 2617]
HTTP Authentication: Basic and Digest Access Authentication, J. Franks, P.
Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart,
June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.
[IETF RFC 2818]
HTTP Over TLS, E. Rescorla, Author. Internet Engineering Task Force, May
2000. Available at http://www.ietf.org/rfc/rfc2818.txt.
[IETF RFC 2965]
HTTP State Management Mechanism, D. Kristol, L. Montulli Authors. Internet
Engineering Task Force, October 2000. Available at http://www.ietf.org/rfc/
rfc2965.txt.
[IETF RFC 3023]
XML Media Types, M. Murata, S. St. Laurent, D. Kohn, Authors. Internet
Engineering Task Force, January 2001. Available at http://www.ietf.org/rfc/
rfc3023.txt.
[IETF RFC 3205]
On the use of HTTP as a Substrate, K. Moore, Authors. Internet Engineering
Task Force, February 2002. Available at http://www.ietf.org/rfc/
rfc3205.txt.
[IETF RFC 3986]
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R.
Fielding, L. Masinter, Authors. Internet Engineering Task Force, January
2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 3987]
Internationalized Resource Identifiers (IRIs), M. Duerst, M. Suignard,
Authors. Internet Engineering Task Force, January 2005. Available at http:/
/www.ietf.org/rfc/rfc3987.txt.
[Web Architecture]
Architecture of the World Wide Web, Volume One, I. Jacobs, and N. Walsh,
Editors. World Wide Web Consortium, 15 December 2004. This version of the
"Architecture of the World Wide Web, Volume One" Recommendation is http://
www.w3.org/TR/2004/REC-webarch-20041215/. The latest version of
"Architecture of the World Wide Web, Volume One" is available at http://
www.w3.org/TR/webarch/.
[Web Services Architecture]
Web Services Architecture, David Booth, Hugo Haas, Francis McCabe, Eric
Newcomer, Michael Champion, Chris Ferris, David Orchard, Editors. World
Wide Web Consortium, 11 February 2004. This version of the "Web Services
Architecture" Working Group Note is http://www.w3.org/TR/2004/
NOTE-ws-arch-20040211/. The latest version of "Web Services Architecture"
is available at http://www.w3.org/TR/ws-arch/.
[WSDL 2.0 Core Language]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language,
R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide
Web Consortium, 26 March 2007. This version of the "Web Services
Description Language (WSDL) Version 2.0 Part 1: Core Language"
Specification is available is available at http://www.w3.org/TR/2007/
WD-wsdl20-20070326. The latest version of "Web Services Description
Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://
www.w3.org/TR/wsdl20.
[SOAP 1.2 Part 1: Messaging Framework (Second Edition)]
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), M. Gudgin,
M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, A. Karmarkar, Y.
Lafon, Editors. World Wide Web Consortium, 19 December 2006. This version
of the "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)"
Proposed Edited Recommendation is http://www.w3.org/TR/2006/
PER-soap12-part1-20061219/. The latest version of "SOAP Version 1.2 Part 1:
Messaging Framework" is available at http://www.w3.org/TR/soap12-part1/.
[SOAP 1.2 Part 2: Adjuncts (Second Edition)]
SOAP Version 1.2 Part 2: Adjuncts (Second Edition), M. Gudgin, M. Hadley,
N. Mendelsohn, J-J. Moreau, and H. Frystyk Nielsen, A. Karmarkar, Y. Lafon,
Editors. World Wide Web Consortium, 7 May 2003. This version of the "SOAP
Version 1.2 Part 2: Adjuncts (Second Edition)" Proposed Edited
Recommendation is http://www.w3.org/TR/2006/PER-soap12-part2-20061219/. The
latest version of "SOAP Version 1.2 Part 2: Adjuncts" is available at http:
//www.w3.org/TR/soap12-part2/.
[XML 1.0]
Extensible Markup Language (XML) 1.0 (Third Edition), T. Bray, J. Paoli, C.
M. Sperberg-McQueen, E. Maler, and F. Yergeau, Editors. World Wide Web
Consortium, 4 February 2004. This version of the XML 1.0 Recommendation is
http://www.w3.org/TR/2004/REC-xml-20040204/. The latest version of
"Extensible Markup Language (XML) 1.0" is available at http://www.w3.org/TR
/REC-xml.
[Canonical XML]
Canonical XML, J. Boyer, Author. World Wide Web Consortium, 15 March 2001.
This version of the Canonical XML Recommendation is http://www.w3.org/TR/
2001/REC-xml-c14n-20010315. The latest version of Canonical XML is
available at http://www.w3.org/TR/xml-c14n.
[XML Information Set]
XML Information Set (Second Edition), J. Cowan and R. Tobin, Editors. World
Wide Web Consortium, 4 February 2004. This version of the XML Information
Set Recommendation is http://www.w3.org/TR/2004/REC-xml-infoset-20040204.
The latest version of XML Information Set is available at http://www.w3.org
/TR/xml-infoset.
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M.
Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 28 October
2004. This version of the XML Schema Part 1 Recommendation is http://
www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML
Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra,
Editors. World Wide Web Consortium, 28 October 2004. This version of the
XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/
REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is
available at http://www.w3.org/TR/xmlschema-2.
[XForms 1.0]
XForms 1.0, M. Dubinko, et al., Editors. World Wide Web Consortium, 14
October 2003. This version of the XForms 1.0 Recommendation is http://
www.w3.org/TR/2003/REC-xforms-20031014/. The latest version of XForms 1.0
is available at http://www.w3.org/TR/xforms/.
7.2 Informative References
[WSA 1.0 Core]
Web Services Addressing 1.0 - Core , M. Gudgin, M. Hadley, Editors. World
Wide Web Consortium, 17 August 2005. This version of Web Services
Addressing 1.0 - Core is http://www.w3.org/TR/2005/CR-ws-addr-core-20050817
/ The latest version of the "Web Services Addressing 1.0 - Core" document
is available from http://www.w3.org/TR/ws-addr-core.
[WSDL 2.0 Primer]
Web Services Description Language (WSDL) Version 2.0 Part 0: Primer ,
D.Booth, C.K. Liu , Editors. World Wide Web Consortium, 26 March 2007. This
version of the "Web Services Description Language (WSDL) Version 2.0 Part
0: Primer" Specification is available at http://www.w3.org/TR/2007/
WD-wsdl20-primer-20070326. The latest version of "Web Services Description
Language (WSDL) Version 2.0 Part 0: Primer" is available at http://
www.w3.org/TR/wsdl20-primer.
[WSDL 2.0 Additional MEPs]
Web Services Description Language (WSDL) Version 2.0: Additional MEPs, A.
Lewis, Editors. World Wide Web Consortium, 26 March 2007. This version of
the "Web Services Description Language (WSDL) Version 2.0: Additional MEPs"
Specification is available is available at http://www.w3.org/TR/2007/
WD-wsdl20-additional-meps-20070326. The latest version of "Web Services
Description Language (WSDL) Version 2.0: Additional MEPs" is available at
http://www.w3.org/TR/wsdl20-additional-meps.
[SOAP Message Transmission Optimization Mechanism]
SOAP Message Transmission Optimization Mechanism, N. Mendelsohn, M.
Nottingham, and H. Ruellan, Editors. World Wide Web Consortium, W3C
Recommendation, 25 January 2005. This version of SOAP Message Transmission
Optimization Mechanism is http://www.w3.org/TR/2005/
REC-soap12-mtom-20050125/. The latest version of the "SOAP Message
Transmission Optimization Mechanism" document is available from http://
www.w3.org/TR/soap12-mtom/.
A. Acknowledgements (Non-Normative)
This document is the work of the W3C Web Service Description Working Group.
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), 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), Rebecca Bergersen (IONA Technologies), Ugo
Corda (SeeBeyond).
The people who have contributed to discussions on www-ws-desc@w3.org are also
gratefully acknowledged.
B. Component Summary (Non-Normative)
Table B-1 lists all the components in the WSDL 2.0 Adjuncts abstract Component
Model, and all their properties.
Table B-1. Summary of WSDL 2.0 Adjuncts Components and their Properties
┌──────────────┬──────────────────────────────────────────────────────────────┐
│ Component │ Defined Properties │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ │{http content encoding default}, {http cookies}, {http method │
│Binding │default}, {http query parameter separator default}, {soap mep │
│ │default}, {soap modules}, {soap underlying protocol}, {soap │
│ │version} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ │{http content encoding}, {http error status code}, {http │
│Binding Fault │headers}, {soap fault code}, {soap fault subcodes}, {soap │
│ │headers}, {soap modules} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│Binding Fault │{soap modules} │
│Reference │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│Binding │{http content encoding}, {http headers}, {soap headers}, {soap│
│Message │modules} │
│Reference │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ │{http content encoding default}, {http fault serialization}, {│
│Binding │http input serialization}, {http location}, {http location │
│Operation │ignore uncited}, {http method}, {http output serialization}, {│
│ │http query parameter separator}, {soap action}, {soap mep}, { │
│ │soap modules} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│Endpoint │{http authentication realm}, {http authentication scheme} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│HTTP Header │{name}, {parent}, {required}, {type definition} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│Interface │{rpc signature}, {safe} │
│Operation │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│SOAP Header │{element declaration}, {mustUnderstand}, {parent}, {required} │
│Block │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│SOAP Module │{parent}, {ref}, {required} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ Property │ Where Defined │
├──────────────┼──────────────────────────────────────────────────────────────┤
│element │SOAP Header Block.{element declaration} │
│declaration │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http │ │
│authentication│Endpoint.{http authentication realm} │
│realm │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http │ │
│authentication│Endpoint.{http authentication scheme} │
│scheme │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http content │Binding Fault.{http content encoding}, Binding Message │
│encoding │Reference.{http content encoding} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http content │Binding.{http content encoding default}, Binding Operation.{ │
│encoding │http content encoding default} │
│default │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http cookies │Binding.{http cookies} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http error │Binding Fault.{http error status code} │
│status code │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http fault │Binding Operation.{http fault serialization} │
│serialization │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http headers │Binding Fault.{http headers}, Binding Message Reference.{http │
│ │headers} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http input │Binding Operation.{http input serialization} │
│serialization │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http location │Binding Operation.{http location} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http location │Binding Operation.{http location ignore uncited} │
│ignore uncited│ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http method │Binding Operation.{http method} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http method │Binding.{http method default} │
│default │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http output │Binding Operation.{http output serialization} │
│serialization │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http query │ │
│parameter │Binding Operation.{http query parameter separator} │
│separator │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│http query │ │
│parameter │Binding.{http query parameter separator default} │
│separator │ │
│default │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│mustUnderstand│SOAP Header Block.{mustUnderstand} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│name │HTTP Header.{name} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│parent │HTTP Header.{parent}, SOAP Header Block.{parent}, SOAP Module.│
│ │{parent} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ref │SOAP Module.{ref} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│required │HTTP Header.{required}, SOAP Header Block.{required}, SOAP │
│ │Module.{required} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│rpc signature │Interface Operation.{rpc signature} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│safe │Interface Operation.{safe} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap action │Binding Operation.{soap action} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap fault │Binding Fault.{soap fault code} │
│code │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap fault │Binding Fault.{soap fault subcodes} │
│subcodes │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap headers │Binding Fault.{soap headers}, Binding Message Reference.{soap │
│ │headers} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap mep │Binding Operation.{soap mep} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap mep │Binding.{soap mep default} │
│default │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ │Binding.{soap modules}, Binding Fault.{soap modules}, Binding │
│soap modules │Fault Reference.{soap modules}, Binding Message Reference.{ │
│ │soap modules}, Binding Operation.{soap modules} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap │ │
│underlying │Binding.{soap underlying protocol} │
│protocol │ │
├──────────────┼──────────────────────────────────────────────────────────────┤
│soap version │Binding.{soap version} │
├──────────────┼──────────────────────────────────────────────────────────────┤
│type │HTTP Header.{type definition} │
│definition │ │
└──────────────┴──────────────────────────────────────────────────────────────┘
C. Assertion Summary (Non-Normative)
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.
Table C-1. Summary of Assertions about WSDL 2.0 Documents
┌────────────────────┬────────────────────────────────────────────────────────┐
│ Id │ Assertion │
├────────────────────┼────────────────────────────────────────────────────────┤
│OperationSafety-2028│An OPTIONAL safe attribute information item with the │
│ │following Infoset properties: │
├────────────────────┼────────────────────────────────────────────────────────┤
│ │Additionally, each even-numbered item (0, 2, 4, ...) in │
│WRPC-2050 │the list MUST be of type xs:QName and each odd-numbered │
│ │item (1, 3, 5, ...) in the list MUST be of the subtype │
│ │of xs:token described in the previous paragraph. │
└────────────────────┴────────────────────────────────────────────────────────┘
Table C-2. Summary of Assertions about WSDL 2.0 Components
┌─────────────────────────────────┬───────────────────────────────────────────┐
│ Id │ Assertion │
├─────────────────────────────────┼───────────────────────────────────────────┤
│FaultPropagationModification-2005│However, extensions or binding extensions │
│ │MAY modify these rulesets. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the {http authentication scheme} │
│HTTPAccessAuthentication-2127 │property is present, then this property │
│ │MUST be present. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the HTTP message to be │
│HTTPBinding-2083 │transmitted, the HTTP request method used │
│ │MUST be selected using one of the │
│ │following: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the HTTP message to be │
│HTTPBinding-2084 │transmitted, content encoding for a given │
│ │Binding Message Reference component is │
│ │determined as follows: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the HTTP fault message to │
│HTTPBinding-2085 │be transmitted, content encoding for a │
│ │given Binding Fault component is determined│
│ │as follows: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the HTTP message to be │
│ │transmitted, the contents of the payload │
│ │(i.e. the contents of the HTTP message │
│HTTPBinding-2086 │body) MUST be what is defined by the │
│ │corresponding Interface Message Reference │
│ │or Interface Fault components, serialized │
│ │as specified by the serialization format │
│ │used. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the value is "#none", then the payload │
│ │MUST be empty and the value of the │
│HTTPBinding-2087 │corresponding serialization property ({http│
│ │input serialization} or {http output │
│ │serialization}) is ignored. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the Interface Message Reference │
│ │component or the Interface Fault component │
│ │is declared using a non-XML type system (as│
│ │considered in the Types section of [WSDL │
│HTTPBinding-2088 │2.0 Core Language]), then additional │
│ │binding rules MUST be defined in an │
│ │extension specification to indicate how to │
│ │map those components into the HTTP │
│ │envelope. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The serialization rules for messages whose │
│HTTPBinding-2089 │{message content model} is either "# │
│ │element" or "#any", AND the serialization │
│ │rules for fault messages, are as follows: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The fault definition SHOULD agree with the │
│HTTPBindingFault-2105 │definition of the HTTP error codes, as │
│ │specified in section 8 of [IETF RFC 3205]. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │An integer value of this property │
│HTTPBindingFault-2106 │identifies the error Status-Code as defined│
│ │by [IETF RFC 2616] that the service will │
│ │use in case the fault is returned. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the HTTP Request, the HTTP│
│ │Request IRI is an absolute IRI reference │
│ │and is the value of the {http location} │
│HTTPBindingOperation-2093 │property of the Binding Operation │
│ │component, resolved using the value of the │
│ │{address} property of the Endpoint │
│ │component (see section 5 of [IETF RFC 3986 │
│ │]). │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The first one is transmitted using an HTTP │
│HTTPBindingOperation-2094 │request, and the second one is transmitted │
│ │using the corresponding HTTP response. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │In cases where only one single message is │
│HTTPBindingOperation-2095 │being sent, the message body of the HTTP │
│ │response MUST be empty. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │It MUST contain an IRI reference and MUST │
│HTTPBindingOperation-2098 │NOT include a fragment identifier │
│ │component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The value of the serialization format used │
│HTTPBindingOperation-2100 │for a message is a media type which MUST be│
│ │covered by this range. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │Wild cards (for example, "application/*") │
│HTTPBindingOperation-2101 │SHOULD NOT be used in this attribute │
│ │information item since they may lead to │
│ │interoperability problems. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │A value of "true" means that the service │
│HTTPCookies-2126 │relies on cookies and that the client MUST │
│ │understand them. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the {http headers} property as defined │
│ │in section 6.6 Declaring HTTP Headers │
│ │exists and is not empty in a Binding │
│HTTPHeader-2090 │Message Reference or Binding Fault │
│ │component, HTTP headers conforming to each │
│ │HTTP Header component contained in this { │
│ │http headers} property MAY be serialized as│
│ │follows: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The HTTP binding MUST NOT set an HTTP │
│ │header field corresponding to the value of │
│HTTPHeader-2091 │the {name} property already set by another │
│ │mechanism, such as the HTTP stack or │
│ │another feature. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the value of an HTTP Header component's │
│HTTPHeader-2092 │{required} property is "true", the │
│ │inclusion of this HTTP header field is │
│ │REQUIRED │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │A Binding Message Reference or a Binding │
│HTTPHeader-2102 │Fault component's {http headers} property │
│ │MUST NOT contain multiple HTTP Header │
│ │components with the same {name} property. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│HTTPHeader-2103 │This type MUST be a simple type. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the value is "true", then the HTTP │
│HTTPHeader-2104 │header field MUST be included in the │
│ │message. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The instance data MUST NOT contain elements│
│HTTPQueryString-2115 │with an xs:nil attribute whose value is │
│ │"true". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When serializing an HTTP request that does │
│ │not allow an HTTP message body, and when { │
│ │http location ignore uncited} is "true", │
│ │any element NOT cited in the {http location│
│HTTPQueryString-2116 │} property MUST be defined in the schema as│
│ │nillable, or have a default value, or │
│ │appear no less frequently than specified by│
│ │the minOccurs value. The element │
│ │declaration SHOULD NOT combine a default │
│ │value with nillable. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The value of the {http input serialization │
│ │}, {http output serialization} and {http │
│ │fault serialization} properties is similar │
│ │to the value allowed for the Accept HTTP │
│HTTPSerialization-2099 │header defined by the HTTP 1.1 │
│ │specification, Section 14.1 (see [IETF RFC │
│ │2616]) and MUST follow the production rules│
│ │defined in that section except for the │
│ │following: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the {style} property of the Interface │
│ │Operation bound has a value of "http:// │
│ │www.w3.org/ns/wsdl/style/iri" as defined in│
│HTTPSerialization-2107 │4.2 IRI Style, and if the {http location} │
│ │property of the Binding Operation component│
│ │is present, the value of the {http location│
│ │} property component is used as a template │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The resulting IRI MUST be mapped to an URI │
│HTTPSerialization-2108 │for use in the HTTP Request as per section │
│ │3.1 "Mapping of IRIs to URIs" of the IRI │
│ │specification [IETF RFC 3987]. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The local name in a template SHOULD match │
│HTTPSerialization-2109 │at least one element from the instance data│
│ │of the input message. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If this format is used then the {style} │
│ │property of Interface Operation component │
│ │being bound MUST contain a value of "http:/│
│HTTPSerialization-2111 │/www.w3.org/ns/wsdl/style/iri" as defined │
│ │in 4.2 IRI Style, i.e. this serialization │
│ │format may only be used to serialize the │
│ │HTTP request corresponding to the initial │
│ │message of an interface operation. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For the HTTP binding defined in this │
│ │section (6. WSDL HTTP Binding Extension), │
│ │"application/x-www-form-urlencoded" MAY be │
│HTTPSerialization-2112 │used as a serialization format for an input│
│ │message (HTTP Request), but MUST NOT be │
│ │used as a serialization format for an │
│ │output or fault message (HTTP Response). │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If not all elements from the instance data │
│ │are cited in the {http location} property, │
│HTTPSerialization-2113 │or if the property is not present on the │
│ │Binding Operation component, then │
│ │additional serialization rules apply. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For elements of the instance data not cited│
│HTTPSerialization-2114 │in the {http location} property, a query │
│ │string is constructed as follows. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the HTTP request method used does not │
│ │allow HTTP message body (e.g. "GET" and │
│HTTPSerialization-2117 │"DELETE"), and if the value of the {http │
│ │location ignore uncited} property is │
│ │"false", then the following rules apply. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the HTTP request method used does allow │
│HTTPSerialization-2118 │an HTTP message body (e.g. "POST" and │
│ │"PUT"), then the following rules apply. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The Content-Type HTTP header field must │
│HTTPSerialization-2119 │have the value application/ │
│ │x-www-form-urlencoded. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The Content-Type HTTP header MUST have the │
│ │value application/xml, or a media type │
│HTTPSerialization-2120 │compatible with application/xml as │
│ │specified in section 6.4.3.1 Serialization │
│ │rules for XML messages. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │this serialization format may only be used │
│HTTPSerialization-2121 │to serialize the HTTP request corresponding│
│ │to the initial message of an interface │
│ │operation. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │Specifically, for the HTTP binding defined │
│ │in this section (6. WSDL HTTP Binding │
│ │Extension), "multipart/form-data" MAY be │
│HTTPSerialization-2122 │used as a serialization format for an input│
│ │message (HTTP Request), but MUST NOT be │
│ │used as a serialization format for an │
│ │output or fault message (HTTP Response). │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The Content-Disposition header MUST have │
│HTTPSerialization-2123 │the value form-data, and its name parameter│
│ │is the local name of the element. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│HTTPSerialization-2124 │The Content-Type header MUST have the │
│ │value: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The instance data MUST NOT contain elements│
│HTTPSerialization-2125 │with an xs:nil attribute whose value is │
│ │"true". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│InOnlyComposition-2012 │The in-only message exchange pattern │
│ │consists of exactly one message as follows:│
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The in-out message exchange pattern │
│InOutComposition-2015 │consists of exactly two messages, in order,│
│ │as follows: │
├─────────────────────────────────┼───────────────────────────────────────────┤
│InterfaceOperation-2096 │202 when the MEP is "http://www.w3.org/ns/ │
│ │wsdl/in-only" │
├─────────────────────────────────┼───────────────────────────────────────────┤
│InterfaceOperation-2097 │204 when the MEP is "http://www.w3.org/ns/ │
│ │wsdl/robust-in-only" │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When using this style, the value of the { │
│ │message content model} property of the │
│IRIStyle-2051 │Interface Message Reference component │
│ │corresponding to the initial message of the│
│ │message exchange pattern MUST be "# │
│ │element". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│IRIStyle-2052 │The sequence MUST only contain elements. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│IRIStyle-2053 │The sequence MUST contain only local │
│ │element children. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The localPart of the element's QName MUST │
│IRIStyle-2054 │be the same as the Interface Operation │
│ │component's {name}. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The complex type that defines the body of │
│IRIStyle-2055 │the element or its children elements MUST │
│ │NOT contain any attributes. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The children elements of the sequence MUST │
│ │derive from xs:simpleType, and MUST NOT be │
│IRIStyle-2056 │of the type or derive from xs:QName, │
│ │xs:NOTATION, xs:hexBinary or │
│ │xs:base64Binary. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When using this style, the value of the { │
│ │message content model} property of the │
│MultipartStyle-2057 │Interface Message Reference component │
│ │corresponding to the initial message of the│
│ │message exchange pattern MUST be "# │
│ │element". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│MultipartStyle-2058 │The sequence MUST only contain elements. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│MultipartStyle-2059 │The sequence MUST contain only local │
│ │element children. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│MultipartStyle-2060 │The attributes minOccurs and maxOccurs for │
│ │these child elements MUST have a value 1. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The localPart of the element's QName MUST │
│MultipartStyle-2061 │be the same as the Interface Operation │
│ │component's {name}. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The complex type that defines the body of │
│MultipartStyle-2062 │the element or its children elements MUST │
│ │NOT contain any attributes. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The sequence MUST NOT contain multiple │
│MultipartStyle-2063 │children element declared with the same │
│ │local name. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │However, an operation SHOULD be marked safe│
│OperationSafety-2027 │if it meets the criteria for a safe │
│ │interaction defined in Section 3.4 of [Web │
│ │Architecture]. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RobustInOnlyComposition-2013 │The robust-in-only message exchange pattern│
│ │consists of exactly one message as follows:│
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the RPC style is used by an Interface │
│ │Operation component then its {message │
│RPCStyle-2029 │exchange pattern} property MUST have the │
│ │value either "http://www.w3.org/ns/wsdl/ │
│ │in-only" or "http://www.w3.org/ns/wsdl/ │
│ │in-out". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The value of the {message content model} │
│ │property for the Interface Message │
│RPCStyle-2030 │Reference components of the {interface │
│ │message references} property MUST be "# │
│ │element". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The content model of input and output { │
│RPCStyle-2031 │element declaration} elements MUST be │
│ │defined using a complex type that contains │
│ │a sequence from XML Schema. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2032 │The input sequence MUST only contain │
│ │elements and element wildcards. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2033 │The input sequence MUST NOT contain more │
│ │than one element wildcard. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2034 │The element wildcard, if present, MUST │
│ │appear after any elements. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2035 │The output sequence MUST only contain │
│ │elements. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2036 │Both the input and output sequences MUST │
│ │contain only local element children. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The local name of input element's QName │
│RPCStyle-2037 │MUST be the same as the Interface Operation│
│ │component's name. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│RPCStyle-2038 │Input and output elements MUST both be in │
│ │the same namespace. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The complex type that defines the body of │
│RPCStyle-2039 │an input or an output element MUST NOT │
│ │contain any local attributes. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If elements with the same qualified name │
│RPCStyle-2040 │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 │
│RPCStyle-2041 │contain multiple children elements declared│
│ │with the same name. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │A xs:anyURI, which is an absolute IRI as │
│SOAPAction-2075 │defined by [IETF RFC 3987], to the Binding │
│ │Operation component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When formulating the SOAP envelope to be │
│ │transmitted, the contents of the payload │
│ │(i.e., the contents of the SOAP Body │
│SOAPBinding-2065 │element information item of the SOAP │
│ │envelope) MUST be what is defined by the │
│ │corresponding Interface Message Reference │
│ │component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the Interface Message Reference │
│ │component is declared using a non-XML type │
│ │system (as considered in the Types section │
│SOAPBinding-2068 │of [WSDL 2.0 Core Language]), then │
│ │additional binding rules MUST be defined to│
│ │indicate how to map those components into │
│ │the SOAP envelope. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │Every SOAP binding MUST indicate what │
│SOAPBinding-2069 │version of SOAP is in use for the │
│ │operations of the interface that this │
│ │binding applies to. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│SOAPBinding-2070 │Every SOAP binding MUST indicate what │
│ │underlying protocol is in use. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For every Interface Fault component │
│SOAPBindingFault-2071 │contained in an Interface component, a │
│ │mapping to a SOAP Fault MUST be described. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │when the value of the {soap version} is │
│SOAPBindingFault-2072 │"1.2", the allowed QNames MUST be the ones │
│ │defined by [SOAP 1.2 Part 1: Messaging │
│ │Framework (Second Edition)], section 5.4.6 │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │When its value is "true", the SOAP header │
│ │block MUST be decorated with a SOAP │
│ │mustUnderstand attribute information item │
│SOAPHeaderBlock-2077 │with a value of "true"; if so, the XML │
│ │element declaration referenced by the { │
│ │element declaration} property MUST allow │
│ │this SOAP mustUnderstand attribute │
│ │information item. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │If the value is "true", then the SOAP │
│SOAPHeaderBlock-2078 │header block MUST be included in the │
│ │message. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │The value of the element attribute │
│ │information item MUST resolve to a global │
│SOAPHeaderBlock-2079 │element declaration from the {element │
│ │declarations} property of the Description │
│ │component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│SOAPHTTPProperties-2064 │These properties MUST NOT be used unless │
│ │the underlying protocol is HTTP. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │This default binding rule is applicable │
│ │when the value of the {soap underlying │
│ │protocol} property of the Binding component│
│ │is "http://www.w3.org/2003/05/soap/bindings│
│ │/HTTP/". If the SOAP MEP selected as │
│SOAPHTTPSelection-2082 │specified above has the value "http:// │
│ │www.w3.org/2003/05/soap/mep/ │
│ │request-response/" then the HTTP method │
│ │used is "POST". If the SOAP MEP selected │
│ │has the value "http://www.w3.org/2003/05/ │
│ │soap/mep/soap-response/" then the HTTP │
│ │method used is "GET". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │A xs:anyURI, which is an absolute IRI as │
│SOAPMEP-2074 │defined by [IETF RFC 3987], to the Binding │
│ │Operation component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │A xs:anyURI, which is an absolute IRI as │
│SOAPMEPDefault-2073 │defined by [IETF RFC 3987], to the Binding │
│ │component. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For a given Interface Operation component, │
│ │if there is a Binding Operation component │
│ │whose {interface operation} property │
│ │matches the component in question and its {│
│ │soap mep} property has a value, then the │
│ │SOAP MEP is the value of the {soap mep} │
│ │property. Otherwise, the SOAP MEP is the │
│ │value of the Binding component's {soap mep │
│SOAPMEPSelection-2080 │default}, if any. Otherwise, the Interface │
│ │Operation component's {message exchange │
│ │pattern} property MUST have the value │
│ │"http://www.w3.org/ns/wsdl/in-out", and the│
│ │SOAP MEP is the URI "http://www.w3.org/2003│
│ │/05/soap/mep/request-response/" identifying│
│ │the SOAP Request-Response Message Exchange │
│ │Pattern as defined in [SOAP 1.2 Part 2: │
│ │Adjuncts (Second Edition)]. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│SOAPModule-2076 │A xs:anyURI, which is an absolute IRI as │
│ │defined by [IETF RFC 3987]. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│WRPC-2042 │OPTIONAL, but MUST be present when the │
│ │style is RPC │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │Values for the second component MUST be │
│WRPC-2043 │chosen among the following four: "#in", "# │
│ │out", "#inout" "#return". │
├─────────────────────────────────┼───────────────────────────────────────────┤
│WRPC-2044 │The value of the first component of each │
│ │pair (q, t) MUST be unique within the list.│
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For each child element of the input and │
│ │output messages of the operation, a pair │
│ │(q, t), whose first component q is equal to│
│WRPC-2045 │the qualified name of that element, MUST be│
│ │present in the list, with the caveat that │
│ │elements that appear with cardinality │
│ │greater than one MUST be treated as a │
│ │single element. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For each pair (q, #in), there MUST be a │
│ │child element of the input element with a │
│WRPC-2046 │name of q. There MUST NOT be a child │
│ │element of the output element with the name│
│ │of q. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For each pair (q, #out), there MUST be a │
│ │child element of the output element with a │
│WRPC-2047 │name of q. There MUST NOT be a child │
│ │element of the input element with the name │
│ │of q. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For each pair (q, #inout), there MUST be a │
│ │child element of the input element with a │
│WRPC-2048 │name of q. There MUST also be a child │
│ │element of the output element with the name│
│ │of q. │
├─────────────────────────────────┼───────────────────────────────────────────┤
│ │For each pair (q, #return), there MUST be a│
│ │child element of the output element with a │
│WRPC-2049 │name of q. There MUST NOT be a child │
│ │element of the input element with the name │
│ │of q. │
└─────────────────────────────────┴───────────────────────────────────────────┘
Table C-3. Summary of Assertions about Messages
┌─────────────────────────────┬───────────────────────────────────────────────┐
│ Id │ Assertion │
├─────────────────────────────┼───────────────────────────────────────────────┤
│ │Cited elements (i.e. elements referenced in │
│HTTPSerialization-2110 │templates) MUST NOT carry an xs:nil attribute │
│ │whose value is "true" │
├─────────────────────────────┼───────────────────────────────────────────────┤
│ │If any, the value of the SOAP "Detail" element │
│SOAP12Binding-SOAPDetail-2081│MUST be the element information item identified│
│ │by the {element declaration} property of the │
│ │Interface Fault component. │
├─────────────────────────────┼───────────────────────────────────────────────┤
│SOAPBinding-2066 │If the value is "#none", then the payload MUST │
│ │be empty. │
├─────────────────────────────┼───────────────────────────────────────────────┤
│ │If the value is "#element", then the payload │
│SOAPBinding-2067 │MUST be the element information item identified│
│ │by the {element declaration} property of the │
│ │Interface Message Reference component. │
└─────────────────────────────┴───────────────────────────────────────────────┘
Table C-4. Summary of Assertions about Message Exchanges
┌─────────────────────────┬───────────────────────────────────────────────────┐
│ Id │ Assertion │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │The fault message MUST be delivered to the same │
│ │target node as the message it replaces, unless │
│FaultDelivery-2008 │otherwise specified by an extension or binding │
│ │extension. If there is no path to this node, the │
│ │fault MUST be discarded. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │The fault message MUST be delivered to the │
│ │originator of the triggering message, unless │
│ │otherwise specified by an extension or binding │
│FaultDelivery-2010 │extension. Any node MAY propagate a fault message, │
│ │and MUST NOT do so more than once for each │
│ │triggering message. If there is no path to the │
│ │originator, the fault MUST be discarded. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │Nodes that generate faults MUST attempt to │
│ │propagate the faults in accordance with the │
│FaultPropagation-2003 │governing ruleset, but it is understood that any │
│ │delivery of a network message is best effort, not │
│ │guaranteed. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │When a fault is generated, the generating node MUST│
│FaultPropagation-2004 │attempt to propagate the fault, and MUST do so in │
│ │the direction and to the recipient specified by the│
│ │ruleset. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │When the Fault Replaces Message propagation rule is│
│FaultReplacesMessage-2007│in effect, any message after the first in the │
│ │pattern MAY be replaced with a fault message, which│
│ │MUST have identical direction. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│InOnlyFaults-2013 │The in-only message exchange pattern uses the rule │
│ │2.2.3 No Faults propagation rule. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│InOutFaults-2016 │The in-out message exchange pattern uses the rule │
│ │2.2.1 Fault Replaces Message propagation rule. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │by some prior agreement, another node and/or the │
│MEPDescriptiveness-2002 │service MAY send messages (to each other or to │
│ │other nodes) that are not described by the pattern.│
├─────────────────────────┼───────────────────────────────────────────────────┤
│MEPTermination-2006 │Generation of a fault, regardless of ruleset, │
│ │terminates the exchange. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │When the Message Triggers Fault propagation rule is│
│MessageTriggersFault-2009│in effect, any message, including the first in the │
│ │pattern, MAY trigger a fault message, which MUST │
│ │have opposite direction. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│NodeIdentity-2001 │A node MAY be accessible via more than one physical│
│ │address or transport. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│NoFaults-2011 │When the No Faults propagation rule is in effect, │
│ │faults MUST NOT be propagated. │
├─────────────────────────┼───────────────────────────────────────────────────┤
│ │The robust in-only message exchange pattern uses │
│RobustInOnlyFaults-2014 │the rule 2.2.2 Message Triggers Fault propagation │
│ │rule. │
└─────────────────────────┴───────────────────────────────────────────────────┘
D. Part 2 Change Log (Non-Normative)
┌────────┬──────┬─────────────────────────────────────────────────────────────┐
│ Date │Author│ Description │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070314│JJM │Final fix for minor typos. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070316│JMarsh│Removed two instances of "or a #" from 6.8.1.1 ("#" can't │
│ │ │appear in whttp:location). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070314│JJM │Further adjust the implementation of CR156 to miror that of │
│ │ │section 6.6.3 (i.e. using pattern facets). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070314│JJM │Implement the resolution for CR156 at the proper location │
│ │ │(i.e. 6.5.4). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070313│JJM │CR157 add reference to RFC2234 for ALPHA and DIGIT │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070313│JJM │CR157 further resolution │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070313│JJM │CR157 QUESTION 3 (RE: Http location text for 6.8.1.1) │
│ │ │editorial suggestions │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070313│JJM │CR157: RE: LocationTemplate-1G test. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070313│JJM │CR156: Query parameter separator value. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070228│JJM │Add missing whttp:ignoreUncited to SOAP & HTTP syntax │
│ │ │summaries. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070227│JJM │Reorder bibentries for increased readability. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Added markup around pattern names. Added a non-normative│
│ │ │reference to the Additional MEPs document and corresponding │
│20070227│JJM │bibentry. Reordered normative and non-normative bibentries │
│ │ │for better readability. Removed commented markup for │
│ │ │Additional MEPs (now in a separate document). Removed │
│ │ │commented markup for unused bibentries. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070225│AGR │Renumbered assertions for PR. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070222│JJM │Fixed logic in template encoding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070220│Jmarsh│removed formatting from RPC signature description per │
│ │ │CR149. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070220│JJM │Spell-checked. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070220│JJM │Fixed remaining occurences of contentCoding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070220│JJM │Updated the mapping to SOAP-Response to only allow #element │
│ │ │or #none, as per CR120. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070220│JJM │Renamed "content coding" to "content encoding" for │
│ │ │disambiguation with "transfer coding". │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070216│JMarsh│CR142 - fixed {town/}. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070216│JJM │Fixed issue when Content-Encoding could be empty (follow-up │
│ │ │of CR089). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070216│JJM │Fixed issues noticed by Jonathan │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │CR148: SOAP Action has no effect with SOAP-Response. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │CR142: Remove trailing slash. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│PLH │CR112: HTTP Location property definition. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │CR112: Rename Request-Optional-Response to Request-Response │
│ │ │and point to SOAP 1.2 Second Edition. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │CR143: Remove example headers since we cover them all │
│ │ │already. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │Fix missing "In" for SOAP-Reponse. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │Fix logic in template encoding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070215│JJM │CR112: Fix typo in section title "WSDL Robust-In-Only to SOAP│
│ │ │Request-Optional-Response" │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR044: Additional editorial work, item 3 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR044: Additional editorial work, item 2 part 2 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR120: SOAP Response and IRI style │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR109: SOAP Fault code issue │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR144: Set ImmediateDestination according to Section 6.7.1 │
│ │ │(not 6.7.2) │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR116: 6.7.1.1 Construction of the request IRI using the http│
│ │ │location │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR114: Separation of the in-only and robust-in-only cases. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR114: Mapping WSDL MEPs to SOAP MEPs │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070214│JJM │CR117: Re: 6.7.1.1 Construction of the request IRI using the │
│ │ │http location [completed] │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070213│JJM │CR117: Re: 6.7.1.1 Construction of the request IRI using the │
│ │ │http location [half-way through] │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070213│JJM │CR143: Renamed "transfer coding" to "content coding", and │
│ │ │made it explicit we set HTTP Content-Encoding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070213│JJM │CR146: Ignoring uncited and nillable │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR144: RE: LocationTemplate-1G totally hosed ;-) │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR139: Suggestion on Part - 2 : Adjuncts │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR137: Spelling mistake in Part 2 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR133: {http location} ignored on SOAP request-response MEP? │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR130: Question on double curly braces with HTTP Location │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070212│JJM │CR123: HTTP Method selection │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR113: SOAP Response query string issue. Updated │
│ │ │pseudo-syntax accordingly. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR111: Mapping WSDL meps to the HTTP binding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR110: Semantics of {http cookies} Property. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR092: WSDL 2.0 Fault Binding [Plus two Questions] │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR087: Turning off http transfer coding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR067: {http cookies} REQUIRED? │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20070208│JJM │CR053: Allow absolute URI in {location}. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061221│AGR │CR086: HTTP properties prohibited in SOAP binding unless the │
│ │ │protocol is HTTP. (see 5. WSDL SOAP Binding Extension). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061206│AGR │CR094: Added message assertion table. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061128│JJM │Removed all references to features and properties. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061101│JJM │Added missing whttp:cookies attribute on SOAP binding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061025│JJM │Removed MEPs which are now located in │
│ │ │wsdl20-additional-meps.xml. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061023│JJM │CR043: fixed second occurrence of wrong pseudo-syntax for │
│ │ │wsoap:subcodes │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20061011│AGR │Corrected errors in markup - added @comp. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060914│JJM │CR026: change SHOULD to MUST for using mU in SOAP when mU is │
│ │ │set in WSDL │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060908│JJM │CR068: indicate the patterns and faults which were being │
│ │ │described │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060908│JJM │CR055: Clarification on HTTP Transfer Coding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060908│JJM │CR059: {http location ignore uncited} belongs to the Binding │
│ │ │Operation component │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060907│JJM │CR044: note about interface-less bindings which require │
│ │ │default properties │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060907│JJM │CR073: improved readibility of assertions in 4.1.1 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR076: RPC signature now optional, but must be present when │
│ │ │style is RPC │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR075: separated assertions from suggestions in 4.2 and 4.3 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR070: hardened assertion for RPCStyle-5014 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR067: {http cookies} restricted to SOAP HTTP underlying │
│ │ │protocol only │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR060: renamed authenticationType to authenticationScheme │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR058: renamed {safety} to {safe} │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR043: fixed the pseudo-syntax for wsoap:subcodes │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR040: 5.9.3, changed the type of the {element declaration} │
│ │ │property to a Element Declaration │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR036: 6.5.3, changed the type of the {type definition} │
│ │ │property to a Type Definition │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR035: HTTP method selection defaults to POST │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR034: reworded duplicate assertions in section 5 and 6, │
│ │ │paragraph starting with "As allowed in" │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR033: change "namespace#name" to "qname" for wsoap.header │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR032: {element declaration} is unique for a given soap │
│ │ │header block │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR031: for a soap module on a given binding, {ref} is unique │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR029: CR030: relationship between WSDL and SOAP MEPs, and │
│ │ │MEP defaults │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR027: clarify soap fault subcodes │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR025: IRI style children elements always derive from XML │
│ │ │simple type │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060906│JJM │CR024: clarification that there are no occurence constraints │
│ │ │for IRI style sequence │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060508│AGR │Removed line breaks from within propdef tags to workaround │
│ │ │stylesheet error. Component table is now generated correctly.│
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060506│AGR │Made more editorial improvements. Done now. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060503│AGR │Made editorial improvements. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060405│HH │Removed mentions of "error" and "fatal error" │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060309│HH │CR014: clarification about SOAP underlying protocol │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060309│HH │CR013: relaxed IRI style element cardinality │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060309│HH │CR011: removed {http version} │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060227│HH │CR010: removed slash notation left-over │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060209│HH │Added test assertions to HTTP binding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20060110│AGR │Applied patch, Re: WSDL 2.0 adjuncts assertions , posted by │
│ │ │Lawrence Mandel, 2006-01-09. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051122│HH │LC359: moved transfer coding from binding fault ref to │
│ │ │binding fault in XML representations │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051117│JJM │LC358: fixed formatting in some examples. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051113│HH │LC359: moved transfer coding from binding fault ref to │
│ │ │binding fault │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│HH │Added SOAP MEP / WSDL MEP mapping as per resolution │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│HH │LC333: implemented resolution to accommodate interfaceless │
│ │ │bindings │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│HH │LC362: added URI to fault propagation rules │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│HH │LC337: added media type range │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│HH │LC305: added reference to BNF pseudo-schemas in Part 1 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051111│AGR │Added assertion tables. Added Fault Propagation Rule │
│ │ │assertions. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051110│HH │LC304: implemented proposal │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051110│HH │LC345: allowed POST as application/x-www-form-urlencoded and │
│ │ │reorganized HTTP binding serializations │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051109│HH │LC301: specified that {soap action} is for the initial │
│ │ │message of an operation │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC339: added required attribute to wsoap:header and │
│ │ │whttp:header │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC340: clarified cardinality of headers │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │LC331: if the {message content model} property is "#any" in │
│20051027│HH │the HTTP binding, then the payload MUST be any one XML │
│ │ │element. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC330: operation styles mandate that the {message content │
│ │ │model} of the operation's messages is "#element" │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC329: we do now have default rules for binding faults │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC327: made both HTTP authentication properties optional │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC326: changed type of {http authentication scheme} │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051027│HH │LC315: fixed HTTP header serialization and IRI │
│ │ │identification. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051020│HH │LC319: implemented detailed resolution. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051020│HH │LC342: fixed typos │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051020│HH │LC349: improved section 2's introduction │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051013│HH │LC334: removed HTTP error reason phrase │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051013│HH │Fixed mark-up for declaring {soap modules}, {soap headers} │
│ │ │and {http headers} │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051013│HH │LC323: removed text on HTTP Accept headers. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051013│HH │LC321: clarified {soap mep} error. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20051012│RRC │LC344(5): changed order of union member types in the schema │
│ │ │for the wrpc:signature extension │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC341: renamed {element} into {element declaration} and fixed│
│ │ │typo │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC318: reorganized default declarations in bindings │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC320: added {parent} property to nested components │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC317: clarified applicability of application/ │
│ │ │x-www-url-encoded and multipart/form-data │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC314: completed introduction │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC306: wsdlx declaration clarification. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC322: section 6.3 Default Binding Rules clarification. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC324: fixed queryParameterSeparatorDefault and │
│ │ │queryParameterSeparator definitions. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC325: fixed typo in transferCodingDefault definition. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │LC313: made {soap action}, {http location}, {http error │
│20050923│HH │reason phrase}, {http transfer coding} properties optional; │
│ │ │did not do {soap fault subcodes} because of LC319. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050923│HH │LC312: fixed typo in Section 2. Predefined Message Exchange │
│ │ │Patterns. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050902│RRC │LC316: Added definition of wrpc namespace in section 1.1 and │
│ │ │changed wording of reference to example 4-1 in section 4.1. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050728│HH │LC76d: spelled out conflict between mustUnderstand use and │
│ │ │schema definition; clarified mustUnderstand definition. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050728│HH │Clarified {soap action} scope for SOAP 1.2 binding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050728│HH │LC76c: added security consideration section. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050725│RRC │LC75f: allowed extension attributes on RPC-style input/output│
│ │ │elements. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050707│aal │Modified 2.2.2 per text supplied by Jean-Jacques. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050616│AGR │Fixed component table. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Added markup to list all the components and properties used │
│20050616│JJM │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 │LC76a: Added comment requested by reviewer. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050615│JJM │Further pass at adding markup for properties. Fixed issues │
│ │ │with entities preventing validation. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050615│JJM │Added and markup around properties. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050614│JJM │Finished adding markup around components. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050613│JJM │Started adding markup around components. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050613│JJM │LC122: replaced "binding" by "binding extension" where │
│ │ │appropriate. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050613│JJM │LC98: {soap mep} only applies to SOAP 1.2. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050613│RRC │LC74c: changed documentation element cardinality to zero or │
│ │ │more. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050606│HH │LC79 & LC102: added editors note about one-way MEP defaulting│
│ │ │for SOAP 1.2 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050606│HH │LC130: wsoap:code is now optional, and aligned whttp:code │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050602│HH │LC75c: introduced wsdlx namespace, moved safety to Part 2. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050527│HH │LC74a: switched to IRIs │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050527│HH │LC80: defined fragment identifiers for defined components as │
│ │ │proposed │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050520│JJM │LC97: Fixed specifying default values throughout the spec. │
│ │ │Resolved incoherencies along the way. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050519│aal │added template to guide readers when defining new message │
│ │ │exchange patterns. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050512│HH │LC110: referenced RFC2616 for whttp:version │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050512│HH │LC77a: clarified namespace and local name serialization in │
│ │ │application/x-www-url-encoded serialization │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │LC118: Added clarification to step 2 of the algorithm to │
│20050509│RRC │compute the function signature for an operation that uses the│
│ │ │wrpc:signature extension. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050509│RRC │LC89a: Added conformance requirement for RPC style. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│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 │LC97: Made the setting of default values for properties more │
│ │ │consistent. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050429│RRC │LC75g: RPC should allows element wildcards │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050422│HH │LC75d: RPC style; same input and output elements need named │
│ │ │type │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050420│JJM │Fixed typos in RPC section (part of LC78). │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050413│AV │LC76d: made changes to 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 │LC28: ignoring transfer coding for HTTP/1.0 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050408│HH │LC17: added order preservation in application/ │
│ │ │x-www-url-encoded serialization │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050408│HH │LC69a: added whttp:queryParameterSeparator │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050408│HH │LC47: added whttp:reasonPhrase │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050408│HH │LC76d: added whttp:header │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050408│HH │Added wsoap:module at the Binding Fault component model as │
│ │ │per 2005-04-07 telcon │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050407│HH │LC7: fixed RPC style glitches │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050406│HH │LC76d: added wsoap:header │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050331│HH │LC106: URI and Multipart styles are placing restrictions on │
│ │ │the initial message of the MEP │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050331│HH │LC111: added reference to section 8 of RFC3205 for use of │
│ │ │HTTP error codes │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050321│HH │LC48b: added link between WSDL and SOAP 1.2 MEPs in │
│ │ │predefined MEPs section │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050321│HH │LC74d: removed constraint on LocalPart of the output element │
│ │ │in RPC style │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050321│HH │LC108: fixed typo and added missing {soap modules} XML │
│ │ │mapping │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050321│HH │LC88: fixed typo │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050317│HH │LC61a: Incorporated RPC style │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050316│HH │LC61a: Merged the old part 2 and part 3 documents │
└────────┴──────┴─────────────────────────────────────────────────────────────┘
D.1 WSDL 2.0 Extensions Change Log
┌────────┬──────┬─────────────────────────────────────────────────────────────┐
│ Date │Author│ Description │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050613│JJM │LC122: Replaced "binding" by "binding extension" where │
│ │ │appropriate. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050222│aal │Implement editorial changes for LC39, LC40, LC48c. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050220│AGR │LC50: Adopt proposal for definition of "node", adding "Note:"│
│ │ │before second sentence. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │address issues 233 & 112 all at once, by increasing level of │
│20040713│aal │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │replace "fault generation" with "fault propagation" (in │
│20040713│aal │almost all cases; one case of "generate" remains to indicate │
│ │ │that it ends an exchange). issue 234. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │add language to introduction describing relationship between │
│20040713│aal │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Per action item from October 16 teleconference, added the │
│20031022│aal │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Per 22 Sep 2003 meeting in Palo Alto, CA, removed "Pattern │
│20030922│JCS │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Per 4 Mar 03 meeting, renamed 'message exchange pattern' to │
│20030305│JCS │'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 │
└────────┴──────┴─────────────────────────────────────────────────────────────┘
D.2 WSDL 2.0 Bindings Change Log
┌────────┬──────┬─────────────────────────────────────────────────────────────┐
│ Date │Author│ Description │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050310│JJM │Replaced with . │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050310│JJM │Fixed missing fault pseudo-schema. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050301│RRC │LC55: enabled use of whttp:transferCoding on Binding Fault │
│ │ │Reference components. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050301│RRC │LC55: enabled use of wsoap:module on Binding Fault Reference │
│ │ │components. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050221│HH │LC48b: highlighted relationship between SOAP and WSDL MEPs │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050211│HH │LC49: added conformance section to each of the bindings │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050120│HH │LC75q: removed wsdls namespace and XML 1.1 reference; │
│ │ │limiting to XML 1.0 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20050120│HH │LC21: implemented resolution from 16 Dec 2004 WS Description │
│ │ │WG telcon │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041209│HH │LC86: completed pseudo-schemas with missing F&P occurrences │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041209│HH │LC85: clarified mapping of messages in an operation to HTTP │
│ │ │request/response │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041209│HH │LC30: removed instances of provider/requester agents and │
│ │ │replaced them by HTTP server/client │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041209│HH │LC29d: clarified modification of default of SOAP │
│ │ │serialization rules │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Introduced SOAP version independent WSDL SOAP Binding. Added │
│20041208│AV │two new sections, "Specifying the SOAP Version" and "SOAP 1.2│
│ │ │Binding". Plus, lots of shuffling. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041027│HH │LC57 &LC58: fixed typos │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041027│HH │LC51 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041027│HH │LC45: {http location} may or may not be a template │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041027│HH │LC44: URL serialization expressed in terms of the component │
│ │ │model │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041027│HH │LC29e: URL serialization: disallowing nil elements in certain│
│ │ │cases; clarifying that empty elements are OK │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041001│HH │LC29g: switched 3.8 (serializations) and 3.9 (styles) │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041001│HH │LC29f: it is an error to have nil elements in an instance │
│ │ │data for multipart/form-data │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041001│HH │LC29a & LC29c: indicated that there is no suitable default │
│ │ │fault code │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20041001│HH │LC15: moved {http location} under bulleted list in section 2 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC36 & LC2: added wsdls:* and xs:* in SOAP binding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC32: fixed errors due to operation name restriction in │
│ │ │serialization examples │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC36: added wsdls:* and xs:* in HTTP binding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC37: corrected rules to set operation properties values in │
│ │ │HTTP binding │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC33: removed "default" in SOAP binding's HTTP method │
│ │ │selection │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC13: removed remaining mentions of HTTP Operation Component │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040920│HH │LC12: added whttp:location in SOAP XML summary │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040909│HH │LC10: fixed typo in example 3.3 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040909│HH │LC11: made default attributes consistent with the following │
│ │ │form: wbinding:fooDefault │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20040730│HH │Removed property on wsoap:module in pseudo-schema. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Addressed 249: major reorganization of the HTTP binding to be│
│20040723│HH │presented in a functional way like the SOAP binding rather │
│ │ │than in a syntactical way. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Moved SOAP binding syntax summary to the top per request. │
│20040722│SW │Also fixed the value of the binding/@type property in the │
│ │ │pseudo-schema to show that its a SOAP binding. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Added HTTP error code attribute on fault binding. Added │
│20040722│HH │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Specified default serialization format for HTTP binding, as │
│20040720│HH │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 │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Major rewrite of http binding. Moved to component model, │
│20040604│DO │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 by . 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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Start converting the HTTP binding to the component model. The│
│20030514│JJM │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │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 │
│20030115│JCS │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. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Deleted placeholder for appendix C "Location of Extensibility│
│20020621│JJM │Elements", since this is part 1 stuff and extensibility has │
│ │ │been reworked anyway. │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│20020621│JJM │Corrected link to issues lists │
├────────┼──────┼─────────────────────────────────────────────────────────────┤
│ │ │Updated title from "WSDL" to "Web Services Description │
│20020621│JJM │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 │
└────────┴──────┴─────────────────────────────────────────────────────────────┘