Table of Contents

Web Services Description Language (WSDL) Version 2.0

Part 2: Adjuncts
W3C Recommendation 26 June 2007
This version:
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626
Latest version:
http://www.w3.org/TR/wsdl20-adjuncts
Previous version:
http://www.w3.org/TR/2007/PR-wsdl20-adjuncts-20070523
Editors:
Roberto Chinnici, Sun Microsystems
Hugo Haas, W3C
Amelia A. Lewis, TIBCO Software
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Sanjiva Weerawarana, WSO2

Please refer to the errata for this document, which may include some normative corrections.

This document is also available in these non-normative formats: PDF, PostScript, XML, and plain text.

See also translations.

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

1
 Status of this Document

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 the W3C Recommendation 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.

Please send comments about this document to the public [email protected] mailing list
(public archive).

The Working Group released a test suite along with an implementation report. A diff-marked version
against the previous version of this document is available.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups
and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document
and may be used as reference material or cited from another document. W3C’s role in making the
Recommendation is to draw attention to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.

This document is governed by the 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 [p.6]
1.1 Notational Conventions [p.6]
1.2 Assertions [p.8]
2. Predefined Message Exchange Patterns [p.8]
2.1 Template for Message Exchange Patterns [p.9]
2.1.1 Pattern Name [p.9]
2.2 Fault Propagation Rules [p.9]
2.2.1 Fault Replaces Message propagation rule [p.10]
2.2.2 Message Triggers Fault propagation rule [p.10]
2.2.3 No Faults propagation rule [p.10]
2.3 Message Exchange Patterns [p.10]
2.3.1 In-Only message exchange pattern [p.11]
2.3.2 Robust In-Only message exchange pattern [p.11]

2
 Table of Contents

2.3.3 In-Out message exchange pattern [p.11]

2.4 Security Considerations [p.12]
3. Predefined Extensions [p.12]
3.1 Operation safety [p.12]
3.1.1 Relationship to WSDL Component Model [p.12]
3.1.2 XML Representation [p.13]
3.1.3 Mapping from XML Representation to Component Properties [p.13]
4. Predefined Operation Styles [p.13]
4.1 RPC Style [p.13]
4.1.1 wrpc:signature Extension [p.15]
4.1.2 XML Representation of the wrpc:signature Extension [p.16]
4.1.3 wrpc:signature Extension Mapping To Properties of an Interface Operation component [p.17]
4.2 IRI Style [p.17]
4.3 Multipart style [p.18]
5. WSDL SOAP Binding Extension [p.19]
5.1 SOAP Syntax Summary (Non-Normative) [p.20]
5.2 Identifying the use of the SOAP Binding [p.22]
5.3 SOAP Binding Rules [p.22]
5.4 Specifying the SOAP Version [p.23]
5.4.1 Description [p.23]
5.4.2 Relationship to WSDL Component Model [p.23]
5.4.3 XML Representation [p.23]
5.4.4 Mapping from XML Representation to Component properties [p.23]
5.5 Specifying the SOAP Underlying Protocol [p.24]
5.5.1 Description [p.24]
5.5.2 Relationship to WSDL Component Model [p.24]
5.5.3 XML Representation [p.24]
5.5.4 Mapping from XML Representation to Component Properties [p.24]
5.6 Binding Faults [p.25]
5.6.1 Description [p.25]
5.6.2 Relationship to WSDL Component Model [p.25]
5.6.3 XML Representation [p.25]
5.6.4 Mapping XML Representation to Component Properties [p.26]
5.7 Binding Operations [p.26]
5.7.1 Description [p.26]
5.7.2 Relationship to WSDL Component Model [p.26]
5.7.3 XML Representation [p.27]
5.7.4 Mapping from XML Representation to Component Properties [p.28]
5.8 Declaring SOAP Modules [p.28]
5.8.1 Description [p.28]
5.8.2 Relationship to WSDL Component Model [p.28]
5.8.3 SOAP Module component [p.29]
5.8.4 XML Representation [p.29]
5.8.5 Mapping from XML Representation to Component Properties [p.30]
5.8.6 IRI Identification Of A SOAP Module component [p.31]
5.9 Declaring SOAP Header Blocks [p.31]
5.9.1 Description [p.31]

3
 Table of Contents

5.9.2 Relationship to WSDL Component Model [p.31]

5.9.3 SOAP Header Block component [p.32]
5.9.4 XML Representation [p.32]
5.9.5 Mapping XML Representation to Component Properties [p.34]
5.9.6 IRI Identification Of A SOAP Header Block component [p.34]
5.10 WSDL SOAP 1.2 Binding [p.35]
5.10.1 Identifying a WSDL SOAP 1.2 Binding [p.35]
5.10.2 Description [p.35]
5.10.3 SOAP 1.2 Binding Rules [p.35]
5.10.4 Binding WSDL 2.0 MEPs to SOAP 1.2 MEPs [p.36]
5.10.4.1 WSDL In-Out to SOAP Request-Response [p.36]
5.10.4.1.1 The Client [p.36]
5.10.4.1.2 The Service [p.37]
5.10.4.2 WSDL In-Out to SOAP SOAP-Response [p.37]
5.10.4.2.1 The Client [p.37]
5.10.4.2.2 The Service [p.37]
5.10.4.3 WSDL In-Only to SOAP Request-Response [p.38]
5.10.4.3.1 The Client [p.38]
5.10.4.3.2 The Service [p.38]
5.10.4.4 WSDL Robust-In-Only to SOAP Request-Response [p.38]
5.10.4.4.1 The Client [p.38]
5.10.4.4.2 The Service [p.39]
5.11 Conformance [p.39]
6. WSDL HTTP Binding Extension [p.39]
6.1 Identifying the use of the HTTP Binding [p.40]
6.2 HTTP Syntax Summary (Non-Normative) [p.40]
6.3 Supported Extensions [p.41]
6.4 HTTP Binding Rules [p.41]
6.4.1 HTTP Method Selection [p.41]
6.4.2 HTTP Content Encoding Selection [p.42]
6.4.3 Payload Construction And Serialization Format [p.42]
6.4.3.1 Serialization rules for XML messages [p.43]
6.4.4 Default input and output serialization format [p.44]
6.4.5 HTTP Header Construction [p.44]
6.4.6 HTTP Request IRI [p.45]
6.5 Binding Operations [p.45]
6.5.1 Description [p.45]
6.5.2 Relationship to WSDL Component Model [p.46]
6.5.3 Specification of serialization rules allowed [p.47]
6.5.4 XML Representation [p.47]
6.5.5 Mapping from XML Representation to Component Properties [p.49]
6.6 Declaring HTTP Headers [p.50]
6.6.1 Description [p.50]
6.6.2 Relationship to WSDL Component Model [p.50]
6.6.3 HTTP Header component [p.51]
6.6.4 XML Representation [p.51]
6.6.5 Mapping from XML Representation to Component Properties [p.53]

4
 Appendices

6.6.6 IRI Identification Of An HTTP Header component [p.53]

6.7 Specifying HTTP Error Code for Faults [p.53]
6.7.1 Description [p.53]
6.7.2 Relationship to WSDL Component Model [p.54]
6.7.3 XML Representation [p.54]
6.7.4 Mapping from XML Representation to Component Properties [p.54]
6.8 Serialization Format of Instance Data [p.55]
6.8.1 Serialization of the instance data in parts of the HTTP request IRI [p.56]
6.8.1.1 Construction of the request IRI using the {http location} property [p.57]
6.8.2 Serialization as application/x-www-form-urlencoded [p.58]
6.8.2.1 Case of elements cited in the {http location} property [p.59]
6.8.2.2 Serialization of content of the instance data not cited in the {http location} property [p.59]
6.8.2.2.1 Construction of the query string [p.59]
6.8.2.2.2 Controlling the serialization of the query string in the request IRI [p.60]
6.8.2.2.3 Serialization in the request IRI [p.61]
6.8.2.2.4 Serialization in the message body [p.61]
6.8.3 Serialization as application/xml [p.62]
6.8.4 Serialization as multipart/form-data [p.62]
6.9 Specifying the Content Encoding [p.64]
6.9.1 Description [p.64]
6.9.2 Relationship to WSDL Component Model [p.64]
6.9.3 XML Representation [p.65]
6.9.4 Mapping from XML Representation to Component Properties [p.66]
6.10 Specifying the Use of HTTP Cookies [p.66]
6.10.1 Description [p.66]
6.10.2 Relationship to WSDL Component Model [p.66]
6.10.3 XML Representation [p.66]
6.10.4 Mapping from XML Representation to Component Properties [p.67]
6.11 Specifying HTTP Access Authentication [p.67]
6.11.1 Description [p.67]
6.11.2 Relationship to WSDL Component Model [p.67]
6.11.3 XML Representation [p.68]
6.11.4 Mapping from XML Representation to Component Properties [p.68]
6.12 Conformance [p.69]
7. References [p.69]
7.1 Normative References [p.69]
7.2 Informative References [p.71]

Appendices
A. Acknowledgements [p.72] (Non-Normative)
B. Component Summary [p.73] (Non-Normative)
C. Assertion Summary [p.75] (Non-Normative)

5
 1. Introduction

1. Introduction
The Web Services Description Language Version 2.0 (WSDL 2.0) [WSDL 2.0 Core Language [p.70] ]
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 [p.8]

Operation safety declaration: 3. Predefined Extensions [p.12]

Operation styles: 4. Predefined Operation Styles [p.13]

Binding extensions:

A SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition) [p.70] ] binding
extension: 5. WSDL SOAP Binding Extension [p.19]

An HTTP/1.1 [IETF RFC 2616 [p.69] ] binding extension: 6. WSDL HTTP Binding
Extension [p.39]

This document depends on "Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language" [WSDL 2.0 Core Language [p.70] ]. See also the "Web Services Description Language
(WSDL) Version 2.0 Part 0: Primer" [WSDL 2.0 Primer [p.71] ] for more information and examples.

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 [p.69] ].

This specification uses a number of namespace prefixes throughout; they are listed in Table 1-1 [p.6] .
Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML
Information Set [p.71] ]).

6
 1.1 Notational Conventions

Table 1-1. Prefixes and Namespaces used in this specification

Prefix Namespace Notes
This namespace is defined in [WSDL 2.0 Core
Language [p.70] ]. A normative XML Schema [XML
Schema Structures [p.71] ], [XML Schema Datatypes
[p.71] ] document for the
wsdl "http://www.w3.org/ns/wsdl"
"http://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 [p.12] the
"http://www.w3.org/ns/wsdl-extensions" namespace
defined in [WSDL 2.0 Core Language [p.70] ]. A
wsdlx "http://www.w3.org/ns/wsdl-extensions" normative XML Schema [XML Schema Structures
[p.71] ], [XML Schema Datatypes [p.71] ] 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 [XML Schema Structures [p.71] ], [XML
wsoap "http://www.w3.org/ns/wsdl/soap" Schema Datatypes [p.71] ] document for the
"http://www.w3.org/ns/wsdl/soap" namespace can be
found at http://www.w3.org/ns/wsdl/soap.
Defined by this specification. A normative XML
Schema [XML Schema Structures [p.71] ], [XML
whttp "http://www.w3.org/ns/wsdl/http" Schema Datatypes [p.71] ] document for the
"http://www.w3.org/ns/wsdl/http" namespace can be
found at http://www.w3.org/ns/wsdl/http.
Defined by this specification. A normative XML
Schema [XML Schema Structures [p.71] ], [XML
wrpc "http://www.w3.org/ns/wsdl/rpc" Schema Datatypes [p.71] ] document for the
"http://www.w3.org/ns/wsdl/rpc" namespace can be
found at http://www.w3.org/ns/wsdl/rpc.
Defined in the W3C XML Schema specification
xs "http://www.w3.org/2001/XMLSchema" [XML Schema Structures [p.71] ], [XML Schema
Datatypes [p.71] ].

Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent

application or context-dependent URIs [IETF RFC 3986 [p.69] ].

7
 2. Predefined Message Exchange Patterns

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 [p.70] ] serialization.
The syntax of BNF pseudo-schemas is the same as the one used in [WSDL 2.0 Core Language [p.70] ].

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 [p.75] .

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
[p.70] ]) 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. † [p.85]

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 [p.35] 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 [p.19] ).

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. † [p.85]

8
 2.1 Template for Message Exchange Patterns

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 [p.70] ]. Additional, non-normative patterns are available in [WSDL
2.0 Additional MEPs [p.71] ].

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 [p.9] , 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 [p.10] . "Propagation" is defined as a
best-effort attempt to transmit the fault message to its designated recipient.

9
 2.3 Message Exchange Patterns

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. † [p.85] 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. † [p.85] However, extensions or binding extensions
MAY modify these rulesets. † [p.76] For example, WS-Addressing [WSA 1.0 Core [p.71] ] 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. † [p.85]

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. † [p.85] 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. † [p.85]

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. † [p.85] 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. † [p.85]

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. † [p.85]

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.

10
 2.3 Message Exchange Patterns

2.3.1 In-Only message exchange pattern

The in-only message exchange pattern consists of exactly one message as follows: † [p.80]

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 [p.10] . † [p.85]

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: † [p.82]

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 [p.10] . † [p.85]

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: † [p.80]

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"

11
 3. Predefined Extensions

sent to node N

The in-out message exchange pattern uses the rule 2.2.1 Fault Replaces Message propagation rule
[p.10] . † [p.85]

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 [p.70] ] that allows marking
an operation as a safe interaction, as defined in section 3.4. Safe Interactions of [Web Architecture [p.70]
].

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 [p.49] ).

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 [p.70] ]):

{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 [p.70] ]. † [p.81]

12
 4. Predefined Operation Styles

3.1.2 XML Representation

<description>
<interface>
<operation name="xs:NCName" pattern="xs:anyURI"
wsdlx:safe="xs:boolean"? >
</operation>
</interface>
</description>

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: † [p.75]

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 [p.13] .

Table 3-1. Mapping from XML Representation to Interface Operation component Extension Properties
Property Value
{safe [p.12] 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 [p.55] 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. Also, if the wrpc:signature extension is engaged simultaneously, 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 [p.15] and 4.1.2 XML Representation of the
wrpc:signature Extension [p.16] .

13
 4.1 RPC Style

Furthermore, the associated messages MUST conform to the rules below, described using XML Schema
[XML Schema Structures [p.71] ]. 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 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". † [p.81]

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". † [p.81]

The content model of input and output {element declaration} elements MUST be defined using a
complex type that contains a sequence from XML Schema. † [p.81]

The input sequence MUST only contain elements and element wildcards. † [p.81] It MUST NOT
contain other structures such as xs:choice. The input sequence MUST NOT contain more than
one element wildcard. † [p.81] The element wildcard, if present, MUST appear after any elements. †
[p.81]

The output sequence MUST only contain elements. † [p.81] It MUST NOT contain other structures
such as xs:choice.

Both the input and output sequences MUST contain only local element children. † [p.81] 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. † [p.81]

Input and output elements MUST both be in the same namespace. † [p.81]

The complex type that defines the body of an input or an output element MUST NOT contain any
local attributes. † [p.81] 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 [p.15] ).

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. † [p.81]

The input or output sequence MUST NOT contain multiple children elements declared with the same
name. † [p.82]

14
 4.1 RPC Style

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 † [p.83] . 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". † [p.83]

The value of the {rpc signature [p.15] } property MUST satisfy the following conditions:

The value of the first component of each pair (q, t) MUST be unique within the list. † [p.83]

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. † [p.83]

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. † [p.84]

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. † [p.84]

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. † [p.84]

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. † [p.84]

The function signature defined by a wrpc:signature extension is determined as follows:

1. Start with the value of the {rpc signature [p.15] } 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:

15
 4.1 RPC Style

(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"

16
 4.2 IRI Style

The type of the signature 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 [p.17] 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. † [p.76]

Example 4-1. Definition of the wrpc:signature extension

<xs:attribute name="signature" type="wrpc:signatureType"/>

<xs:simpleType name="signatureType">
<xs:list itemType="wrpc:signatureItemType"/>
</xs:simpleType>

<xs:simpleType name="signatureItemType">
<xs:union memberTypes="xs:QName wrpc:directionToken"/>
</xs:simpleType>

<xs:simpleType name="directionToken">
<xs:restriction base="xs:token">
<xs:enumeration value="#in"/>
<xs:enumeration value="#out"/>
<xs:enumeration value="#inout"/>
<xs:enumeration value="#return"/>
</xs:restriction>
</xs:simpleType>

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
A list of (xs:QName, xs:token) pairs formed by grouping the items present in the
{rpc signature
actual value of the wrpc:signature attribute information item in the order in
[p.15] }
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.

17
 4.3 Multipart style

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". † [p.80]

Use of this value indicates that XML Schema [XML Schema Structures [p.71] ] 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. † [p.80] It MUST NOT contain other structures such as
xs:choice. There are no occurrence constraints on the sequence.

The sequence MUST contain only local element children. † [p.80] 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}. † [p.80]

The complex type that defines the body of the element or its children elements MUST NOT contain
any attributes. † [p.80]

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. † [p.80]

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". † [p.80]

Use of this value indicates that XML Schema [XML Schema Structures [p.71] ] 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. † [p.80] It MUST NOT contain other structures such as
xs:choice.

18
 5. WSDL SOAP Binding Extension

The sequence MUST contain only local element children. † [p.80] The attributes minOccurs and
maxOccurs for these child elements MUST have a value 1. † [p.80] 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}. † [p.81]

The complex type that defines the body of the element or its children elements MUST NOT contain
any attributes. † [p.81]

The sequence MUST NOT contain multiple children element declared with the same local name. †
[p.81]

5. WSDL SOAP Binding Extension

The SOAP binding extension described in this section is an extension for [WSDL 2.0 Core Language
[p.70] ] 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 [p.70] ]. 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 [p.70] ], 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 [p.70] ], 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 [p.39] 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 [p.24] } 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. † [p.82] The allowed properties are the ones that
describe the underlying protocol (HTTP):

19
 5.1 SOAP Syntax Summary (Non-Normative)

{http location [p.46] } and {http location ignore uncited [p.60] } on Binding Operation components,
as defined in 6.5 Binding Operations [p.45] and 6.8.2.2.2 Controlling the serialization of the
query string in the request IRI [p.60] , respectively.

{http headers [p.50] } on Binding Message Reference and Binding Fault components, as defined in
6.6 Declaring HTTP Headers [p.50]

{http query parameter separator default [p.46] } on Binding components, {http query parameter
separator [p.47] } on Binding Operation components, as defined in 6.5.2 Relationship to WSDL
Component Model [p.46]

{http content encoding default [p.64] } on Binding and Binding Operation components, {http content
encoding [p.65] } on Binding Message Reference and Binding Fault components, as defined in 6.9
Specifying the Content Encoding [p.64]

{http cookies [p.66] } on Binding components, as defined in 6.10 Specifying the Use of HTTP
Cookies [p.66] .

{http authentication scheme [p.67] } and {http authentication realm [p.67] } on Endpoint
components, as defined in 6.11 Specifying HTTP Access Authentication [p.67]

5.1 SOAP Syntax Summary (Non-Normative)

<description>
<binding name="xs:NCName" interface="xs:QName"?
type="http://www.w3.org/ns/wsdl/soap"
whttp:queryParameterSeparatorDefault="xs:string"??
whttp:contentEncodingDefault="xs:string"??
whttp:cookies="xs:boolean"?
wsoap:version="xs:string"?
wsoap:protocol="xs:anyURI"
wsoap:mepDefault="xs:anyURI"? >
<documentation />*

<wsoap:module ref="xs:anyURI" required="xs:boolean"? >

<documentation />*
</wsoap:module>*

<fault ref="xs:QName"
wsoap:code="union of xs:QName, xs:token"?
wsoap:subcodes="union of (list of xs:QName), xs:token"?
whttp:contentEncoding="xs:string"?? >

<documentation />*

<wsoap:module ... />*

<wsoap:header element="xs:QName" mustUnderstand="xs:boolean"?
required="xs:boolean"? >
<documentation />*
</wsoap:header>*
<whttp:header ... />*??

</fault>*

20
 5.1 SOAP Syntax Summary (Non-Normative)

<operation ref="xs:QName"
whttp:location="xs:anyURI"??
whttp:contentEncodingDefault="xs:string"??
whttp:queryParameterSeparator="xs:string"??
whttp:ignoreUncited="xs:boolean"??
wsoap:mep="xs:anyURI"?
wsoap:action="xs:anyURI"? >

<documentation />*

<wsoap:module ... />*

<input messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"?? >
<documentation />*
<wsoap:module ... />*
<wsoap:header ... />*
<whttp:header ... />*??
</input>*

<output messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"?? >
<documentation />*
<wsoap:module ... />*
<wsoap:header ... />*
<whttp:header ... />*??
</output>*

<infault ref="xs:QName"
messageLabel="xs:NCName"?>
<documentation />*
<wsoap:module ... />*
</infault>*

<outfault ref="xs:QName"
messageLabel="xs:NCName"?>
<documentation />*
<wsoap:module ... />*
</outfault>*

</operation>*

</binding>

<service>
<endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"?
whttp:authenticationScheme="xs:token"??
whttp:authenticationRealm="xs:string"?? >
<documentation />*
</endpoint>
</service>
</description>

21
 5.2 Identifying the use of the SOAP Binding

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 [p.70] ]) 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. † [p.82] This
is further subject to optimization by a feature in use which affects serialization, such as MTOM
[SOAP Message Transmission Optimization Mechanism [p.71] ]. 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. † [p.84]

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. † [p.84]

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 [p.70] ]), then additional binding
rules MUST be defined to indicate how to map those components into the SOAP envelope. †
[p.82]

Note:

This SOAP binding extension only allows one single element in the SOAP body.

SOAP Header Construction. If the {soap headers [p.31] } property as defined in section 5.9
Declaring SOAP Header Blocks [p.31] 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 [p.32] component’s {element declaration [p.32] } property, in the {soap
headers [p.31] } property, MAY be turned into a SOAP header block for the corresponding message.

If the value of the SOAP Header Block [p.32] component’s {required [p.32] } property is "true", the
inclusion of this SOAP header block is REQUIRED, otherwise it is OPTIONAL.

22
 5.4 Specifying the SOAP Version

And, if the SOAP Header Block [p.32] component’s {mustUnderstand [p.32] } 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 [p.31] } 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 [p.28] .

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. † [p.82]

By default, SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition) [p.70] ] 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 [p.70] ]):

{soap version} REQUIRED. A xs:string, to the Binding component.

5.4.3 XML Representation

<description>
<binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
wsoap:version="xs:string"? >
...
</binding>
</description>

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 [p.23] .

23
 5.5 Specifying the SOAP Underlying Protocol

Table 5-1. Mapping from XML Representation to Binding component Extension Properties
Property Value
{soap version The actual value of the wsoap:version attribute information item, if present;
[p.23] } 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. † [p.82]

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 [p.70] ]):

{soap underlying protocol} REQUIRED. A xs:anyURI, which is an absolute IRI as defined by [IETF
RFC 3987 [p.70] ], 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) [p.70] ]), which is to be used for any of the SOAP interactions
described by this binding.

5.5.3 XML Representation

<description>
<binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
wsoap:protocol="xs:anyURI" >
...
</binding>
</description>

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 [p.24] .

24
 5.6 Binding Faults

Table 5-2. Mapping from XML Representation to Binding component Extension Properties
Property Value
{soap underlying protocol [p.24] The actual value of the wsoap:protocol attribute 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. † [p.82] 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 [p.70] ]):

{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 [p.23] } is "1.2", the allowed QNames MUST be the ones
defined by [SOAP 1.2 Part 1: Messaging Framework (Second Edition) [p.70] ], section 5.4.6 †
[p.82] ;

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

<description>
<binding >
<fault ref="xs:QName"
wsoap:code="union of xs:QName, xs:token"?
wsoap:subcodes="union of (list of xs:QName), xs:token"? >
<documentation />*
</fault>*
</binding>
</description>

25
 5.7 Binding Operations

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 [p.26] .

Table 5-3. Mapping from XML Representation to SOAP Fault component Properties
Property Value
The actual value of the code attribute information item, if present;
{soap fault code [p.25] }
otherwise "#any".
{soap fault subcodes The actual value of the subcodes attribute information item, if present;
[p.25] } 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 [p.35] ), 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 [p.70] ]):

26
 5.7 Binding Operations

{soap mep default} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC
3987 [p.70] ], to the Binding component. † [p.83] 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
[p.70] ], to the Binding Operation component. † [p.83] 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
[p.35] , 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
[p.70] ], to the Binding Operation component. † [p.82] 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 [p.35] for the SOAP 1.2 binding when the value of the {soap
version [p.23] } property of the Binding component is "1.2").

5.7.3 XML Representation

<description>
<binding wsoap:mepDefault="xs:anyURI"? >
<operation ref="xs:QName"
wsoap:mep="xs:anyURI"?
wsoap:action="xs:anyURI"? >
</operation>
</binding>
</description>

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:

27
 5.8 Declaring SOAP Modules

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 [p.28] .

Table 5-4. Mapping from XML Representation to SOAP Operation Component Properties
Property Value
{soap mep default The actual value of the wsoap:mepDefault attribute information item, if
[p.27] } present.
{soap mep [p.27] } The actual value of the wsoap:mep attribute information item, if present.
{soap action [p.27] } 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) [p.70] ]). 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 [p.29] component adds the following property to the WSDL component model (as
defined in [WSDL 2.0 Core Language [p.70] ]):

{soap modules} OPTIONAL. A set of SOAP Module [p.29] components as defined in 5.8.3 SOAP
Module component [p.29] 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

28
 5.8 Declaring SOAP Modules

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 [p.29] 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 [p.70] ]. †
[p.83] 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) [p.70] ] 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 [p.28] }
property.

5.8.4 XML Representation

<description>
<binding >
<wsoap:module ref="xs:anyURI"
required="xs:boolean"? >
<documentation ... />*
</wsoap:module>
<fault>
<wsoap:module ... />*
</fault>
<operation>
<wsoap:module ... />*
<input>
<wsoap:module ... />*
</input>
<output>
<wsoap:module ... />*
</output>
<infault>
<wsoap:module ... />*
</infault>
<outfault>
<wsoap:module ... />*

29
 5.8 Declaring SOAP Modules

</outfault>
</operation>
</binding>
</description>

The XML representation for a SOAP Module [p.29] 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 [p.70] ].

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 [p.30] .

30
 5.9 Declaring SOAP Header Blocks

Table 5-5. Mapping from XML Representation to SOAP Module component-related Properties
Property Value
{soap The set of SOAP Module [p.29] components corresponding to all the module element
modules information item in the [children] of the binding, operation, fault, input,
[p.28] } output, infault, outfault element information items, if any.
{ref [p.29] } The actual value of the ref attribute information item.
{required The actual value of the required attribute information item, if present; otherwise
[p.29] } "false".
The Binding, Binding Operation, Binding Message Reference, Binding Fault or Binding
{parent
Fault Reference component corresponding to the binding, operation, fault,
[p.29] }
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 [p.70] ] defines a fragment
identifier syntax for identifying components of a WSDL 2.0 document.

A SOAP Module [p.29] 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 [p.29] } component, as specified in appendix A.2,
Fragment Identifiers in [WSDL 2.0 Core Language [p.70] ]. parts.

2. ref is the value of the {ref [p.29] } 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 [p.70] ]):

{soap headers} OPTIONAL. A set of SOAP Header Block [p.32] components as defined in 5.9.3
SOAP Header Block component [p.32] , to the Binding Message Reference component.

31
 5.9 Declaring SOAP Header Blocks

Similarly, {soap headers} OPTIONAL, to the Binding Fault component.

5.9.3 SOAP Header Block component

A SOAP Header Block [p.32] 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 [p.32] 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 [p.32] } property
MUST allow this SOAP mustUnderstand attribute information item. † [p.83] 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. † [p.83] 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 [p.31] } property.

5.9.4 XML Representation

<description>
<binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/soap" >
<fault ref="xs:QName" >
<wsoap:header element="xs:QName" mustUnderstand="xs:boolean"?
required="xs:boolean"? >
<documentation />*
</wsoap:header>*
...
</fault>*
<operation ref="xs:QName" >
<input messageLabel="xs:NCName"?>
<wsoap:header ... />*
...
</input>*
<output messageLabel="xs:NCName"?>
<wsoap:header ... />*
...

32
 5.9 Declaring SOAP Header Blocks

</output>*
</operation>*
</binding>
</description>

The XML representation for a SOAP Header Block [p.32] 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 [p.70] ].

33
 5.9 Declaring SOAP Header Blocks

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 [p.34] .

Table 5-6. Mapping from XML Representation to SOAP Header Block component-related Properties
Property Value
The set of SOAP Header Block [p.32] components corresponding to all the
{soap headers
header element information item in the [children] of the fault, input or
[p.31] }
output element information item, if any.
The element declaration from the {element declarations} resolved to by the value
{element of the element attribute information item. The value of the element attribute
declaration [p.32] } information item MUST resolve to a global element declaration from the {element
declarations} property of the Description component. † [p.83]
{mustUnderstand The actual value of the mustUnderstand attribute information item, if present;
[p.32] } otherwise "false".
The actual value of the required attribute information item, if present;
{required [p.32] }
otherwise "false".
The Binding Fault or Binding Message Reference component corresponding to the
{parent [p.32] }
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 [p.70] ] defines a fragment
identifier syntax for identifying components of a WSDL 2.0 document.

A SOAP Header Block [p.32] 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 "wsdl.*" pointer part of the {parent [p.32] } component, as specified in appendix A.2,
Fragment Identifiers in [WSDL 2.0 Core Language [p.70] ], i.e. without the xmlns() pointer parts.

2. element declaration is the value of the {name} of the Element Declaration component that is
referred to by the {element declaration [p.32] } property of the SOAP Header Block component.

34
 5.10 WSDL SOAP 1.2 Binding

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 [p.23] } 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 [p.19] to enable Web service applications to use
SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition) [p.70] ].

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) [p.70] ] 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) [p.70] ]) to the {soap underlying protocol [p.24] } 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 [p.35] define the relationship between SOAP
message exchange patterns defined in [SOAP 1.2 Part 2: Adjuncts (Second Edition) [p.70] ] and WSDL
message exchange patterns defined in section 2. Predefined Message Exchange Patterns [p.8] .

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 [p.27] } property
of this Binding Operation component. If the Binding Operation component does NOT have a {soap
action [p.27] } property defined, then the SOAP Action Feature (see [SOAP 1.2 Part 2: Adjuncts
(Second Edition) [p.70] ]) 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 [p.27] } property
has NO effect when binding to the SOAP-Response MEP.

35
 5.10 WSDL SOAP 1.2 Binding

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 [p.27] } property has a value, then the SOAP MEP is the value of the {soap mep [p.27] }
property. Otherwise, the SOAP MEP is the value of the Binding component’s {soap mep default
[p.27] }, 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) [p.70] ]. † [p.83]

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. †
[p.84]

HTTP Method Selection. This default binding rule is applicable when the value of the {soap
underlying protocol [p.24] } 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". † [p.82]

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) [p.70] ].

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
[p.71] ]) 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 [p.45] , and modified as described in section
6.8.1 Serialization of the instance data in parts of the HTTP request IRI [p.56] .

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.

36
 5.10 WSDL SOAP 1.2 Binding

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
[p.71] ]) 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 [p.45] , and modified as described in section
6.8.1 Serialization of the instance data in parts of the HTTP request IRI [p.56] .

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 [p.58] .

"#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 [p.58] , WHEN the value of the {message content
model} property for the Interface Message Reference components of the {interface message references}

37
 5.10 WSDL SOAP 1.2 Binding

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 [p.71] ]) 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 [p.45] , and modified as described in section
6.8.1 Serialization of the instance data in parts of the HTTP request IRI [p.56] .

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 [p.71] ]) 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".

38
 6. WSDL HTTP Binding Extension

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 [p.45] , and modified as described in section
6.8.1 Serialization of the instance data in parts of the HTTP request IRI [p.56] .

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
[p.70] ] to enable Web services applications to use HTTP 1.1 [IETF RFC 2616 [p.69] ] (as well as other
versions of HTTP) and HTTPS [IETF RFC 2818 [p.69] ]. This binding extension extends WSDL 2.0 by
adding properties to the component model defined in [WSDL 2.0 Core Language [p.70] ]. 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 [p.70] ], 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

39
 6.1 Identifying the use of the HTTP Binding

2.0 Core Language [p.70] ], 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 [p.70] ]) 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)

<description>
<binding name="xs:NCName" interface="xs:QName"?
type="http://www.w3.org/ns/wsdl/http"
whttp:methodDefault="xs:string"?
whttp:queryParameterSeparatorDefault="xs:string"?
whttp:cookies="xs:boolean"?
whttp:contentEncodingDefault="xs:string"? >
<documentation />?

<fault ref="xs:QName"
whttp:code="union of xs:int, xs:token"?
whttp:contentEncoding="xs:string"? >
<documentation />*
<whttp:header name="xs:string" type="xs:QName"
required="xs:boolean"? >
<documentation />*
</whttp:header>*
</fault>*

<operation ref="xs:QName"
whttp:location="xs:anyURI"?
whttp:method="xs:string"?
whttp:inputSerialization="xs:string"?
whttp:outputSerialization="xs:string"?
whttp:faultSerialization="xs:string"?
whttp:queryParameterSeparator="xs:string"?
whttp:contentEncodingDefault="xs:string"?
whttp:ignoreUncited="xs:boolean"? >
<documentation />*

40
 6.3 Supported Extensions

<input messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"? >
<documentation />*
<whttp:header ... />*
</input>*

<output messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"? >
<documentation />*
<whttp:header ... />*
</output>*

<infault ref="xs:QName"
messageLabel="xs:NCName"? >
<documentation />*
</infault>*

<outfault ref="xs:QName"
messageLabel="xs:NCName"? >
<documentation />*
</outfault>*

</operation>*

</binding>

<service>
<endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"?
whttp:authenticationScheme="xs:token"?
whttp:authenticationRealm="xs:string"? >
<documentation />*
</endpoint>
</service>
</description>

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 [p.12] )

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: † [p.76]

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 [p.46] }
property has a value, then the value of the {http method [p.46] } property.

41
 6.4 HTTP Binding Rules

Otherwise, the value of the Binding component’s {http method default [p.46] }, if any.

Otherwise, if a {safe [p.12] } property as defined in 3.1 Operation safety [p.12] 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: † [p.76]

If the {http content encoding [p.65] } 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
[p.64] } 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 [p.64]
} 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: † [p.76]

If the {http content encoding [p.65] } 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 [p.64] } 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 [p.42] used. † [p.76]

[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 [p.46] }
property. The HTTP response serialization format MUST be in the media type range specified by the {http
output serialization [p.46] } property. The HTTP serialization format of a fault MUST be in the media
type range specified by the {http fault serialization [p.46] } property. The concept of media type range is
defined in Section 14.1 of [IETF RFC 2616 [p.69] ]. 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 [p.69] ]. ]

42
 6.4 HTTP Binding Rules

Section 6.8 Serialization Format of Instance Data [p.55] 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 [p.43] .

If the value is "#none", then the payload MUST be empty and the value of the corresponding
serialization property ({http input serialization [p.46] } or {http output serialization [p.46] }) is
ignored. † [p.76]

If the value is "#other", then the serialization format [p.42] 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 [p.69] ]. 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 [p.43] .

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 [p.70] ]), then
additional binding rules MUST be defined in an extension specification to indicate how to map those
components into the HTTP envelope. † [p.76]

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: † [p.76]

If the serialization format [p.42] is "application/x-www-form-urlencoded", then the serialization of

the instance data [p.40] is defined by section 6.8.2 Serialization as
application/x-www-form-urlencoded [p.58] .

If the serialization format [p.42] is "multipart/form-data", then the serialization of the instance data
[p.40] is defined by section 6.8.4 Serialization as multipart/form-data [p.62] .

If the serialization format [p.42] is "application/xml", then the serialization of the instance data [p.40]
is defined by section 6.8.3 Serialization as application/xml [p.62] .

Otherwise, then the serialization of the instance data [p.40] is defined by section 6.8.3 Serialization
as application/xml [p.62] with the following additional rule: the value of the HTTP
Content-Type entity-header field is the value of the serialization format [p.42] and its associated
media type parameters, if any.

43
 6.4 HTTP Binding Rules

6.4.4 Default input and output serialization format

Section Table 6-1 [p.44] 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 [p.41] .

Table 6-1. Default values for GET, POST, PUT and DELETE
Default Output
HTTP Method Default Input Serialization
Serialization
Selected in 6.4.1 HTTP
{http output serialization
Method Selection {http input serialization [p.46] }
[p.46] }
[p.41]
GET application/x-www-form-urlencoded application/xml
POST application/xml application/xml
PUT application/xml application/xml
DELETE application/x-www-form-urlencoded application/xml

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 [p.58] ).

The default value for the {http input serialization [p.46] } and {http output serialization [p.46] } 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 [p.40] 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 [p.22] . This binding
extension specifies that the SOAP-Response Message Exchange Pattern ([SOAP 1.2 Part 2: Adjuncts
(Second Edition) [p.70] ], 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 [p.50] } property as defined in section 6.6 Declaring HTTP Headers [p.50] exists and
is not empty in a Binding Message Reference or Binding Fault component, HTTP headers conforming to
each HTTP Header [p.51] component contained in this {http headers [p.50] } property MAY be serialized
as follows: † [p.77]

44
 6.5 Binding Operations

The HTTP header field name used is the value of the {name [p.51] } property of the HTTP Header
[p.51] component. The HTTP binding MUST NOT set an HTTP header field corresponding to the
value of the {name [p.51] } property already set by another mechanism, such as the HTTP stack or
another feature. † [p.77]

The HTTP header field value, whose XML Schema type is declared by the {type definition [p.51] }
property of the HTTP Header [p.51] component, is serialized following the rules of the
field-value production of section 4.2 of [IETF RFC 2616 [p.69] ].

If the value of an HTTP Header [p.51] component’s {required [p.51] } property is "true", the inclusion of
this HTTP header field is REQUIRED † [p.77] , 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 [p.46] } 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 [p.69] ]). † [p.77] If the
{http location [p.46] } property is not 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 [p.46] } 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 [p.55] define a
syntax to use the {http location [p.46] } as a template using elements of the instance data.

If the resulting IRI uses the https scheme, then HTTP over TLS [IETF RFC 2818 [p.69] ] 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 [p.69] ].

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.

45
 6.5 Binding Operations

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. † [p.77] In cases where only one single message is being sent, the
message body of the HTTP response MUST be empty. † [p.77]

For successful responses, the HTTP response code MUST be:

202 when the MEP is "http://www.w3.org/ns/wsdl/in-only" † [p.80]

204 when the MEP is "http://www.w3.org/ns/wsdl/robust-in-only" † [p.80]

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 [p.70] ]):

{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. † [p.77]

{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 [p.47] .

{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 [p.47] .

{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 [p.47] .

{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.

46
 6.5 Binding Operations

{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 [p.46] }, {http output serialization [p.46] } and {http fault
serialization [p.46] } 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 [p.69] ]) and MUST follow the production
rules defined in that section except for the following: † [p.78]

1. The prefix "Accept:" MUST NOT be used.

2. The rule qdtext is changed from:

qdtext = <any TEXT except<">>

to:

qdtext = <any CHAR except<">>

This change is made to disallow non-US-ASCII OCTETs.

These properties indicate the range of media types and associated parameters with which an instance
MAY be serialized. The value of the serialization format [p.42] used for a message is a media type which
MUST be covered by this range. † [p.77] Wild cards (for example, "application/*") SHOULD NOT be
used in this attribute information item since they may lead to interoperability problems. † [p.77]

The use of {http input serialization [p.46] }, {http output serialization [p.46] } and {http fault serialization
[p.46] } is specified in section 6.4.3 Payload Construction And Serialization Format [p.42] .

6.5.4 XML Representation

<description>
<binding whttp:methodDefault="xs:string"?
whttp:queryParameterSeparatorDefault="xs:string"? >
<operation ref="xs:QName"
whttp:location="xs:anyURI"?
whttp:method="xs:string"?
whttp:inputSerialization="xs:string"?
whttp:outputSerialization="xs:string"?
whttp:faultSerialization="xs:string"?
whttp:queryParameterSeparator="xs:string"? >
</operation>
</binding>
</description>

The XML representation for binding an Operation are six attribute information items with the following
Infoset properties:

47
 6.5 Binding Operations

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

48
 6.5 Binding Operations

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 [p.47] } property above.

6.5.5 Mapping from XML Representation to Component Properties

See Table 6-2 [p.49] .

49
 6.6 Declaring HTTP Headers

Table 6-2. Mapping from XML Representation to Binding Operation component Extension Properties
Property Value
{http location [p.46]
The actual value of the whttp:location attribute information item, if present.
}
{http method The actual value of the whttp:methodDefault attribute information item, if
default [p.46] } present.
{http method [p.46]
The actual value of the whttp:method attribute information item, if present.
}
{http input The actual value of the whttp:inputSerialization attribute information
serialization [p.46] item, if present; otherwise, the default value as defined in 6.4 HTTP Binding
} Rules [p.41] .
{http output The actual value of the whttp:outputSerialization attribute information
serialization [p.46] item, if present; otherwise, the default value as defined in 6.4 HTTP Binding
} Rules [p.41] .
{http fault
The actual value of the whttp:faultSerialization attribute information
serialization [p.46]
item, if present; otherwise "application/xml".
}
{http query
The actual value of the whttp:queryParameterSeparatorDefault
parameter separator
attribute information item, if present; otherwise, "&".
default [p.46] }
{http query
The actual value of the whttp:queryParameterSeparator attribute
parameter separator
information item, if present.
[p.47] }

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 [p.70] ]):

{http headers} OPTIONAL. A set of HTTP Header [p.51] components as defined in 6.6.3 HTTP
Header component [p.51] , to the Binding Message Reference component.

50
 6.6 Declaring HTTP Headers

Similarly, {http headers} OPTIONAL, to the Binding Fault component.

A Binding Message Reference or a Binding Fault component’s {http headers [p.50] } property MUST
NOT contain multiple HTTP Header [p.51] components with the same {name [p.51] } property. † [p.78]

6.6.3 HTTP Header component

An HTTP Header [p.51] 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 [p.51] 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 [p.69] ].

{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. † [p.78]

{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. † [p.78] 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 [p.50] } property.

6.6.4 XML Representation

<description>
<binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/http" >
<fault ref="xs:QName">
<whttp:header name="xs:string" type="xs:QName"
required="xs:boolean"? >
<documentation />*
</whttp:header>*
...
</fault>*
<operation ref="xs:QName" >
<input messageLabel="xs:NCName"?>
<whttp:header ... />*
...
</input>*
<output messageLabel="xs:NCName"?>
<whttp:header ... />*
...

51
 6.6 Declaring HTTP Headers

</output>*
</operation>*
</binding>
</description>

The XML representation for a HTTP Header [p.51] 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 [p.70] ].

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".

52
 6.7 Specifying HTTP Error Code for Faults

6.6.5 Mapping from XML Representation to Component Properties

See Table 6-3 [p.53] .

Table 6-3. Mapping from XML Representation to HTTP Header component-related Properties
Property Value
The set of HTTP Header [p.51] components corresponding to all the header element
{http headers
information item in the [children] of the fault, input or output element
[p.50] }
information item, if any.
{name [p.51] } The value of the name attribute information item.
The Type Definition component from the {type definitions} property of the
{type definition
Description component resolved to by the value of the type attribute information
[p.51] }
item.
{required The actual value of the required attribute information item, if present; otherwise
[p.51] } "false".
{parent [p.51] The Binding Fault or Binding Message Reference component 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 [p.70] ] defines a fragment
identifier syntax for identifying components of a WSDL 2.0 document.

An HTTP Header [p.51] 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 [p.51] } component, as specified in WSDL Version 2.0
Part 1: Core Language.

2. name is the {name [p.51] } 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.

53
 6.7 Specifying HTTP Error Code for Faults

The fault definition SHOULD agree with the definition of the HTTP error codes, as specified in section 8
of [IETF RFC 3205 [p.69] ]. † [p.77]

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 [p.70] ]):

{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 [p.69] ] that the service will use in case the fault is
returned. † [p.77] If the value of this property is "#any", no claim is made by the service.

6.7.3 XML Representation

<description>
<binding >
<fault ref="xs:QName"
whttp:code="union of xs:int, xs:token"? >
</fault>*
</binding>
</description>

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 [p.54] .

Table 6-4. Mapping from XML Representation to Binding Fault component Extension Properties
Property Value
{http error status code The actual value of the whttp:code attribute information item, if present;
[p.54] } otherwise "#any".

54
 6.8 Serialization Format of Instance Data

6.8 Serialization Format of Instance Data

This section specifies three serialization formats defining rules to encode the instance data [p.40] of an
input or output message as an HTTP message. Table 6-5 [p.55] and Table 6-6 [p.55] give an overview of
those serialization formats and their constraints. All of them allow serialization of parts of the instance
data [p.40] in the HTTP Request IRI, as defined in section 6.8.1 Serialization of the instance data in
parts of the HTTP request IRI [p.56] .

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 In the message body

request
URI application/x-www-form-urlencoded multipart/form-data application/xml
Without
message
All,
body:
some - - -
GET,
HTTP or none
DELETE,
request …
(input
message) With
message All,
body: some Remainder All All
POST, or none
PUT, …
HTTP response
- - - All
(output message)

55
 6.8 Serialization Format of Instance Data

Table 6-6. Operation styles required for using serialization formats defined below as input serialization
Request
Request
HTTP URI: query Input serialization
Method parameters
or path application/x-www-form-urlencoded multipart/form-data application/xml
components
Without
message
body:
IRI style IRI style - -
GET,
DELETE,
…
IRI style, if
With any data is
message serialized as
body: path IRI style Multipart style None required
POST, components
PUT, … or query
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 [p.46] } property of the Binding Operation
component. Templating is used by the serialization formats defined in section 6.8 Serialization Format of
Instance Data [p.55] , 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 [p.17] , and if the {http location [p.46] }
property of the Binding Operation component is present, the value of the {http location [p.46] } property
component is used as a template † [p.78] 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 [p.46] .

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 [p.70] ]. † [p.78] Additional rules for the
serialization of the HTTP request IRI MAY be defined by a serialization format.

56
 6.8 Serialization Format of Instance Data

6.8.1.1 Construction of the request IRI using the {http location} property

The {http location [p.46] } property MAY cite local names of elements from the instance data [p.40] 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 [p.60] 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 {http location [p.46] } property MUST conform to the following EBNF [ISO/IEC 14977:1996 [p.69]
] grammar, which represents the patterns for constructing the request IRI: † [p.78]
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 4234
[p.70] ]):

The local name in a template SHOULD match at least one element from the instance data [p.40] of
the input message. † [p.78] 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
[p.40] . 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 [p.40] . Cited elements (i.e. elements referenced in templates) MUST
NOT carry an xs:nil attribute whose value is "true" † [p.84] .

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 [p.40] . No percent-encoding
is performed.

Each encoded template (encodedTemplate production in the grammar above) NOT preceded in
the {http location [p.46] } property by a "?" character is replaced by the possibly empty single value
of the corresponding element from the instance data [p.40] . 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.

57
 6.8 Serialization Format of Instance Data

Each encoded template (encodedTemplate production in the grammar above) preceded in the
{http location [p.46] } property by a "?" character is replaced by the possibly empty single value of
the corresponding element from the instance data [p.40] . Encoding is performed as follows:

The value of the {http query parameter separator [p.47] } property, if present; otherwise the
value of the {http query parameter separator default [p.46] } 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 [p.70] ].

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 [p.40] 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 [p.17] , i.e. this
serialization format may only be used to serialize the HTTP request corresponding to the initial message
of an interface operation. † [p.79]

For the HTTP binding defined in this section (6. WSDL HTTP Binding Extension [p.39] ),
"application/x-www-form-urlencoded" MAY be used as a serialization format [p.42] for an input message
(HTTP Request), but MUST NOT be used as a serialization format [p.42] for an output or fault message
(HTTP Response). † [p.79]

58
 6.8 Serialization Format of Instance Data

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 [p.46] } property defined in 6.8.1 Serialization of the instance data in parts of the HTTP
request IRI [p.56] 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 [p.40] are cited in the {http location [p.46] } property, or if the
property is not present on the Binding Operation component, then additional serialization rules apply. †
[p.79]

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 [p.59] .

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 [p.61] ),
otherwise it is serialized in the message body (see 6.8.2.2.4 Serialization in the message body [p.61] ).

6.8.2.2.1 Construction of the query string

For elements of the instance data not cited in the {http location [p.46] } property, a query string is
constructed as follows. † [p.79]

Non-nil elements with a possibly empty single value of the instance data [p.40] not cited are serialized as
query parameters in the order they appear in the instance data.

The instance data [p.40] MUST NOT contain elements with an xs:nil attribute whose value is "true". †
[p.78]

Each parameter pair is separated by the value of the {http query parameter separator [p.47] } property, if
present, or the value of the {http query parameter separator default [p.46] } 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 4234 [p.70] ]): 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 [p.70] ].

59
 6.8 Serialization Format of Instance Data

Example 6-1. Query string generation

The following instance data of an input message:

<data>
<town>Fréjus</town>
<date>2007-06-26</date>
<unit>C</unit>
</data>

with the following value of the {http location [p.46] } property:

’temperature/{town}’

and the following value of the {http query parameter separator default [p.46] } property:
’&’

will produce the following query string:

date=2007-06-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 [p.46] } 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 [p.61] dictate how to serialize elements not cited in {http location [p.46] } 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 [p.60] } is "true", any element NOT cited in the {http location [p.46] } 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. † [p.78]

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

60
 6.8 Serialization Format of Instance Data

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 ignore The actual value of the whttp:ignoreUncited attribute information
uncited [p.60] } 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 [p.60] } property is "false", then the following rules apply. †
[p.79]

If the {http location [p.46] } 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 [p.47] } property, if present, or the value
of the {http query parameter separator default [p.46] } property otherwise, is appended.

Finally, the query string computed in 6.8.2.2.1 Construction of the query string [p.59] is appended.

Example 6-2. Instance data serialized in an IRI

The instance data defined in Example 6-1 [p.60] with the following operation declaration:
<operation ref=’t:data’
whttp:location=’temperature/{town}’
whttp:method=’GET’ />

and the following endpoint declaration:

<endpoint name=’e’ binding=’t:b’
address=’http://ws.example.com/service1/’ />

will serialize the message in the HTTP request as follows:

GET http://ws.example.com/service1/temperature/Fr%C3%A9jus?date=2007-06-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. † [p.79]

Finally, the query string computed in 6.8.2.2.1 Construction of the query string [p.59] is used as the
value of the HTTP message body.

61
 6.8 Serialization Format of Instance Data

The Content-Type HTTP header field must have the value

application/x-www-form-urlencoded. † [p.79]

Example 6-3. Instance data serialized in the HTTP Request IRI and message body

The instance data defined in Example 6-1 [p.60] with the following operation declaration:
<operation ref=’t:data’
whttp:inputSerialization=’application/x-www-form-urlencoded’
whttp:location=’temperature/{town}’
whttp:method=’POST’ />

and the following endpoint declaration:

<endpoint name=’e’ binding=’t:b’
address=’http://ws.example.com/service1/’ />

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-06-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 [p.56] 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 [p.17] .

The instance data [p.40] 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 [p.70] ].
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 [IETF RFC 3023
[p.69] ], or a media type compatible with application/xml as specified in section 6.4.3.1
Serialization rules for XML messages [p.43] . † [p.79] 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 [p.56] 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 [p.17] .

62
 6.8 Serialization Format of Instance Data

This format is for legacy compatibility to permit the use of XForms clients with [IETF RFC 2388 [p.69] ]
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 [p.18] , i.e. this serialization format may only be used to serialize the HTTP request corresponding to
the initial message of an interface operation. † [p.79]

Specifically, for the HTTP binding defined in this section (6. WSDL HTTP Binding Extension [p.39] ),
"multipart/form-data" MAY be used as a serialization format [p.42] for an input message (HTTP Request),
but MUST NOT be used as a serialization format [p.42] for an output or fault message (HTTP
Response). † [p.79] 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. † [p.80]

2. The Content-Type header MUST have the value: † [p.80]

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 [p.62] .

The instance data [p.40] MUST NOT contain elements with an xs:nil attribute whose value is "true". †
[p.80]

Example 6-4. Example of multipart/form-data

The following instance data of an input message:

<data>
<town>
<name>Fréjus</name>
<country>France</country>
</town>
<date>2007-06-26</date>
</data>

with the following operation element:

63
 6.9 Specifying the Content Encoding

<operation ref=’t:data’
whttp:location=’temperature’
whttp:method=’POST’
whttp:inputSerialization=’multipart/form-data’/>

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

<town>
<name>Fréjus</name>
<country>France</country>
</town>
--AaB03x
Content-Disposition: form-data; name="date"
Content-Type: text/plain; charset=utf-8

2007-06-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 [p.69] ], 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 [p.70] ]):

{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.

64
 6.9 Specifying the Content Encoding

{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
[p.64] } 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

<description>
<binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
whttp:contentEncodingDefault="xs:string"? >

<fault ref="xs:QName"
whttp:contentEncoding="xs:string"? >
</fault>*

<operation location="xs:anyURI"?
whttp:contentEncodingDefault="xs:string"? >
<input messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"? />

<output messageLabel="xs:NCName"?
whttp:contentEncoding="xs:string"? />

</operation>
</binding>
</description>

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

65
 6.10 Specifying the Use of HTTP Cookies

6.9.4 Mapping from XML Representation to Component Properties

See Table 6-8 [p.66] .

Table 6-8. Mapping from XML Representation to Interface Message Reference component Extension
Properties
Property Value
{http content encoding default The actual value of the whttp:contentEncodingDefault
[p.64] } of the Binding attribute information item of the binding element information item, if
component present.
{http content encoding default The actual value of the whttp:contentEncodingDefault
[p.64] } of the Binding attribute information item of the operation element information item,
Operation component if present.
{http content encoding [p.65] The actual value of the whttp:contentEncoding attribute
} of the Binding Message information item of the input or output element information item, if
Reference component present.
{http content encoding [p.65]
The actual value of the whttp:contentEncoding attribute
} of the Binding Fault
information item of the fault element information item, if present.
component

6.10 Specifying the Use of HTTP Cookies

6.10.1 Description
The {http cookies [p.66] } property allows Binding components to indicate that HTTP cookies (as defined
by [IETF RFC 2965 [p.69] ]) 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 [p.70] ]):

{http cookies} REQUIRED. A xs:boolean to the Binding component.

6.10.3 XML Representation

<description>
<binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
whttp:cookies="xs:boolean"? >
</binding>
</description>

66
 6.11 Specifying HTTP Access Authentication

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 [p.67] .

Table 6-9. Mapping from XML Representation to Binding component Extension Properties
Property Value
The actual value of the whttp:cookies attribute information item; otherwise,
{http cookies
"false". A value of "true" means that the service relies on cookies and that the client
[p.66] }
MUST understand them. † [p.77]

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 [p.69] ]) 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 [p.70] ]):

{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 [p.69] ], and "digest" indicates the Digest Access
Authentication scheme as defined in [IETF RFC 2617 [p.69] ].

{http authentication realm} OPTIONAL. A xs:string to the Endpoint component. It corresponds to

the realm authentication parameter defined in [IETF RFC 2617 [p.69] ]. If the {http authentication
scheme [p.67] } property is present, then this property MUST be present. † [p.76]

67
 6.11 Specifying HTTP Access Authentication

6.11.3 XML Representation

<description>
<service>
<endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"? >
whttp:authenticationScheme="xs:token"?
whttp:authenticationRealm="xs:string"? />
</endpoint>
</service>
</description>

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 [p.68] .

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 [p.67] }
{http The actual value of the whttp:authenticationRealm attribute information
authentication item, if present; otherwise, if the whttp:authenticationScheme attribute
realm [p.67] } information item is present, "" (the empty value).

68
 7. References

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 items, 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, March 1997. Available at http://www.ietf.org/rfc/rfc2119.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.

69
 7.1 Normative References

[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.
[IETF RFC 4234]
Augmented BNF for Syntax Specifications: ABNF, D. Crocker, P. Overell, Authors. Internet
Engineering Task Force, October 2005. Available at http://www.ietf.org/rfc/rfc4234.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, J-J.
Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language"
Recommendation is available is available at http://www.w3.org/TR/2007/REC-wsdl20-20070626.
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, et al., Editors. World
Wide Web Consortium, 24 June 2003, revised 27 April 2007. This version of the "SOAP Version 1.2
Part 1: Messaging Framework (Second Edition)" Recommendation is
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. 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, et al., Editors. World Wide Web
Consortium, 24 June 2006, revised 27 April 2007. This version of the "SOAP Version 1.2 Part 2:
Adjuncts (Second Edition)" Recommendation is
http://www.w3.org/TR/2007/REC-soap12-part2-20070427/. 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 (Fourth Edition), T. Bray, J. Paoli, C. M.
Sperberg-McQueen, E. Maler, and F. Yergeau, Editors. World Wide Web Consortium, 10 February
1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is
http://www.w3.org/TR/2006/REC-xml-20060816/. 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.

70
 7.2 Informative References

[XML Information Set]

XML Information Set (Second Edition), J. Cowan and R. Tobin, Editors. World Wide Web
Consortium, 24 October 2001, revised 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, 2 May 2001, revised 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, 2 May 2001, revised 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 (Second Edition), J. Boyer, et al., Editors. World Wide Web Consortium, 14 October
2003, revised 14 March 2006. This version of the XForms 1.0 Recommendation is
http://www.w3.org/TR/2006/REC-xforms-20060314/. 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, T. Rogers, Editors. World Wide Web
Consortium, 9 May 2006. This version of Web Services Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. 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 June 2007. This version of the "Web Services Description
Language (WSDL) Version 2.0 Part 0: Primer" Recommendation is available at
http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626. 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 June 2007. This version of the "Web Services Description
Language (WSDL) Version 2.0: Additional MEPs" Working Group Note is available is available at
http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626. 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

71
 A. Acknowledgements (Non-Normative)

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/.
[XPointer]
XPointer Framework,Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh, Editors. World Wide
Web Consortium, 25 March 2003. This version of the XPointer Framework Proposed
Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version
of XPointer Framework is available at http://www.w3.org/TR/xptr-framework/.

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): Charlton Barreto
(Adobe Systems, Inc), Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen
Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of
Maryland), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet
(Canon), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe Systems), Anish Karmarkar (Oracle
Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria),
Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C), Michael Liddy (Education.au Ltd.),
Kevin Canyang Liu (SAP AG), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine
Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone
Commerce), Jean-Jacques Moreau (Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA
Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA
Technologies), Michael Shepherd (Xerox), Asir Vedamuthu (Microsoft Corporation), Sanjiva
Weerawarana (WSO2), Ümit Yalç&#305;nalp (SAP AG), Peter Zehler (Xerox).

Previous members were: Eran Chinthaka (WSO2), Mark Nottingham (BEA Systems, Inc.), Hugo Haas
(W3C), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), Lily Liu (webMethods,
Inc.), Don Wright (Lexmark), Joyce Yang (Oracle Corporation), Daniel Schutzer (Citigroup), Dave Solo
(Citigroup), Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox), Stephen White (SeeBeyond),
Barbara Zengler (DaimlerChrysler Research and Technology), Tim Finin (University of Maryland),
Laurent De Teneuille (L’Echangeur), Johan Pauhlsson (L’Echangeur), Mark Jones (AT&T), Steve Lind
(AT&T), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret (W3C),
Jim Hendler (University of Maryland), Dietmar Gaertner (Software AG), Michael Champion (Software
AG), Don Mullen (TIBCO Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke (Global
Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks & Associates), Ingo Melzer
(DaimlerChrysler Research and Technology), Sandeep Kumar (Cisco Systems), Alan Davies
(SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic Data Systems), Mike Davoren (W.
W. Grainger), Dan Kulp (IONA Technologies), Mike McHugh (W. W. Grainger), Michael Mealling
(Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland (BEA Systems, Inc.), Ümit
Yalç&#305;nalp (Oracle Corporation), Peter Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer
(Microsoft Corporation), Hao He (The Thomson Corporation), Erik Ackerman (Lexmark), Jerry Thrasher
(Lexmark), Prasad Yendluri (webMethods, Inc.), William Vambenepe (Hewlett-Packard Company),
David Booth (W3C), Sanjiva Weerawarana (IBM), Asir Vedamuthu (webMethods, Inc.), Igor Sedukhin

72
 B. Component Summary (Non-Normative)

(Computer Associates), Martin Gudgin (Microsoft Corporation), Rebecca Bergersen (IONA

Technologies), Ugo Corda (SeeBeyond).

The people who have contributed to discussions on [email protected] are also gratefully
acknowledged.

B. Component Summary (Non-Normative)

Table B-1 [p.73] 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 [p.64] }, {http cookies [p.66] }, {http method
default [p.46] }, {http query parameter separator default [p.46] }, {soap mep
Binding
default [p.27] }, {soap modules [p.28] }, {soap underlying protocol [p.24] }, {soap
version [p.23] }
{http content encoding [p.65] }, {http error status code [p.54] }, {http headers
Binding Fault [p.51] }, {soap fault code [p.25] }, {soap fault subcodes [p.25] }, {soap headers
[p.32] }, {soap modules [p.28] }
Binding Fault
{soap modules [p.29] }
Reference
Binding Message {http content encoding [p.65] }, {http headers [p.50] }, {soap headers [p.31] },
Reference {soap modules [p.28] }
{http content encoding default [p.64] }, {http fault serialization [p.46] }, {http
input serialization [p.46] }, {http location [p.46] }, {http location ignore uncited
Binding Operation [p.60] }, {http method [p.46] }, {http output serialization [p.46] }, {http query
parameter separator [p.47] }, {soap action [p.27] }, {soap mep [p.27] }, {soap
modules [p.28] }
Endpoint {http authentication realm [p.67] }, {http authentication scheme [p.67] }
HTTP Header
{name [p.51] }, {parent [p.51] }, {required [p.51] }, {type definition [p.51] }
[p.51]
Interface Operation {rpc signature [p.15] }, {safe [p.12] }
SOAP Header {element declaration [p.32] }, {mustUnderstand [p.32] }, {parent [p.32] },
Block [p.32] {required [p.32] }
SOAP Module
{parent [p.29] }, {ref [p.29] }, {required [p.29] }
[p.29]
Property Where Defined

73
 B. Component Summary (Non-Normative)

element
SOAP Header Block.{element declaration [p.32] }
declaration
http authentication
Endpoint.{http authentication realm [p.67] }
realm
http authentication
Endpoint.{http authentication scheme [p.67] }
scheme
http content Binding Fault.{http content encoding [p.65] }, Binding Message Reference.{http
encoding content encoding [p.65] }
http content Binding.{http content encoding default [p.64] }, Binding Operation.{http content
encoding default encoding default [p.64] }
http cookies Binding.{http cookies [p.66] }
http error status
Binding Fault.{http error status code [p.54] }
code
http fault
Binding Operation.{http fault serialization [p.46] }
serialization
Binding Fault.{http headers [p.51] }, Binding Message Reference.{http headers
http headers
[p.50] }
http input
Binding Operation.{http input serialization [p.46] }
serialization
http location Binding Operation.{http location [p.46] }
http location ignore
Binding Operation.{http location ignore uncited [p.60] }
uncited
http method Binding Operation.{http method [p.46] }
http method default Binding.{http method default [p.46] }
http output
Binding Operation.{http output serialization [p.46] }
serialization
http query
parameter Binding Operation.{http query parameter separator [p.47] }
separator
http query
parameter Binding.{http query parameter separator default [p.46] }
separator default
mustUnderstand SOAP Header Block.{mustUnderstand [p.32] }
name HTTP Header.{name [p.51] }

74
 C. Assertion Summary (Non-Normative)

HTTP Header.{parent [p.51] }, SOAP Header Block.{parent [p.32] }, SOAP

parent
Module.{parent [p.29] }
ref SOAP Module.{ref [p.29] }
HTTP Header.{required [p.51] }, SOAP Header Block.{required [p.32] }, SOAP
required
Module.{required [p.29] }
rpc signature Interface Operation.{rpc signature [p.15] }
safe Interface Operation.{safe [p.12] }
soap action Binding Operation.{soap action [p.27] }
soap fault code Binding Fault.{soap fault code [p.25] }
soap fault subcodes Binding Fault.{soap fault subcodes [p.25] }
Binding Fault.{soap headers [p.32] }, Binding Message Reference.{soap headers
soap headers
[p.31] }
soap mep Binding Operation.{soap mep [p.27] }
soap mep default Binding.{soap mep default [p.27] }
Binding.{soap modules [p.28] }, Binding Fault.{soap modules [p.28] }, Binding
soap modules Fault Reference.{soap modules [p.29] }, Binding Message Reference.{soap
modules [p.28] }, Binding Operation.{soap modules [p.28] }
soap underlying
Binding.{soap underlying protocol [p.24] }
protocol
soap version Binding.{soap version [p.23] }
type definition HTTP Header.{type definition [p.51] }

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
[p.13] properties:

75
 C. Assertion Summary (Non-Normative)

Additionally, each even-numbered item (0, 2, 4, ...) in the list MUST be of

WRPC-2050 [p.17] 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
[p.10] rulesets.
HTTPAccessAuthentication-2127 If the {http authentication scheme [p.67] } property is present,
[p.67] then this property MUST be present.
When formulating the HTTP message to be transmitted, the HTTP
HTTPBinding-2083 [p.41] request method used MUST be selected using one of the
following:
When formulating the HTTP message to be transmitted, content
HTTPBinding-2084 [p.42] encoding for a given Binding Message Reference component is
determined as follows:
When formulating the HTTP fault message to be transmitted,
HTTPBinding-2085 [p.42] 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 [p.42] body) MUST be what is defined by the corresponding Interface
Message Reference or Interface Fault components, serialized as
specified by the serialization format [p.42] used.
If the value is "#none", then the payload MUST be empty and the
value of the corresponding serialization property ({http input
HTTPBinding-2087 [p.43]
serialization [p.46] } or {http output serialization [p.46] }) 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 2.0 Core Language
HTTPBinding-2088 [p.43]
[p.70] ]), 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 {message content
HTTPBinding-2089 [p.43] model} is either "#element" or "#any", AND the serialization rules
for fault messages, are as follows:

76
 C. Assertion Summary (Non-Normative)

The fault definition SHOULD agree with the definition of the

HTTPBindingFault-2105 [p.54] HTTP error codes, as specified in section 8 of [IETF RFC 3205
[p.69] ].
An integer value of this property identifies the error Status-Code
HTTPBindingFault-2106 [p.54] as defined by [IETF RFC 2616 [p.69] ] 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 [p.46]
HTTPBindingOperation-2093
} property of the Binding Operation component, resolved using the
[p.45]
value of the {address} property of the Endpoint component (see
section 5 of [IETF RFC 3986 [p.69] ]).
HTTPBindingOperation-2094 The first one is transmitted using an HTTP request, and the second
[p.46] one is transmitted using the corresponding HTTP response.
HTTPBindingOperation-2095 In cases where only one single message is being sent, the message
[p.46] body of the HTTP response MUST be empty.
HTTPBindingOperation-2098 It MUST contain an IRI reference and MUST NOT include a
[p.46] fragment identifier component.
HTTPBindingOperation-2100 The value of the serialization format [p.42] used for a message is a
[p.47] media type which MUST be covered by this range.
Wild cards (for example, "application/*") SHOULD NOT be used
HTTPBindingOperation-2101
in this attribute information item since they may lead to
[p.47]
interoperability problems.
A value of "true" means that the service relies on cookies and that
HTTPCookies-2126 [p.67]
the client MUST understand them.
If the {http headers [p.50] } property as defined in section 6.6
Declaring HTTP Headers [p.50] exists and is not empty in a
Binding Message Reference or Binding Fault component, HTTP
HTTPHeader-2090 [p.44]
headers conforming to each HTTP Header [p.51] component
contained in this {http headers [p.50] } property MAY be
serialized as follows:
The HTTP binding MUST NOT set an HTTP header field
corresponding to the value of the {name [p.51] } property already
HTTPHeader-2091 [p.45]
set by another mechanism, such as the HTTP stack or another
feature.
If the value of an HTTP Header [p.51] component’s {required
HTTPHeader-2092 [p.45] [p.51] } property is "true", the inclusion of this HTTP header field
is REQUIRED

77
 C. Assertion Summary (Non-Normative)

A Binding Message Reference or a Binding Fault component’s

{http headers [p.50] } property MUST NOT contain multiple
HTTPHeader-2102 [p.51]
HTTP Header [p.51] components with the same {name [p.51] }
property.
HTTPHeader-2103 [p.51] This type MUST be a simple type.
If the value is "true", then the HTTP header field MUST be
HTTPHeader-2104 [p.51]
included in the message.
The instance data [p.40] MUST NOT contain elements with an
HTTPQueryString-2115 [p.59]
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 [p.60] } is
"true", any element NOT cited in the {http location [p.46] }
HTTPQueryString-2116 [p.60] 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 [p.46] }, {http output
serialization [p.46] } and {http fault serialization [p.46] }
properties is similar to the value allowed for the Accept HTTP
HTTPSerialization-2099 [p.47]
header defined by the HTTP 1.1 specification, Section 14.1 (see
[IETF RFC 2616 [p.69] ]) and MUST follow the production rules
defined in that section except for the following:
The {http location [p.46] } property MUST conform to the
HTTPSerialization-2106 [p.57] following EBNF [ISO/IEC 14977:1996 [p.69] ] grammar, which
represents the patterns for constructing the request IRI:
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
HTTPSerialization-2107 [p.56] IRI Style [p.17] , and if the {http location [p.46] } property of the
Binding Operation component is present, the value of the {http
location [p.46] } property component is used as a template
The resulting IRI MUST be mapped to an URI for use in the
HTTPSerialization-2108 [p.56] HTTP Request as per section 3.1 "Mapping of IRIs to URIs" of the
IRI specification [IETF RFC 3987 [p.70] ].
The local name in a template SHOULD match at least one element
HTTPSerialization-2109 [p.57]
from the instance data [p.40] of the input message.

78
 C. Assertion Summary (Non-Normative)

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
HTTPSerialization-2111 [p.58]
[p.17] , 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 [p.39] ),
"application/x-www-form-urlencoded" MAY be used as a
HTTPSerialization-2112 [p.58]
serialization format [p.42] for an input message (HTTP Request),
but MUST NOT be used as a serialization format [p.42] for an
output or fault message (HTTP Response).
If not all elements from the instance data [p.40] are cited in the
{http location [p.46] } property, or if the property is not present on
HTTPSerialization-2113 [p.59]
the Binding Operation component, then additional serialization
rules apply.
For elements of the instance data not cited in the {http location
HTTPSerialization-2114 [p.59]
[p.46] } property, a query string is constructed as follows.
If the HTTP request method used does not allow HTTP message
body (e.g. "GET" and "DELETE"), and if the value of the {http
HTTPSerialization-2117 [p.61]
location ignore uncited [p.60] } property is "false", then the
following rules apply.
If the HTTP request method used does allow an HTTP message
HTTPSerialization-2118 [p.61]
body (e.g. "POST" and "PUT"), then the following rules apply.
The Content-Type HTTP header field must have the value
HTTPSerialization-2119 [p.62]
application/x-www-form-urlencoded.
The Content-Type HTTP header MUST have the value
application/xml [IETF RFC 3023 [p.69] ], or a media type
HTTPSerialization-2120 [p.62]
compatible with application/xml as specified in section
6.4.3.1 Serialization rules for XML messages [p.43] .
this serialization format may only be used to serialize the HTTP
HTTPSerialization-2121 [p.63] request corresponding to the initial message of an interface
operation.
Specifically, for the HTTP binding defined in this section (6.
WSDL HTTP Binding Extension [p.39] ), "multipart/form-data"
HTTPSerialization-2122 [p.63] MAY be used as a serialization format [p.42] for an input message
(HTTP Request), but MUST NOT be used as a serialization format
[p.42] for an output or fault message (HTTP Response).

79
 C. Assertion Summary (Non-Normative)

The Content-Disposition header MUST have the value

HTTPSerialization-2123 [p.63] form-data, and its name parameter is the local name of the
element.
HTTPSerialization-2124 [p.63] The Content-Type header MUST have the value:
The instance data [p.40] MUST NOT contain elements with an
HTTPSerialization-2125 [p.63]
xs:nil attribute whose value is "true".
When using this style, the value of the {message content model}
property of the Interface Message Reference component
IRIStyle-2051 [p.18]
corresponding to the initial message of the message exchange
pattern MUST be "#element".
IRIStyle-2052 [p.18] The sequence MUST only contain elements.
IRIStyle-2053 [p.18] The sequence MUST contain only local element children.
The localPart of the element’s QName MUST be the same as the
IRIStyle-2054 [p.18]
Interface Operation component’s {name}.
The complex type that defines the body of the element or its
IRIStyle-2055 [p.18]
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
IRIStyle-2056 [p.18]
xs:QName, xs:NOTATION, xs:hexBinary or
xs:base64Binary.
The in-only message exchange pattern consists of exactly one
InOnlyComposition-2012 [p.11]
message as follows:
The in-out message exchange pattern consists of exactly two
InOutComposition-2015 [p.11]
messages, in order, as follows:
InterfaceOperation-2096 [p.46] 202 when the MEP is "http://www.w3.org/ns/wsdl/in-only"
InterfaceOperation-2097 [p.46] 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 Interface Message Reference component
MultipartStyle-2057 [p.18]
corresponding to the initial message of the message exchange
pattern MUST be "#element".
MultipartStyle-2058 [p.18] The sequence MUST only contain elements.
MultipartStyle-2059 [p.19] The sequence MUST contain only local element children.
The attributes minOccurs and maxOccurs for these child
MultipartStyle-2060 [p.19]
elements MUST have a value 1.

80
 C. Assertion Summary (Non-Normative)

The localPart of the element’s QName MUST be the same as the

MultipartStyle-2061 [p.19]
Interface Operation component’s {name}.
The complex type that defines the body of the element or its
MultipartStyle-2062 [p.19]
children elements MUST NOT contain any attributes.
The sequence MUST NOT contain multiple children element
MultipartStyle-2063 [p.19]
declared with the same local name.
However, an operation SHOULD be marked safe if it meets the
OperationSafety-2027 [p.12] criteria for a safe interaction defined in Section 3.4 of [Web
Architecture [p.70] ].
If the RPC style is used by an Interface Operation component then
its {message exchange pattern} property MUST have the value
RPCStyle-2029 [p.14]
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
RPCStyle-2030 [p.14] Interface Message Reference components of the {interface
message references} property MUST be "#element".
The content model of input and output {element declaration}
RPCStyle-2031 [p.14] elements MUST be defined using a complex type that contains a
sequence from XML Schema.
The input sequence MUST only contain elements and element
RPCStyle-2032 [p.14]
wildcards.
The input sequence MUST NOT contain more than one element
RPCStyle-2033 [p.14]
wildcard.
The element wildcard, if present, MUST appear after any
RPCStyle-2034 [p.14]
elements.
RPCStyle-2035 [p.14] The output sequence MUST only contain elements.
Both the input and output sequences MUST contain only local
RPCStyle-2036 [p.14]
element children.
The local name of input element’s QName MUST be the same as
RPCStyle-2037 [p.14]
the Interface Operation component’s name.
RPCStyle-2038 [p.14] Input and output elements MUST both be in the same namespace.
The complex type that defines the body of an input or an output
RPCStyle-2039 [p.14]
element MUST NOT contain any local attributes.
If elements with the same qualified name appear as children of
RPCStyle-2040 [p.14] both the input and output elements, then they MUST both be
declared using the same named type.

81
 C. Assertion Summary (Non-Normative)

The input or output sequence MUST NOT contain multiple

RPCStyle-2041 [p.14]
children elements declared with the same name.
RobustInOnlyComposition-2013 The robust-in-only message exchange pattern consists of
[p.11] exactly one message as follows:
A xs:anyURI, which is an absolute IRI as defined by [IETF RFC
SOAPAction-2075 [p.27]
3987 [p.70] ], 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 [p.22] 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 of
SOAPBinding-2068 [p.22] [WSDL 2.0 Core Language [p.70] ]), then additional binding rules
MUST be defined to indicate how to map those components into
the SOAP envelope.
Every SOAP binding MUST indicate what version of SOAP is in
SOAPBinding-2069 [p.23]
use for the operations of the interface that this binding applies to.
Every SOAP binding MUST indicate what underlying protocol is
SOAPBinding-2070 [p.24]
in use.
For every Interface Fault component contained in an Interface
SOAPBindingFault-2071 [p.25]
component, a mapping to a SOAP Fault MUST be described.
when the value of the {soap version [p.23] } is "1.2", the allowed
SOAPBindingFault-2072 [p.25] QNames MUST be the ones defined by [SOAP 1.2 Part 1:
Messaging Framework (Second Edition) [p.70] ], section 5.4.6
These properties MUST NOT be used unless the underlying
SOAPHTTPProperties-2064 [p.19]
protocol is HTTP.
This default binding rule is applicable when the value of the {soap
underlying protocol [p.24] } 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
SOAPHTTPSelection-2082 [p.36]
"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".

82
 C. Assertion Summary (Non-Normative)

When its value is "true", the SOAP header block MUST be

decorated with a SOAP mustUnderstand attribute information
SOAPHeaderBlock-2077 [p.32] item with a value of "true"; if so, the XML element declaration
referenced by the {element declaration [p.32] } property MUST
allow this SOAP mustUnderstand attribute information item.
If the value is "true", then the SOAP header block MUST be
SOAPHeaderBlock-2078 [p.32]
included in the message.
The value of the element attribute information item MUST
SOAPHeaderBlock-2079 [p.34] resolve to a global element declaration from the {element
declarations} property of the Description component.
A xs:anyURI, which is an absolute IRI as defined by [IETF RFC
SOAPMEP-2074 [p.27]
3987 [p.70] ], to the Binding Operation component.
A xs:anyURI, which is an absolute IRI as defined by [IETF RFC
SOAPMEPDefault-2073 [p.27]
3987 [p.70] ], 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 [p.27] }
property has a value, then the SOAP MEP is the value of the {soap
mep [p.27] } property. Otherwise, the SOAP MEP is the value of
the Binding component’s {soap mep default [p.27] }, if any.
SOAPMEPSelection-2080 [p.36] 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)
[p.70] ].
A xs:anyURI, which is an absolute IRI as defined by [IETF RFC
SOAPModule-2076 [p.29]
3987 [p.70] ].
WRPC-2042 [p.15] OPTIONAL, but MUST be present when the style is RPC
Values for the second component MUST be chosen among the
WRPC-2043 [p.15]
following four: "#in", "#out", "#inout" "#return".
The value of the first component of each pair (q, t) MUST be
WRPC-2044 [p.15]
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
WRPC-2045 [p.15] 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.

83
 C. Assertion Summary (Non-Normative)

For each pair (q, #in), there MUST be a child element of the input
WRPC-2046 [p.15] 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
WRPC-2047 [p.15] 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
WRPC-2048 [p.15] 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
WRPC-2049 [p.15] output element with a 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 templates) MUST
HTTPSerialization-2110 [p.57]
NOT carry an xs:nil attribute whose value is "true"
If any, the value of the SOAP "Detail" element MUST be the
SOAP12Binding-SOAPDetail-2081
element information item identified by the {element declaration}
[p.36]
property of the Interface Fault component.
SOAPBinding-2066 [p.22] If the value is "#none", then the payload MUST be empty.
If the value is "#element", then the payload MUST be the
SOAPBinding-2067 [p.22] element information item identified by the {element declaration}
property of the Interface Message Reference component.

84
 C. Assertion Summary (Non-Normative)

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 otherwise specified by an extension or
FaultDelivery-2008 [p.10]
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 [p.10] 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
FaultPropagation-2003 [p.10] accordance with the governing ruleset, but it is understood that any
delivery of a network message is best effort, not guaranteed.
When a fault is generated, the generating node MUST attempt to
FaultPropagation-2004 [p.10] propagate the fault, and MUST do so in the direction and to the recipient
specified by the ruleset.
When the Fault Replaces Message propagation rule is in effect, any
FaultReplacesMessage-2007
message after the first in the pattern MAY be replaced with a fault
[p.10]
message, which MUST have identical direction.
The in-only message exchange pattern uses the rule 2.2.3 No Faults
InOnlyFaults-2013 [p.11]
propagation rule [p.10] .
The in-out message exchange pattern uses the rule 2.2.1 Fault
InOutFaults-2016 [p.12]
Replaces Message propagation rule [p.10] .
by some prior agreement, another node and/or the service MAY send
MEPDescriptiveness-2002
messages (to each other or to other nodes) that are not described by the
[p.8]
pattern.
MEPTermination-2006 [p.10] Generation of a fault, regardless of ruleset, terminates the exchange.
When the Message Triggers Fault propagation rule is in effect, any
MessageTriggersFault-2009
message, including the first in the pattern, MAY trigger a fault message,
[p.10]
which MUST have opposite direction.
When the No Faults propagation rule is in effect, faults MUST NOT be
NoFaults-2011 [p.10]
propagated.
A node MAY be accessible via more than one physical address or
NodeIdentity-2001 [p.8]
transport.
RobustInOnlyFaults-2014 The robust in-only message exchange pattern uses the rule 2.2.2
[p.11] Message Triggers Fault propagation rule [p.10] .

85