SOAP Version 1.2 Part 2: Adjuncts

1 Introduction

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. The SOAP specification is divided into two parts. Part 1 [1] defines the SOAP messaging framework consisting of the SOAP message construct, the SOAP processing model, and the SOAP underlying protocol binding framework. Part 2 (this document) defines a set of adjuncts that may be used with the SOAP messaging framework:

The SOAP Data Model represents application-defined data as a directed, edge-labeled graph of nodes (see 2 The SOAP Data Model ).
The SOAP Encoding defines a set of rules for encoding instances of data that conform to the SOAP Data Model for inclusion in SOAP messages (see 3 SOAP Encoding ).
The SOAP RPC Representation defines a convention for how to use the SOAP Data Model for representing RPC calls and responses (see 4 SOAP RPC Representation ).
The SOAP HTTP Binding defines a binding of SOAP to HTTP [2] following the rules of the SOAP Protocol Binding Framework (see 7 SOAP HTTP Binding ).

Note:

In previous versions of this specification the SOAP name was an acronym. This is no longer the case.

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 [3] .

As a convention, the namespace prefixes "env" and "enc" used in the prose sections of this document are associated with the SOAP namespace names "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" respectively.

The namespace name "http://www.w3.org/2001/12/soap-envelope" is defined by Part 1 [1] . A normative XML Schema [4] , [5] document for the "http://www.w3.org/2001/12/soap-encoding" namespace can be found at http://www.w3.org/2001/12/soap-encoding .

As an additional convention, the namespace prefixes "xs" and "xsi" used in the prose sections of this document are associated with the namespace names "http://www.w3.org/2001/XMLSchema" and "http://www.w3.org/2001/XMLSchema-instance" respectively, both of which are defined in the XML Schemas specification [4] , [5] .

Note that for all the namespace conventions listed above, the choice of any namespace prefix is arbitrary and not semantically significant (see [10] ).

Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [6] .

This specification uses the Extended Backus-Naur Form (EBNF) as described in [8] .

With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.

2 The SOAP Data Model

The SOAP Data Model represents information as a directed, edge-labeled graph of nodes. Section 3 SOAP Encoding describes how to encode instances of data that conform to the data model for inclusion in SOAP messages. Section 4 SOAP RPC Representation defines a convention for how to use the data model for representing RPC calls and responses.

The purpose of the data model is not to introduce a programming model in SOAP but rather to provide a mapping of non-XML based instance data to some wire representation. It is important to note that use of the SOAP Data Model, the accompanying SOAP Encoding (see 3 SOAP Encoding ), and the SOAP RPC Representation (see 4 SOAP RPC Representation ) is optional. Applications which already model data in XML, for example using W3C XML Schema [4] ,[5] , may never have any need for using the SOAP Data Model. Because of the optionality of using the SOAP datamodel, the SOAP Encoding, and the SOAP RPC Representation, it is NOT a requirement to implement it as part of a SOAP node.

2.1 Graph Edges

An edge in the graph is said to originate at a node and terminate at a node. An edges that originates at a node is known as an outbound edge with respect to that node. An edge that terminates at a node is known as an inbound edge with respect to that node. An edge MAY originate and terminate at the same node.

2.1.1 Edge labels

A given outbound edge is identified either by label or by position, or both. Position is a total order on all the outbound edges of a given node; thus any outbound edge can be identified by postiion. An edge label is an XML Schema Qualified Name (QName). Two edge labels are equal if and only if both of the following are true:

Their local name values are the same.
Either of the following is true:
1. Their namespace name values are missing.
2. Their namespace name values are present and the same

(see XML Schema Datatypes[5] for more information about comparing QNames)

2.2 Graph Nodes

A node is either a terminal or a non-terminal. A non-terminal node has zero or more outbound edges. A terminal node has a lexical value and no outbound edges. Both types of node have an optional unique identifier (of type XML Schema ID) and an optional type name (of type XML Schema QName).

2.2.1 Single and Multi reference nodes

A node in the graph may be single or multi reference. A single reference node has a single inbound edge. A multi reference node has multiple inbound edges.

2.3 Values

A simple value is represented as a terminal node.

A compound value is represented as a non-terminal node as follows:

A non-terminal is known as a "generic" if the labels of its outbound edges need not be unique (i.e. if duplication of edge labels is allowed). Outbound edges of a generic MAY be distinguished by label and/or position, according to the needs of the application.
A non-terminal whose outbound edges are distinguished solely by label is known as a "struct".
A non-terminal whose outbound edges are distinguished solely by position is known as an "array". The outbound edges of an array MUST NOT be labelled.

3 SOAP Encoding

SOAP Encoding describes how to encode instances of data that conform to the data model described in 2 The SOAP Data Model for inclusion in SOAP messages. Note that nothing precludes the specification of different encodings based on other data models, or indeed that make different use of the SOAP Data Model.

The serialization rules defined in this section are identified by the URI "http://www.w3.org/2001/12/soap-encoding". SOAP messages using this particular serialization SHOULD indicate this using the SOAP encodingStyle attribute information item (see [1] SOAP Encoding Attribute ).

3.1 Rules for Encoding Graphs in XML

XML allows very flexible encoding of data. SOAP Encoding defines a narrower set of rules for encoding the graphs desribed in 2 The SOAP Data Model . This section defines the encoding at a high level, and the next section describes the encoding rules in more detail. The encodings described in this section can be used in conjunction with the mapping of RPC calls and responses specified in 4 SOAP RPC Representation .

To describe encoding, the following terminology is used:

Within a compound value (see 2.3 Values ) , if an outbound edge has a label that is based in part on a URI, directly or indirectly, such that the label of the outbound edge alone is sufficient to uniquely identify the outbound edge, the label is said to be "globally scoped"
Within a compound value (see 2.3 Values ), if an outbound edge has a label that is distinct within that compound value but is not distinct with respect to other values in the graph, that is, the label of the outbound edge and the compound value together are needed to make a unique identification, the label is said to be "locally scoped"

The encodings are described below from the perspective of a de-serializer. In each case, the presence of an XML serialization is presumed, and the mapping to a corresponding graph is described.

When serializing, more than one encoding is typically possible for a given graph. For example, the order in which multi-reference nodes are serialized is generally insignificant. When serializing a graph for transmission inside a SOAP message any representation that deserializes to the identical graph MAY be used; when receiving an encoded SOAP message, all representations MUST be accepted.

3.1.1 Encoding graph edges and nodes

Each graph edge is encoded as an element information item and each element information item represents a graph edge. 3.1.3 Encoding compound values describes the relationship between edge labels and the local name and namespace name properties of such element information items .

The node at which an edge terminates is determined as follows:

If the element information item representing the edge does not have a ref attribute information item (see 3.1.4.2 ref Attribute Information Item ) amongst its attributes then that element information item is said to represent a node in the graph and the edge terminates at that node.
If the element information item representing the edge does have a ref attribute information item (see 3.1.4.2 ref Attribute Information Item ), then the value of that attribute information item MUST be identical to the value of exactly one id attribute information item ( see 3.1.4.1 id Attribute Information Item ) in the same envelope. In this case the edge terminates at the node represented by the element information item on which the id attribute information item appears.

All nodes in the graph are encoded as described in 1 above. Additional inbound edges for multi reference nodes are encoded as described in 2 above.

3.1.2 Encoding simple values

The "lexical value" of a terminal graph node is the sequence of Unicode characters identified by the character information item children of the element information item representing that node.

3.1.3 Encoding compound values

An outbound edge of a node is encoded as an element information item child of the element information item that represents the node (see 3.1.1 Encoding graph edges and nodes ). Particular rules apply depending on what kind of compound value, "generic", "struct" or "array", the node represents:

For a graph edge which is distinguised by label ( "struct" or "generic" ), the namespace name property of the element information item determines whether the edge label is globally or locally scoped:
- If the namespace name is empty then the edge label is locally scoped.
- If the namespace name is not empty then the edge label is globally scoped. The namespace name is the URI part of the edge label.
The intepretation of the local name property of the element information item with respect to the edge label is as follows:
- If the edge label is locally scoped, the edge label is the same as the local name. (see A Mapping Application Defined Name to XML Name ).
- If the edge label is globally scoped, the non-URI part of the edge labl is the local name. (see A Mapping Application Defined Name to XML Name ).
For a graph edge which is distinguished by position ( "array" or "generic" ):
- The ordinal position of the graph edge corresponds to the position of the element information item relative to its siblings
- If outbound edges are distinguished only by position ("array") then the local name and namespace name properties of the element information item are not significant.
The following rules apply to the encoding of a node that represents an "array":
- The element information item representing an array nodeMAY have amongst its attributes an itemType attribute information item (see 3.1.5.1 itemType Attribute Information Item ).
- The element information item representing an array node MAY have amongst its attributes an arraySize attribute information item (see 3.1.6 arraySize Attribute Information Item ).
If a graph edge does not terminate in a graph node then it can either be omitted from the serialization or it can be encoded as an element information item with an xsi:nil attribute information item.

3.1.4 Unique identifiers

3.1.4.1 id Attribute Information Item

The id attribute information item has the following Infoset properties:

A local name of id;
A namespace name which is empty
A specified property with a value of "true".

The type of the id attribute information item is ID in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the id attribute information item is a unique identifier that can be refered to by a ref attribute information item (see 3.1.4.2 ref Attribute Information Item ).

3.1.4.2 ref Attribute Information Item

The ref attribute information item has the following Infoset properties:

A local name of ref;
A namespace name which is empty
A specified property with a value of true.

The type of the ref attribute information item is IDREF in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the ref attribute information item is a reference to a unique identifier defined by an id attribute information item (see 3.1.4.1 id Attribute Information Item ).

3.1.4.3 Constraints on id and ref attribute information items

The value of a ref attribute information item MUST also be the value of exactly one id attribute information item.

A ref attribute information item and an id attribute information item MUST NOT appear on the same element information item.

3.1.5 Computing the Type Name property

The type name property of a graph node is computed as follows;

If the element information item representing the graph node has an xsi:type attribute information item amongst its attributes then the type name property of the graph node is the value of the xsi:type attribute information item.

Note:

This attribute is of type QName; its value consists of the pair {namespace name, local name}. Neither the prefix used to construct the QName nor any information relating to any definition of the type is considered to be part of the value. The SOAP graph carries only the qualified name of the type.
Otherwise if the parent element information item of the element information item representing the graph node has a soap:itemType attribute information item (see 3.1.5.1 itemType Attribute Information Item ) amongst its attributes then the type name property of the graph node is the value of the soap:itemType attribute information item
Otherwise the value of the type name property of the graph node is unspecified.

Note:

The above rules define how the type name property of a node in a graph is computed from a serialized encoding. This specification does not mandate validation using any particular schema language or type system, includes no built in types and provides no standardized faults to be reflected in the case where the contents of an element might appear to be in conflict with the value of the type name.

However, nothing herein prohibits development of additional specifications that desribe the use of SOAP with particular schema languages or type systems. Such additional specifications MAY mandate validation using some particular schema language, and MAY specify faults to be generated should validation fail. Such additional specifications MAY specify augmentations to the deserialized graph based on information determined from such a validation. The use by SOAP of xsi:type is intended to facilitate integration with the W3C XML Schema language (see B Using W3C XML Schema with SOAP Encoding ). Other XML based schema languages, data schemas and programmatic type systems MAY be used but only to the extent that they are compatible with the serialization described in this specification.

3.1.5.1 itemType Attribute Information Item

The itemType attribute information item has the following Infoset properties:

A local name of itemType;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A specified property with a value of true.

The type of the itemType attribute information item is QName in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the itemType attribute information item is used to compute the type name property (see 3.1.5 Computing the Type Name property ) of members of an array.

3.1.6 arraySize Attribute Information Item

The arraySize attribute information item has the following Infoset properties:

A local name of arraySize ;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A default value of "*"

The type of the arraySize attribute information item is arraySize in the namespace named "http://www.w3.org/2001/12/soap-encoding".

Value of `enc:arraySize`

[1]	`arraySizeValue`	::=	`("" \| concreteSize) nextConcreteSize`
[2]	`nextConcreteSize`	::=	`" " concreteSize`
[3]	`concreteSize`	::=	`non negative integer`

Each item in the list of sizes represents the size of each of the array's dimensions (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list.

3.2 Decoding Faults

During deserialization a SOAP receiver:

SHOULD generate an env:Sender SOAP fault with a subcode of enc:MissingID if the message violates the constraints on id and ref attribute information items (see 3.1.4.3 Constraints on id and ref attribute information items ).
MAY generate an env:Sender SOAP fault with a subcode of enc:UntypedValue if the type name property of an encoded graph node is unspecified.

4 SOAP RPC Representation

One of the design goals of SOAP is to encapsulate remote procedure call functionality using the extensibility and flexibility of XML. This section defines a uniform representation of RPC requests and responses.

Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in 3 SOAP Encoding , other representations are possible. The SOAP encodingStyle attribute information item (see [1] SOAP Encoding Attribute ) can be used to indicate the encoding style of the RPC invocation and/or the response using the representation described in this section.

Use of the SOAP RPC Representation is orthogonal to the SOAP protocol binding. In the case of using HTTP as the protocol binding, an RPC invocation maps naturally to an HTTP request and an RPC response maps to an HTTP response. However, use of the SOAP RPC Representation is not limited to the SOAP HTTP Binding (see 7 SOAP HTTP Binding ).

To invoke an RPC, the following information is needed:

The URI of the target SOAP node
A procedure or method name
An optional procedure or method signature
The parameters to the procedure or method
Optional header data

SOAP relies on the protocol binding to provide a mechanism for carrying the URI. For example, for HTTP the request URI indicates the resource that the invocation is being made against. Other than it be a valid URI, SOAP places no restriction on the form of an address (see RFC2396 [6] for more information on URIs).

4.1 RPC and SOAP Body

RPC invocations and responses are both carried in the SOAP Body element (see [1] section SOAP Body ) using the following representation:

An RPC invocation is modeled as a struct where parameter access is by name or as an array where parameter access is by position.
The invocation is viewed as a single struct or array containing an outbound edge for each [in] or [in/out] parameter. The struct is named identically to the procedure or method name (see A Mapping Application Defined Name to XML Name ).
Each outbound edge either has a label corresponding to the name of the parameter (see A Mapping Application Defined Name to XML Name ) or a position corresponding to the position of the parameter.
An RPC response is modeled as a struct where parameter access is by name or as an array where parameter access is by position.
The response is viewed as a single struct or array containing an outbound edge for the return value and each [out] or [in/out] parameter. The return value outbound edge SHOULD be the first outbound edge.
Each outbound edge has a label corresponding to the name of the parameter (see A Mapping Application Defined Name to XML Name ) or a position corresponding to the position of the parameter. The label of the return value outbound edge is "result" and it is namespace-qualified with the namespace name "http://www.w3.org/2001/12/soap-rpc". The return value outbound edge MUST be present if the return value of the procedure is non-void. The return value outbound edge MUST NOT be present if the return value of the procedure is void.
Invocation faults are handled according to the rules in 4.3 RPC Faults . If a protocol binding adds additional rules for fault expression, those MUST also be followed.

As noted above, RPC invocation and response structs can be encoded according to the rules in 3 SOAP Encoding , or other encodings can be specified using the encodingStyle attribute information item (see [1] Encoding Attribute ).

Applications MAY process invocations with missing parameters but also MAY return a fault.

Because a result indicates success and a fault indicates failure, it is an error for an RPC response to contain both a result and a fault.

4.2 RPC and SOAP Header

Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in the RPC encoding. If so, it MUST be expressed as a header block.

4.3 RPC Faults

The SOAP RPC Representation introduces additional SOAP fault subcode values to the fault codes described in [1] section Fault Codes . The namespace name for these SOAP fault subcode values is "http://www.w3.org/2001/12/soap-rpc" and the namespace prefix rpc: is used in this section to indicate association with this namespace. A schema document for this namespace can be found at http://www.w3.org/2001/12/soap-rpc

Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):

A fault with a value of "env:Receiver" for faultcode SHOULD be generated when the receiver cannot handle the message because of some temporary condition, e.g. when it is out of memory.
A fault with a value of "env:DataEncodingUnknown" for faultcode SHOULD be generated when the arguments are encoded in a data encoding unknown to the receiver.
A fault with a value of "env:Sender" for faultcode and a value of "rpc:ProcedureNotPresent" for subcode MUST be generated when the receiver cannot find the procedure specified.
A fault with a value of "env:Sender" for faultcode and a value of "rpc:BadArguments" for subcode MUST be generated when the receiver cannot parse the arguments or when there is a mismatch between what the receiver expects and what the sender has sent.
Other faults arising in an extension or from the application SHOULD be generated as described in Part 1 [1] section SOAP Faults .

In all cases the values of the detail and faultstring element information items are implementation defined. They MAY be specified by some external document.

5 A Convention for Describing Features and Bindings

This section describes a convention involving properties and property values for describing Features (including MEPs) and Bindings. This convention is sufficient to describe the distributed states of Feature and Binding specifications as mandated by the Binding Framework (see SOAP Underlying Protocol Binding Framework ). This convention is used to describe a Single-Request-Response MEP 6.1 Single-Request-Response MEP and the SOAP HTTP Binding 7 SOAP HTTP Binding elsewhere in this document. Along with the convention itself, an informal model is defined that describes how properties propagate through a SOAP system. Note that this model is intended to be illustrative only, and is not meant to imply any constraints on the structure or layering of any particular SOAP implementation.

5.1 Model and Properties

In general, a SOAP message is the information that one SOAP Node wishes to exchange with another SOAP Node according to a particular set of features, including a MEP. In addition, there may be information essential to exchanging a message that is not part of the message itself. Such information is sometimes called message meta-data. In the model, the message, any message meta-data, and the various information items that enable features are represented as abstractions called properties.

5.1.1 Properties

Under the convention, properties are represented as follows:

Properties are named with XML qualified names (QNames). For example, myNS:RetryCount where RetryCount is the name of the property, and myNS is a prefix mapped to a namespace.
Property values are typed, and the type of a property-value is defined by an XML Schema simple datatype in the specification which introduces the property. For example, the type of RetryCount is xsi:int.

5.1.2 Property Scope

Model describing properties shared between SOAP and Binding

Properties within a SOAP Node can differ in terms of their scope and the origins of their values. Some properties are scoped per message-exchange, while others have a wider significance. For example, the scope of a SOAP message property is per message-exchange, but the scope of a User Identity property may extend beyond the exchange of a single message. The values of some properties arise directly from the operations of the SOAP Node and message exchanges, while others arise in implementation specific ways due to the local environment. In the figure above, we make the distinction between per message-exchange and more widely scoped properties by showing them in different containers called Message Exchange Context and Environment respectively. All properties, regardless of their scope, are shared by SOAP and a particular Binding.

However, the values of properties in Environment may depend upon local circumstances (as depicted by the external arrow from Environment in the figure above). More specifically, the properties in the example could be influenced by an Operating System User ID on whose behalf a message exchange is being executed. The mapping of information in a particular implementation to such properties is outside the scope of the binding framework although the abstract representation of such information as properties is not.

5.1.3 Properties and Features

Features may be enabled through multiple properties, and a single property may enable more than one feature. For example, the properties called User ID, Password may be used to enable a feature called Authentication. And for example, a single property called Message ID may be used to enable one feature called Transaction and a second feature called Message Correlation.

6 Message Exchange Patterns

A message exchange pattern is a template for the exchange of messages between SOAP Nodes supported by one or more underlying protocol binding instances.

This section is intended to act as a logical description of the operation of a MEP. It is not intended to describe a real implementation or to imply that a real implementation should be structured.

In general the definition of a message exchange pattern:

describes the lifecycle of an message exchange conforming to the pattern;
describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern;
describes the normal and abnormal termination of a message exchange conforming to the pattern.

Underlying protocol binding specifications may declare their support for one or more named message exchange patterns.

Message exchange patterns are named by URI.

A message exchange has a lifecycle governed by a message exchange pattern.

The following table describes the particular property definitions (in accordance with the property naming conventions defined in this document) which support the description of Message Exchange Patterns. Other properties may also be involved in the specification for particular MEPs, but these are generally applicable to all MEPs.

Editorial note: JJM/JBI 20020109

The following table refers to PatternSpecificRole. This has not been defined previously. Should this be single:Role instead?

Property definitions supporting the description of MEPs
Property Name	Property Decription
`context:ExchangePatternName`	A URI that names the message exchange pattern in operation.
`single:Role`	A URI that names the pattern specific role of the local SOAP Node with respect to the message exchange denoted by the enclosing property container.
`single:State`	A relative URI relative with a Base value carried in the PatternSpecificRole property which denotes the current state of the message exchange denoted by the enclosing property container. this value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange.
`context:FailureReason`	A URI value that denotes a pattern specific, binding independent reason for the failure of a message exchange. Underlying protocol binding specifications may define properties to convey more binding specific details of the failure.
`context:CurrentMessage`	An abstract structure that represents the current message in a message exchange. this abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope due to the action of the message exchange . The XML Infoset of the current SOAP message . Depending on pattern dependent state this may be an inbound or outbound message.
`context:ImmediateDestination`	A URI denoting the immediate destination of an outbound message.
`context:ImmediateSender`	A URI denoting the immediate sender of an inbound message.

6.1 Single-Request-Response MEP

This section defines the MEP "Single-Request-Response". The description is an abstract presentation of the operation of this MEP. It is not intended to describe a real implementation or to imply how a real implementation should be structured.

Editorial note: HFN	20020316
Clarify 'single' in 6.1 as meaning pair with no temporal aspect. Avoid duplication with 6.1.3

6.1.1 Message Exchange Pattern Name

This message exchange pattern is named by the URI "http://www.w3.org/2001/12/soap/mep/single-request-response/" abbreviated to "single-request-response" throughout this specification.

Underlying protocol binding specifications may use the full-name of this message exchange pattern to declare their support for the message exchange pattern and associated semantics described herein.

The following table lists the standard prefix mappings which we assume to hold throughout this section:

Editorial note: HFN	20020316
For the record in the log, Noah suggests the editors give some additional thought to the prefix "single". I think something like ReqResp, or SingleReqResp, or even SReqResp would be a bit more suggestive of what's going on.

Standard Prefix Mappings
Prefix	Namespace
context	"http://www.w3.org/2001/12/soap/bindingFramework/ExchangeContext/"
mep	"http://www.w3.org/2001/12/soap/mep/"
fail	"http://www.w3.org/2001/12/soap/mep/FailureReasons/"
single	"http://www.w3.org/2001/12/soap/mep/single-request-response/"

6.1.2 Informal Description

The single-request-response message exchange pattern defines a pattern for the exchange of two messages between two adjacent SOAP nodes along a SOAP Message Path. One message is exchanged in each direction between a Requesting SOAP Node and a Responding SOAP Node.

The normal operation of a message exchange conforming to the single-request-response exchange pattern is such that a Request Message is first transferred from Requesting SOAP Node to Responding SOAP Node. Following the successful processing of the Request Message by the Responding SOAP Node, a Response Message is then transferred from Responding SOAP Node to Requesting SOAP Node.

Abnormal operation of a message exchange conforming to the single-request-response exchange pattern may arise due to a failure to transfer the Request Message, a failure at the Responding SOAP Node to process the Request Message, or a failure to transfer the Response Message. Such failures MAY be silent at requesting, responding or both SOAP Node involved in the exchange. Also, under abnormal operation each SOAP Node involved in the message exchange MAY differ in their determination of the successful completion of the message exchange.

There is no implied timing relationship between contemporaneous exchanges conforming to this message exchange pattern, ie. nothing can be said about the relative temporal ordering of the transmission and reception of messages arising from distinct exchanges.

6.1.3 Formal Description

To initiate an message exchange conforming to the single-request-response message exchange pattern, the Requesting SOAP Node instantiates a local message exchange context. This context is initialised as follows:

Instantiation of a Message Exchange Context for a Requesting SOAP Node
Property Name URI	Value
`context:ExchangePatternName`	"http://www.w3.org/2001/12/soap/mep/single-request-response/"
`single:Role`	RequestingSOAPNode
`single:State`	Requesting
`context:FailureReason`	None
`context:CurrentMessage`	~~An abstraction of~~ The XML Infoset of the SOAP message that constitutes the Request Message
`context:ImmediateDestination`	An identifier (URI) that denotes the Responding SOAP Node

In addition other properties related to the operation of features to be used in conjunction with this particular instance of the message exchange are initialised in accordance with the relevant feature specification.

Once initialised control of the message exchange context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at requesting and responding SOAP Nodes during the lifetime of the message exchange. At each SOAP Node the value of the single:State property is updated (logically) to reflect the current state of the message exchange as perceived by the local binding instance. These state names are relative URIs, relative to a Base URI value carried in the single:Role property of the local message exchange context.

At the Responding SOAP Node a message exchange context is (logically) instantiated by the local binding instance when it starts to receive an inbound Request Message.

At the Responding SOAP Node a message exchange context is (logically)instantiated, in the Receiving state, by the local binding instance when it starts to receive an inbound Request Message.

Instantiation of Message Exchange Context for an inbound Request Message
Property Name	Value
`context:ExchangePatternName`	"http://www.w3.org/2001/12/soap/mep/single-request-response/" Initialised as early as possible during the lifecycle of the message exchange.
`single:Role`	RespondingSOAPNode Initialised as early as possible during the lifecycle the message exchange.
`single:State`	Receiving
`context:FailureReason`	None
`context:CurrentMessage`	NULL
`context:ImmediateSource`	An identifier (URI) that denotes the Requesting SOAP Node (if available)

Editorial note: JJM/TBTF - Awaiting text from Stuart	20011205
Incomplete tables for illustrative purposes. We are assuming the TBTF will provide adequate material.

Requesting SOAP Node State Transition Table
CurrentState	NextState	Action
Requesting	Fail	Set "context:FailureReason" to "transmissionFailure"
Requesting	Waiting
Waiting	Fail	Set "context:FailureReason" to "NoResponse"
Waiting	Receiving
Receiving	Fail	Set "context:FailureReason" to "ReceptionFailure"
Receiving	Success	Set "context:ImmediateSender" to denote the sender of the Response Message (may differ from the value in "context:ImmediateDestination") Replace "context:CurrentMessage" with ~~abstraction of~~ the XML Infoset of the SOAP message that constitutes the Response Message

Responding SOAP Node State transition table
CurrentState	NextState	Action
Receiving	Fail	Set "context:FailureReason" to "ReceptionFailure"
Receiving	Processing	Set "context:ImmediateSender" to denote the sender of the Request Message (if determinable) Set "context:CurrentMessage" with ~~abstraction representing~~ the XML Infoset of the SOAP message that constitutes the Request Message Pass control of message exchange context to SOAP Processor.
Processing	Fail	Set "context:FailureReason" to "NoResponse";
Processing	Responding	SOAP Processor has replaced "context:CurrentMessage" with ~~abstraction of~~ the XML Infoset of the SOAP message that constitutes the Response Message.; Initiate transmission of Response Message.
Responding	Fail	Set "context:FailureReason" to "transmissionFailure"
Responding	Success

6.1.4 Fault Handling

During the operation of the single-request-response message exchange pattern, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the Responding SOAP node while it is in the Processing state, the generated SOAP fault replaces the ~~abstraction of~~ XML Infoset of the SOAP message that constitutes the Response Message that is used to set the "context:CurrentMessage" property and the state machine transitions to the Responding state.

This MEP specification makes no claims as to the disposition or handling of SOAP faults generated by the Requesting SOAP node during the processing of the Response Message that follows the Success state in the Requesting SOAP node's state transition table.

7 SOAP HTTP Binding

7.1 Introduction

The SOAP HTTP Binding presented here provides a binding of SOAP to HTTP. This binding conforms to the SOAP Binding Framework (see [1] SOAP Protocol Binding Framework ) and uses abstract properties as a descriptive tool for defining the functionality of certain features.

The SOAP Protocol Binding Framework (see [1] SOAP Protocol Binding Framework ), Message Exchange Pattern Specifications (see 6 Message Exchange Patterns ) and Feature Specifications (see 5 A Convention for Describing Features and Bindings ) each describe the properties they expect to be present in a message exchange context when control of that context passes between the local SOAP Node and a binding instance.

Properties are named with XML qualified names (QNames). Property values are determined by the Schema type of the property, as defined in the specification which introduces the property. The following table lists the XML namespace prefix mappings that are used throughout this specification:

XML namespace prefix mappings
Prefix	Namespace
context	"http://www.w3.org/2001/12/soap/bindingFramework/ExchangeContext/"
mep	"http://www.w3.org/2001/12/soap/mep/"
fail	"http://www.w3.org/2001/12/soap/mep/FailureReasons/"
single	"http://www.w3.org/2001/12/soap/mep/single-request-response/"

HTTP applications MUST ~~use~~ support the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges using this binding. See [12] for parameters defined by this media type and their recommended usage.

Note:

Use of media types other than "application/soap+xml" is made possible by means of the Content Negotiation Feature defined in section 7.5.2 . However, the specification of the usage of any additional media types as applies to SOAP is outside the scope of this specification. Only use of the "application/soap+xml" media type for purposes of this binding can guarantee interoperability.

Note:

Use of the SOAP HTTP Binding is optional; nothing precludes the specification of different bindings to other protocols or other bindings to HTTP. Because of the optionality of using the SOAP HTTP Binding, it is NOT a requirement to implement it as part of a SOAP node. A node that does correctly and completely implement the HTTP binding may to be said to "conform to the SOAP 1.2 HTTP binding."

7.2 Binding Name

The binding described here is identified with the URI:

"http://www.w3.org/2001/12/soap/bindings/defaultHTTP/"

7.3 Supported Message Exchange Patterns

An implementation of the SOAP HTTP Binding MUST support the following message exchange pattern:

"http://www.w3.org/2001/12/soap/mep/single-request-response/" (see 6.1 Single-Request-Response MEP )

7.4 Single-Request-Reponse Message Exchange Operation

The "http://www.w3.org/2001/12/soap/mep/single-request-response/" message exchange pattern is described in 6.1 Single-Request-Response MEP .

For binding instances conforming to this specification:

A SOAP Node instantiated at an HTTP client may assume the role (i.e. the property single:Role) of RequestingSOAPNode.
A SOAP Node instantiated at an HTTP server may assume the role (ie. the property single:Role) of RespondingSOAPNode.

The remainder of this section describes the MEP state machine and its particular relation to the HTTP protocol. In the state tables below, the states are defined as values for the property single:State (see 6.1 Single-Request-Response MEP ), and are of type single:StateType (an enumeration over xs:string).

Failure reasons as specified in the tables represent values of the property context:FailureReason - their values are QNames. If an implementation enters the "Fail" state, the context:FailureReason property will contain the value specified for the particular transition.

7.4.1 Behaviour of Requesting SOAP Node

The overall flow of the behaviour of a Requesting SOAP Node follows the outline state machine description contained in 6.1 Single-Request-Response MEP . The following subsections describe each state in more detail.

7.4.1.1 Requesting

State Description: Requesting

Statename Requesting

Description Formulate and send HTTP Request (see table below)

Preconditions See 6.1.3 Formal Description

Postconditions None

Transitions Event/Condition NextState Failure Reason

Request successfully sent Waiting N/A

Failed to send request Fail fail:TransmissionFailure

State Description: Requesting
Statename	Requesting
Description	Formulate and send HTTP Request (see table below)
Preconditions	See 6.1.3 Formal Description
Postconditions	None
Transitions	Event/Condition	NextState	Failure Reason
Request successfully sent	Waiting	N/A
Failed to send request	Fail	`fail:TransmissionFailure`

HTTP Request Fields

Field Value

HTTP Method POST (the use of other HTTP methods is currently undefined in this binding).

Request URI The value of the URI carried in the context:ImmediateDestination property of the message exchange context.

Content-Type header "application/soap+xml" (see 7.1 Introduction ) (also see 7.5.2 Content Negotiation Feature )

Additional Headers Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange e.g. SOAPAction (see 7.5.1 SOAP Action ).

HTTP entity body XML 1.0 serialisation of the SOAP message XML Infoset carried in the context:CurrentMessage property of the message exchange context. This binding mandates support for UTF-8 and UTF-16.

HTTP Request Fields
Field	Value
HTTP Method	POST (the use of other HTTP methods is currently undefined in this binding).
Request URI	The value of the URI carried in the `context:ImmediateDestination` property of the message exchange context.
Content-Type header	"application/soap+xml" (see 7.1 Introduction ) (also see 7.5.2 Content Negotiation Feature )
Additional Headers	Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange e.g. `SOAPAction` (see 7.5.1 SOAP Action ).
HTTP entity body	XML 1.0 serialisation of the SOAP message XML Infoset carried in the `context:CurrentMessage` property of the message exchange context. This binding mandates support for UTF-8 and UTF-16.

7.4.1.2 Waiting

State Description: Waiting

Statename Waiting

Description Wait for HTTP Response

Preconditions None

Postconditions

Property context:ImmediateSender instantiated with a URI value that denotes the sender of the HTTP response (if known)

HTTP headers significant to features expressed outside the SOAP envelope processed in accordance with the relevant feature specification.

Transitions Event/Condition NextState Failure Reason

HTTP Response Status Line and HTTP Headers received (see status code table below) (see status code table below)

Reception Failure Fail fail:ReceptionFailure

State Description: Waiting
Statename	Waiting
Description	Wait for HTTP Response
Preconditions	None
Postconditions	Property `context:ImmediateSender` instantiated with a URI value that denotes the sender of the HTTP response (if known) HTTP headers significant to features expressed outside the SOAP envelope processed in accordance with the relevant feature specification.
Transitions	Event/Condition	NextState	Failure Reason
HTTP Response Status Line and HTTP Headers received	(see status code table below)	(see status code table below)
Reception Failure	Fail	`fail:ReceptionFailure`

The following table details the HTTP status code dependent transitions upon reception of an HTTP status line and response headers.

HTTP status code dependent transitions.

Status Code Reason phrase Significance/Action NextState

2xx Successful

200 OK
The Response Message follows in HTTP response entity body.
Receiving

202 Accepted
The Request Message has been received and processed. The entity body of the HTTP response MAY contain a Response Message.

204 No Content
The Request message has been received and processed. The HTTP response MUST NOT contain an entity body. The message exchange is regarded as having completed successfully.
Success

Instantiated Property Value

context:CurrentMessage "Empty" SOAP Envelope.

3xx Redirection
The requested resource has moved and the HTTP request SHOULD be retried using the URI carried in the associated Location header as the new value for the context:ImmediateDestination property.
Requesting

4xx Client Error

400 Bad Request
Indicates a problem with the received HTTP Request Message. This may include a malformed XML in the Request-Message envelope. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded has having completed unsuccessfully.
Fail

Instantiated Property Value

context:FailureReason fail:BadRequest

401 Unauthorized
Indicates that the HTTP Request requires authorization.
Requesting

Instantiated Property Value

context:FailureReason fail:AuthenticationFailure

If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the message exchange is regarded as having completed unsuccessfully.
Fail

Instantiated Property Value

context:FailureReason fail:AuthenticationFailure

405 Method not allowed
Indicates that the peer HTTP server does not support the requested HTTP method at the given request URI. The message exchange is regarded has having completed unsuccessfully.
Fail

Instantiated Property Value

context:FailureReason fail:BindingMismatch

415 Unsupported Media Type
Indicates that the peer HTTP server does not support Content-type used to encode the Request Message. The message exchange is regarded has having completed unsuccessfully.
Fail

Instantiated Property Value

context:FailureReason fail:BindingMismatch

427 SOAPAction Required
Indicates that the peer HTTP server implements the OPTIONAL SOAPAction feature and that it requires that this node provide a SOAPAction header when resubmitting a similar HTTP request. The message exchange is regarded has having completed unsuccessfully.

In requesting SOAP nodes that support the OPTIONAL SOAPAction feature, the behaviour described in 7.5.1 SOAP Action is applied.
Fail

5xx Server Error

500 Internal Server Error
Indicates that the Response Message contained in the following HTTP response entity body may contain an SOAP fault. Other internal server errors may be the cause of this status code. The local binding instance continues to receive the incoming message.
Receiving

Instantiated Property Value

context:FaultHint true

HTTP status code dependent transitions.
Status Code	Reason phrase	Significance/Action	NextState
2xx	Successful
200	OK	The Response Message follows in HTTP response entity body.	Receiving
202	Accepted	The Request Message has been received and processed. The entity body of the HTTP response MAY contain a Response Message.
204	No Content	The Request message has been received and processed. The HTTP response MUST NOT contain an entity body. The message exchange is regarded as having completed successfully.	Success
Instantiated Property	Value
`context:CurrentMessage`	"Empty" SOAP Envelope.
3xx	Redirection	The requested resource has moved and the HTTP request SHOULD be retried using the URI carried in the associated Location header as the new value for the `context:ImmediateDestination` property.	Requesting
4xx	Client Error
400	Bad Request	Indicates a problem with the received HTTP Request Message. This may include a malformed XML in the Request-Message envelope. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded has having completed unsuccessfully.	Fail
Instantiated Property	Value
`context:FailureReason`	`fail:BadRequest`
401	Unauthorized	Indicates that the HTTP Request requires authorization.	Requesting
Instantiated Property	Value
`context:FailureReason`	`fail:AuthenticationFailure`
If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the message exchange is regarded as having completed unsuccessfully.	Fail
Instantiated Property	Value
`context:FailureReason`	`fail:AuthenticationFailure`
405	Method not allowed	Indicates that the peer HTTP server does not support the requested HTTP method at the given request URI. The message exchange is regarded has having completed unsuccessfully.	Fail
Instantiated Property	Value
`context:FailureReason`	`fail:BindingMismatch`
415	Unsupported Media Type	Indicates that the peer HTTP server does not support Content-type used to encode the Request Message. The message exchange is regarded has having completed unsuccessfully.	Fail
Instantiated Property	Value
`context:FailureReason`	`fail:BindingMismatch`
427	SOAPAction Required	Indicates that the peer HTTP server implements the OPTIONAL SOAPAction feature and that it requires that this node provide a SOAPAction header when resubmitting a similar HTTP request. The message exchange is regarded has having completed unsuccessfully. In requesting SOAP nodes that support the OPTIONAL SOAPAction feature, the behaviour described in 7.5.1 SOAP Action is applied.	Fail
5xx	Server Error
500	Internal Server Error	Indicates that the Response Message contained in the following HTTP response entity body may contain an SOAP fault. Other internal server errors may be the cause of this status code. The local binding instance continues to receive the incoming message.	Receiving
Instantiated Property	Value
`context:FaultHint`	true

Note:

There may be elements in the HTTP infrastructure configured to modify HTTP response entity bodies for 4xx and 5xx status code responses; for example, some existing HTTP origin servers have such a feature as a configuration option. This behavior may interfere with the use of 4xx and 5xx status code responses carrying SOAP fault messages in HTTP. It is recommended that such behavior is disabled for resources accepting SOAP/HTTP requests. If the rewriting behavior cannot be disabled, SOAP/HTTP cannot be used in such configurations.

7.4.1.3 Receiving

State Description: Receiving
Transitions	Event/Condition	NextState	Failure Reason
Statename	Receiving
Description	Receive HTTP response entity body, which is assumed to be a SOAP message ~~envelope~~ serialized according to XML 1.0.
Preconditions	None
Postconditions	On transitions to Success: property `context:CurrentMessage` instantiated with XML Infoset representation of the serialized SOAP message ~~envelope~~ in the response body.

	Well formed Response Message Received	Success	N/A
	Reception Failure (broken connections etc.)	Fail	`fail:ReceptionFailure`
	Packaging Failure (inc. mismatched Content-Type)	Fail	`fail:PackagingFailure`
	Malformed Response Message, e.g. malformed XML, invalid SOAP Envelope	Fail	`fail:BadResponseMessage`

7.4.1.4 Success and Fail

These are the terminal states of for a given instance of a single-request-response message exchange. Control over the message exchange context returns to the local SOAP node.

7.4.2 Behaviour of Responding SOAP Node

The overall flow of the behaviour of a Requesting SOAP Node follows the outline state machine description contained in 6.1 Single-Request-Response MEP . The follwoing subsections describe each state in detail.

Editorial note: JJM/SKW	20011205
Preconditions for entering this first state should be part of the single request response mep description. The receiving binding brings a message exchange context into existence for the inbound message instantiates it in a generic receiving state..

7.4.2.1 Receiving

State Description: Receiving

Statename Receiving

Description Receive and validate the inbound Request Message

Preconditions Reception of an HTTP POST request at an HTTP endpoint bound to the local SOAP Node.

Postconditions See below

Transitions Event/Condition NextState Action

Receive HTTP POST Request containing well formed Request Message. Processing

Instantiate or replace the property context:ImmediateSender with a URI value that denotes the sender of the HTTP request (if known)

Instantiate or replace the property context:CurrentMessage with a value that represents an Infoset representation of the received Request Message.

Any HTTP headers that are significant to features expressed outside the SOAP envelope (e.g. SOAPAction) are processed in accordance with the relevant feature specification.

This change of state represents a transfer of control of the inbound message exchange context to the local SOAP node.

Receive HTTP POST Request containing malformed Request Message Fail
The message is deemed to have been intended for the local SOAP node, but is deemed badly formed: ill-formed XML, does contain a valid SOAP envelope. The local SOAP node generates SOAP fault message in accordance with the table below which it sends in the corresponding HTTP response message, accompanied by a status code value appropriate to the particular fault.

The message exchange context may be destroyed or considered not to have been created.

State Description: Receiving
Statename	Receiving
Description	Receive and validate the inbound Request Message
Preconditions	Reception of an HTTP POST request at an HTTP endpoint bound to the local SOAP Node.
Postconditions	See below
Transitions	Event/Condition	NextState	Action
Receive HTTP POST Request containing well formed Request Message.	Processing	Instantiate or replace the property `context:ImmediateSender` with a URI value that denotes the sender of the HTTP request (if known) Instantiate or replace the property `context:CurrentMessage` with a value that represents an Infoset representation of the received Request Message. Any HTTP headers that are significant to features expressed outside the SOAP envelope (e.g. SOAPAction) are processed in accordance with the relevant feature specification. This change of state represents a transfer of control of the inbound message exchange context to the local SOAP node.
Receive HTTP POST Request containing malformed Request Message	Fail	The message is deemed to have been intended for the local SOAP node, but is deemed badly formed: ill-formed XML, does contain a valid SOAP envelope. The local SOAP node generates SOAP fault message in accordance with the table below which it sends in the corresponding HTTP response message, accompanied by a status code value appropriate to the particular fault. The message exchange context may be destroyed or considered not to have been created.

Binding generated faults

Problem with Message HTTP Status Code HTTP reason phrase (informative) SOAP fault

Ill-formed XML or invalid SOAP Envelope (of this SOAP Version) 400 Bad request None

Unsupported message encapsulation method 415 Unsupported Media None

Binding generated faults
Problem with Message	HTTP Status Code	HTTP reason phrase (informative)	SOAP fault
Ill-formed XML or invalid SOAP Envelope (of this SOAP Version)	400	Bad request	None
Unsupported message encapsulation method	415	Unsupported Media	None

7.4.2.2 Processing

State Description: Processing

Statename Processing

Description The SOAP Node processes the Request Message and replace it a Response Message.

Preconditions None

Postconditions See below

Transitions Event/Condition NextState Action or Failure Reason

The local SOAP Node completes the processing of the Request Message. Responding The SOAP Node replaces the Request Message carried in context:CurrentMessage with a Response Message. The Response Message may contain a SOAP fault.

Underlying Connection Failure Fail fail:TransmissionFailure

State Description: Processing
Statename	Processing
Description	The SOAP Node processes the Request Message and replace it a Response Message.
Preconditions	None
Postconditions	See below
Transitions	Event/Condition	NextState	Action or Failure Reason
The local SOAP Node completes the processing of the Request Message.	Responding	The SOAP Node replaces the Request Message carried in `context:CurrentMessage` with a Response Message. The Response Message may contain a SOAP fault.
Underlying Connection Failure	Fail	`fail:TransmissionFailure`

7.4.2.3 Responding

State Description: Responding

Statename Responding

Description Formulate and send Response Message (see table below)

Preconditions context:CurrentMessage contains a value that represents the Response Message (which may contain a SOAP fault).

Postconditions See below

Transitions Event/Condition NextState Action or Failure Reason

The local SOAP Node completes the processing of the Request Message. Responding The SOAP Node replaces the Request Message carried in context:CurrentMessage with a Response Message. The Response Message may contain a SOAP fault.

State Description: Responding
Statename	Responding
Description	Formulate and send Response Message (see table below)
Preconditions	`context:CurrentMessage` contains a value that represents the Response Message (which may contain a SOAP fault).
Postconditions	See below
Transitions	Event/Condition	NextState	Action or Failure Reason
The local SOAP Node completes the processing of the Request Message.	Responding	The SOAP Node replaces the Request Message carried in `context:CurrentMessage` with a Response Message. The Response Message may contain a SOAP fault.

HTTP Response Headers

Header Value

Status line Set according to the following table

Content-Type "application/soap+xml" (see 7.1 Introduction ) (see 7.5.2 Content Negotiation Feature )

Additional Headers Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange e.g. SOAPAction (see 7.5.1 SOAP Action ).

HTTP entity body XML 1.0 serialisation of the SOAP message XML Infoset carried in the context:CurrentMessage property of the message exchange context. This binding mandates support for UTF-8 and UTF-16.

HTTP Response Headers
Header	Value
Status line	Set according to the following table
Content-Type	"application/soap+xml" (see 7.1 Introduction ) (see 7.5.2 Content Negotiation Feature )
Additional Headers	Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange e.g. SOAPAction (see 7.5.1 SOAP Action ).
HTTP entity body	XML 1.0 serialisation of the SOAP message XML Infoset carried in the `context:CurrentMessage` property of the message exchange context. This binding mandates support for UTF-8 and UTF-16.

SOAP Fault to HTTP Status Mapping

SOAP fault HTTP status code HTTP reason phrase (informative)

Non-fault Response Message 200 OK

env:VersionMismatch ??

env:MustUnderstand ??

env:DataEncodingUnknown ??

env:Sender ??

env:Receiver ??

env:rpc ??

Other faults ??

SOAP Fault to HTTP Status Mapping
SOAP fault	HTTP status code	HTTP reason phrase (informative)
Non-fault Response Message	200	OK
env:VersionMismatch	??
env:MustUnderstand	??
env:DataEncodingUnknown	??
env:Sender	??
env:Receiver	??
env:rpc	??
Other faults	??

7.4.2.4 Success and Fail

These are the terminal states for a given instance of a single-request-response message exchange. From the point-of-view of the local node this message exchange has completed.

7.5 Features Expressed External to the Message Envelope

This underlying protocol binding specification defines a binding specific expression for the following features:

"http://www.w3.org/2001/12/soap/bindings/defaultHTTP/SOAPAction/"

Other features that are compatible with the message exchange patterns listed above are supported using their generic in-envelope expression defined in the relevant feature specification.

7.5.1 SOAP Action

This sub-section defines a binding specific optional feature named:

"http://www.w3.org/2001/12/soap/binding/defaultHTTP/SOAPAction/"

In the text to follow, the prefix "action" is mapped to the URI "http://www.w3.org/2001/12/soap/binding/defaultHTTP/SOAPAction/"

Some SOAP Receivers using this binding might need certain information to be readily available outside the message envelope. This binding uses an externalised expression of the SOAP Action feature to supply this information.

Use of the SOAP Action feature is OPTIONAL. SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD NOT require its presence in order to operate. Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receiver specifies its use).

Feature Properties

Property Name Description

action:SOAPActionURI Used to hold the SOAPAction feature value.
The type of this property is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". Relative URIs are interpreted relative to the Request-URI.

action:RequiredSOAPActionURI If a SOAP Receiver does require the action:SOAPActionURI property in order to operate, it MAY respond to requests which either convey an unrecognised action:SOAPActionURI value or convey no action:SOAPActionURI value with a response containing an action:RequiredSOAPActionURI property. The SOAP Receiver SHOULD ensure that an HTTP status code of 427 (SOAPAction required) is returned to the corresponding HTTP client.
The type of this property is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". Relative URIs are interpreted relative to the Request-URI.

Feature Properties
Property Name	Description
`action:SOAPActionURI`	Used to hold the SOAPAction feature value. The type of this property is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". Relative URIs are interpreted relative to the Request-URI.
`action:RequiredSOAPActionURI`	If a SOAP Receiver does require the `action:SOAPActionURI` property in order to operate, it MAY respond to requests which either convey an unrecognised `action:SOAPActionURI` value or convey no `action:SOAPActionURI` value with a response containing an `action:RequiredSOAPActionURI` property. The SOAP Receiver SHOULD ensure that an HTTP status code of 427 (SOAPAction required) is returned to the corresponding HTTP client. The type of this property is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". Relative URIs are interpreted relative to the Request-URI.

The action:SOAPActionURI and action:RequiredSOAPActionURI properties are represented in HTTP using the HTTP headers SOAPAction and Required-SOAPAction respectively. The following table shows the points at which the property values and HTTP header values are exchanged.

Feature Operation (Client side)

Property Name Request Response

action:SOAPActionURI If action:SOAPActionURI property is present in the message exchange context, its value is sent as the value of a SOAPAction HTTP header N/A

action:RequiredSOAPActionURI N/A If a Required-SOAPAction HTTP header is present, its value is inserted into the message exchange context as the value of the action:RequiredSOAPActionURI property.

Feature Operation (Client side)
Property Name	Request	Response
`action:SOAPActionURI`	If `action:SOAPActionURI` property is present in the message exchange context, its value is sent as the value of a SOAPAction HTTP header	N/A
`action:RequiredSOAPActionURI`	N/A	If a Required-SOAPAction HTTP header is present, its value is inserted into the message exchange context as the value of the `action:RequiredSOAPActionURI` property.

Feature Operation (Server side)

Property Name Request Response

action:SOAPActionURI If a SOAPAction HTTP header is present, its value is inserted into the message exchange context as the value of the action:SOAPActionURI property. N/A

action:RequiredSOAPActionURI N/A If an action:RequiredSOAPActionURI property is present in the message exchange context, its value is sent as the value of a Required-SOAPAction HTTP header

Feature Operation (Server side)
Property Name	Request	Response
`action:SOAPActionURI`	If a SOAPAction HTTP header is present, its value is inserted into the message exchange context as the value of the `action:SOAPActionURI` property.	N/A
`action:RequiredSOAPActionURI`	N/A	If an `action:RequiredSOAPActionURI` property is present in the message exchange context, its value is sent as the value of a `Required-SOAPAction` HTTP header

The syntax for the SOAPAction and Required-SOAPAction HTTP headers fields is defined as follows:

SOAP Action HTTP Header

[4]	`soapaction`	::=	`"SOAPAction" ":" <"> URI-reference <">`
[5]	`URI-reference`	::=	`<as defined in RFC2396 >`

Required SOAP Action HTTP Header

[6] req-soapaction ::= "required-SOAPAction" ":" <"> URI-reference <">

7.5.2 Content Negotiation Feature

This sub-section defines a binding specific optional feature named:

"http://www.w3.org/2001/12/soap/binding/defaultHTTP/Conneg/"

In the text to follow, the prefix "conneg" is mapped to the URI "http://www.w3.org/2001/12/soap/binding/defaultHTTP/Conneg/"

Some SOAP Senders or Receivers using this binding might need to use it to exchange representations of a SOAP message using MIME media types other than the default XML 1.0 serialization used by the application/soap+xml media type [12] . Possible examples include representations of an encrypted SOAP message using [S/MIME] or representations which bundle representations of external URI references made from within the SOAP envelope in the form of attachments.

Use of the Content Negotiation feature is OPTIONAL. SOAP nodes MAY use it as means to enhance processing, but SHOULD NOT require its presence in order to operate. Support for the Content Negotiation feature is OPTIONAL in implementations.

Feature Properties
Property Name	Description
conneg:SenderMediaTypesSupported	Used to hold the list of MIME media types supported by the sending SOAP node. The type of this property is NMTOKENS in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". If the property is unset, it is treated as having a value equal to that of the conneg:DefaultMediaType property.
conneg:ReceiverMediaTypesSupported	Used to hold the list of MIME media types supported by the receiving SOAP node. The type of this property is NMTOKENS in the namespace named "http://www.w3.org/2001/XMLSchema-datatypes". If the property is unset, it is treated as having a value equal to that of the conneg:DefaultMediaType property. [Note: A Sending SOAP node MAY use an out-of-band means of determining the set of media types supported at a Receiving SOAP node (e.g. using [WSDL]) or it MAY rely upon the Receiving SOAP node's use of this feature by means of a 415 Unsupported Media HTTP Response message to identify the set of supported media types]
conneg:DefaultMediaType	application/soap+xml [12]
conneg:MediaType	The MIME media type corresponding to the representation of the XML Infoset serialization of the SOAP message in the context:CurrentMessage property. If this property is unset, it is treated as having a value equal to that of the conneg:DefaultMediaType property.

Feature Operation (Client side)
Property Name	Request	Response
conneg:MediaType	If conneg:MediaType property is present in the message exchange context, its value is sent as the value of the Content-Type HTTP header. If conneg:MediaType property is unset, the value of the conneg:DefaultMediaType is sent as the value of the Content-Type HTTP header.	The value of the Content-Type HTTP header is used to set the value of the conneg:MediaType property.
conneg:SenderMediaTypesSupported	If conneg:SenderMediaTypesSupported property is set, its value is sent in an HTTP Accept header. If the conneg:SenderMediaTypesSupported property is unset, the value of the conneg:DefaultMediaType property MAY be sent in the HTTP Accept header.	N/A
conneg:ReceiverMediaTypesSupported	If the conneg:ReceiverMediaTypesSupported property is set, the value of the conneg:MediaType property is selected from an intersection of the conneg:ReceiverMediaTypesSupported and conneg:SenderMediaTypesSupported properties.	If the HTTP Accept header is present in the HTTP Response message, its value is used to set the conneg:ReceiverMediaTypesSupported property. In the event that a Sending SOAP node receives a 415 Unsupported Media HTTP Response, it MAY use the value of this property to resend the original Request message.

Feature Operation (Server side)
Property Name	Request	Response
conneg:MediaType	The value of the Content-Type HTTP header is used to set the value of the conneg:MediaType property. The entity body of the HTTP Request message is deserialized into the XML Infoset representation of the SOAP message in accordance with the rules defined for the MIME media type identified by the conneg:MediaType property and used to set the context:CurrentMessage property.	If conneg:MediaType property is present in the message exchange context, its value is sent as the value of the Content-Type HTTP header. The value of the context:CurrentMessage property is serialized in accordance with the rules defined for the MIME media type identified by the conneg:MediaType property and used to set the entity body of the HTTP Response message.
conneg:SenderMediaTypesSupported	If the HTTP Accept header is present in the HTTP Request message, its value is used to set the conneg:SenderMediaTypesSupported property. If an HTTP Accept header is not present in the HTTP Request message, the value of the Content-Type HTTP header is used.	The value of the conneg:MediaType property of the Response message is selected from among the list of MIME media types in the intersection of the conneg:SenderMediaTypesSupported and the conneg:ReceiverMediaTypesSupported properties.
conneg:ReceiverMediaTypesSupported	N/A	If a Request message is received for which the Content-Type is unrecognized or unsupported resulting in an HTTP 415 Unsupported Media response, insert an HTTP Accept header in the response with the value of the conneg:ReceiverMediaTypesSupported property if set, otherwise use the value of the conneg:DefaultMediaType property.

7.6 Security Considerations

The SOAP HTTP Binding (see 7 SOAP HTTP Binding ) can be considered as an extension of the HTTP application protocol. As such, all of the security considerations identified and described in section 15 of the HTTP specification[2] apply to the SOAP HTTP Binding in addition to those described in Part 1 [1] "Security Considerations". Implementers of the SOAP HTTP Binding should carefully review this material.

8 References

8.1 Normative References

1: W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, @@ @@ 2002 (See soap12-part1.html .)
2: IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt .)
3: IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt .)
4: W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ .)
5: W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ .)
6: IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt .)
7: W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/ .)
8: W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006 .)
9: W3C Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xlink-20010627/ .)
10: W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ .)
11: IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July 1998. (See http://www.ietf.org/rfc/rfc3023.txt .)
12: IETF "INTERNET DRAFT: The 'application/soap+xml' media type", M. Baker, M. Nottingham, January 14, 2002. (Work in progress). (See http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt .)

8.2 Informative References

13: XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/ .)
14: XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/ .)
15: XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter .)
16: IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. (See http://www.ietf.org/rfc/rfc2045.txt .)
17: IETF "RFC 2026: The Internet Standards Process -- Revision 3", section 4.2.3, S. Bradner, October 1996. (See http://www.ietf.org/rfc/rfc2026.txt .)

A Mapping Application Defined Name to XML Name

Hex Digits

[7] hexDigit ::= [0-9A-F]

A.1 Rules for mapping application defined name to XML Name

XML Name has two parts: Prefix and LocalPart . Let Prefix be computed per the rules and constraints specified in Namespaces in XML [7] .
Let TAG be a name in an application. TAG is a sequence of characters of the application. Let N be the number of characters in TAG. Let T₁ , T₂, ... , T_N be the characters of TAG, in order from left to right.
Let M be the implementation-defined mapping of the characters of the application to characters of Unicode.
For each i between 1 (one) and N, let M_i be M(T_i).
For each i between 1 (one) and N, let X_i be the Unicode character string defined by the following rules.

Case:
1. If T_i has no mapping to Unicode (i.e. M(T_i) is undefined), then X_i is implementation-defined
2. If i<=N-1, T_i is "_" (underscore), and T_i+1 is "x" (lowercase letter x), then let X_i be "_x005F_".
3. If i=1, N>=3, T₁ is either "x" (lowercase letter x) or "X" (uppercase letter X), T₂ is either "m" (lowercase letter m) or "M" (uppercase letter M), and T₃ is either "l" (lowercase letter l) or "L" (uppercase letter L), then let X_i be "_xFFFF_" T₁
4. If T_i is not a valid XML NCName character or if i=1 (one) and T₁ is not a valid first character of an XML NCName, then:
  
  Let U₁, U₂, ... , U₈ be the eight hex digits [PROD: 7 ] such that T_i is "U+" U₁ U₂ ... U₈ in the UCS-4 encoding.
  
  Case:
  1. If U₁=0, U₂=0, U₃=0, and U₄=0, then let X_i="_x" U₅ U₆ U₇ U₈ "_".
    
    This case implies that T_i has a UCS-2 encoding, which is U+U₅U₆U₇U₈.
  2. Otherwise, let X_i be "_x" U₁ U₂ U₃ U₄ U₅ U₆ U₇ U₈ "_".
5. Otherwise, let X_i be M_i . That is, any character in TAG that is a valid character in an XML NCName is simply copied.
Let LocalPart be the character string concatenation of X₁, X₂, ... , X_N in order from left to right.
Let XML Name be the QName per Namespaces in XML [7]

A.2 Examples

Hello world -> Hello_x0020_world
Hello_xorld -> Hello_x005F_xorld
Helloworld_ -> Helloworld_

          x -> x
        xml -> _xFFFF_xml
       -xml -> _x002D_xml
       x-ml -> x-ml

B Using W3C XML Schema with SOAP Encoding (Non-Normative)

As noted in 3.1.5 Computing the Type Name property SOAP graph nodes are labeled with type names, but validation of encoded SOAP messages MUST NOT be required by conforming processors. These sections describe techniques that can be used when validation with W3C XML schemas is desired for use by SOAP applications. Any errors or faults resulting from such validation are beyond those covered by the normative recommendation; from the perspective of SOAP, such faults are considered to be application-level failures.

B.1 Validating using the minimum schema

Although W3C XML schemas are conventionally exchanged in the form of schema documents (see [4] ), the schema recommendation is build on an abstract definition of schemas, to which all processors must conform. The schema recommendation provides that all such schemas include definitions for a core set of built in types, such as integers, dates, and so on ([ref to minimal schema in schema rec.]). Thus, it is possible to discuss validation of a SOAP message against such a minimal schema, which is the one that would result from providing no additional definitions or declarations (i.e. no schema document) to a schema processor.

Editorial note: JJM	20020327
Missing reference to minimal schema above.

The minimal schema provides that any well formed XML document will validate, except that where an xsi:type is provided, the type named must be built in, and corresponding element must be valid per that type. Thus, validation of a SOAP 1.2 message using a minimal schema approximates the behavior of the built-in types of SOAP 1.1.

B.2 Validating using the SOAP Encoding schema

Editorial note: MJG	20020314
This is a placeholder for now

B.3 Validating using more specific schemas

Editorial note: MJG	20020314
This is a placeholder for now

C SOAP HTTP Binding Examples (Non-Normative)

C.1 Sample Encoding of Call Requests

Example: SOAP HTTP Request Using POST

POST /StockQuote HTTP/1.1
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://www.example.org/abc#MyMessage"

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 . . .
</env:Envelope>

Example: SOAP message using SOAP Encoding in HTTP POST with a mandatory header

POST /StockQuote HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"

<?xml version="1.0" ?>
<env:Envelope
     xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Header>
  <t:Transaction
     xmlns:t="http://example.org/2001/06/tx"
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     env:mustUnderstand="true" >
     5
  </t:Transaction>
 </env:Header>
 <env:Body >
  <m:GetLastTradePrice
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:m="http://example.org/2001/06/quotes" >
   <m:symbol>DEF</m:symbol>
  </m:GetLastTradePrice>
 </env:Body>
</env:Envelope>

Example: SOAP message using SOAP Encoding in HTTP POST with multiple request parameters

POST /StockQuote HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
  <m:GetLastTradePriceDetailed
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:m="http://example.org/2001/06/quotes" >
   <Symbol>DEF</Symbol>
   <Company>DEF Corp</Company>
   <Price>34.1</Price>
  </m:GetLastTradePriceDetailed>
 </env:Body>
</env:Envelope>

C.2 Sample Encoding of Response

Example: SOAP HTTP Response

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 . . .
</env:Envelope>

Example: SOAP message using SOAP Encoding in HTTP response including a mandatory header

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Header>
  <t:Transaction 
     xmlns:t="http://example.org/2001/06/tx"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xsi:type="xs:int"
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     env:mustUnderstand="true" >
     5
  </t:Transaction>
 </env:Header>
 <env:Body>
  <m:GetLastTradePriceResponse
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:m="http://example.org/2001/06/quotes" >
   <Price>34.5</Price>
  </m:GetLastTradePriceResponse>
 </env:Body>
</env:Envelope>

Example: Similar to previous example but using a struct for the body and ommitting the mandatory header

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
  <m:GetLastTradePriceResponse
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:m="http://example.org/2001/06/quotes" >
   <PriceAndVolume>
    <LastTradePrice>34.5</LastTradePrice>
    <DayVolume>10000</DayVolume>
   </PriceAndVolume>
  </m:GetLastTradePriceResponse>
 </env:Body>
</env:Envelope>

Example: Must understand fault in HTTP response

HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
  <env:Fault>
   <faultcode><value>env:MustUnderstand</value></faultcode>
   <faultstring>SOAP Must Understand Error</faultstring>
  </env:Fault>
 </env:Body>
</env:Envelope>

Example: SOAP fault, resulting from failure to handle the SOAP body, in HTTP response

HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
  <env:Fault xmlns:e="http://example.org/2001/06/faults" >
   <faultcode>
    <value>env:Server</value>
    <subcode>
     <value>e:OutOfMemory</value>
    </subcode>
   </faultcode>
   <faultstring>Server Error</faultstring>
   <detail>
    <e:myfaultdetails>
     <message>My application didn't work</message>
    </e:myfaultdetails>
   </detail>
  </env:Fault>
 </env:Body>
</env:Envelope>

D Acknowledgements (Non-Normative)

This document is the work of the W3C XML Protocol Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), Charles Campbell (Informix Software), Michael Champion (Software AG), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dietmar Gaertner (Software AG), Rich Greenfield (Library of Congress), Martin Gudgin (DevelopMentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Henry Lowe (OMG), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Highland Mary Mountain (Intel), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (BEA Systems), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Herve Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Asir Vedamuthu (webMethods) Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Jin Yu (Martsoft Corp.).

Previous members were: Eric Fedok (Active Data Exchange), Susan Yee (Active Data Exchange), Dan Frantz (BEA Systems), Alex Ceponkus (Bowstreet), James Tauber (Bowstreet), Rekha Nagarajan (Calico Commerce), Mary Holstege (Calico Commerce), Krishna Sankar (Cisco Systems), David Burdett (Commerce One), Murray Maloney (Commerce One), Jay Kasi (Commerce One), Yan Xu (DataChannel), Brian Eisenberg (DataChannel), Mike Dierken (DataChannel), Michael Freeman (Engenia Software), Bjoern Heckel (Epicentric), Dean Moses (Epicentric), Julian Kumar (Epicentric), Miles Chaston (Epicentric), Alan Kropp (Epicentric), Scott Golubock (Epicentric), Michael Freeman (Engenia Software), Jim Hughes (Fujitsu Limited), Dick Brooks (Group 8760), David Ezell (Hewlett Packard), Fransisco Cubera (IBM), David Orchard (Jamcracker), Alex Milowski (Lexica), Steve Hole (MessagingDirect Ltd.), John-Paul Sicotte (MessagingDirect Ltd.), Vilhelm Rosenqvist (NCR), Lew Shannon (NCR), Art Nevarez (Novell, Inc.), David Clay (Oracle), Jim Trezzo (Oracle), David Cleary (Progress Software), Andrew Eisenberg (Progress Software), Peter Lecuyer (Progress Software), Ed Mooney (Sun Microsystems), Mark Baker (Sun Microsystems), Anne Thomas Manes (Sun Microsystems), George Scott (Tradia Inc.), Erin Hoffmann (Tradia Inc.), Conleth O'Connell (Vignette), Waqar Sadiq (Vitria Technology Inc.), Randy Waldrop (WebMethods), Bill Anderson (Xerox), Tom Breuel (Xerox), Matthew MacKenzie (XMLGlobal Technologies), David Webber (XMLGlobal Technologies), John Evdemon (XMLSolutions) and Kevin Mitchell (XMLSolutions).

The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.

E Part 2 Change Log (Non-Normative)

E.1 SOAP Specification Changes

Date	Author	Description
20020327	JJM	Removed extra spaces around parenthesis, dot, semi-colon and comma.
20020327	JJM	Fixed typo discovered by Herve.
20020322	HFN	Changed mU='1' with mu='true' in examples.
20020322	MJH	replaced transport with context/underluing protocol.
MJG	Made consistent usage of section names; SOAP Data Model, SOAP Encoding, SOAP RPC Representation, SOAP HTTP Binding
20020322	MJG	Added priority feedback request regarding 'generics' to section 2.3
20020322	MJH	changed all namespace identifiers, URIs to names.
20020322	MJH	removed links in NS URIs.
20020314	MJG	Added appendix B (not yet complete)
20020314	MJG	Rewrote Section 2
20020314	MJG	Rewrote Section 3
20020314	MJG	Amended Section 4 to match new Section 2 and 3
20020321	HFN	Added text to 7 SOAP HTTP Binding to clarify that HTTP binding is optional and one of many possible bindings
20020321	HFN	Made abstract and introduction consistent with Part 1
20020321	MJH	Issue 174 changes.
20020321	MJH	Made URI styling consistent throughout and consistent with part 1.
20020321	MJH	Made references to fault code values consistent throughout and consistent with part 1.
20020320	JJM	Incorporated resolution for issue #180.
20020320	JJM	Updated cross-references from saying "bibref" "xspecref" to "bibref" section "xspecref". Otherwise the generated HTML looked funny (the links were back to back) [Ednote issue #33]
20020320	JJM	More generally, made all "bibrefs" more uniform.
20020320	JJM	Added resolution text for issue 184.
20020319	JJM	Incorporated Chris Ferris' proposed resolution to 6.1.4 Fault Handling in anticipation of its acceptance by the WG
20020318	JJM	Incorporated resolution to ednote part 2 sec 6.1.3
20020316	HFN	Updated section 6.1 Single-Request-Response MEP
20020316	HFN	Updated section 6.1.4 Fault Handling
20020316	HFN	Deleted section 6.1.5, 6.1.6, and 7.4.1.3
20020312	MJH	Incorporated issue 16 resolution.
20020312	MJH	Incorporated issue 113 resolution.
20020312	MJH	Incorporated issue 48 resolution.
20020312	MJH	Fixed up content list of part 1 in introduction.
20020305	MJG	Removed section 1.3 ( Terminology )
20020305	MJG	Removed section 1.2 ( Examples )
20020304	HFN	Updated rule 8 as per resolution to issue 177 . Section on default values seemed already to have been removed.
20020304	HFN	Removed last two paragraphs in section "RPC and SOAP Header" talking about non-normative example text
20020228	HFN	Updated abstract slightly
20020228	HFN	Add security considerations text .
20020228	HFN	Added second part of resolution of issue 59: Say that we mandate support for UTF-8 and UTF-16
20020228	HFN	Move the HTTP specific examples in Appendix B1 to Appendix C.
20020227	MJG	Changed all refs to transport message exchange to message exchange
20020227	MJG	Moved ednote from 6.1.3 to be text in 6
20020225	MJG	Removed reference to 'Simple Authentication Feature' in HTTP binding
20020225	MJG	added id attrs to all div elements
20020225	MJG	Removed section 7.5.2
20020225	MJG	Removed redundant text from 3.1.2
20020221	MJG	Edited examples so that no line is longer than 66 characters
20020220	MJG	Moved SOAP HTTP Examples to an appendix marked as non-normative
20020220	MJG	Added text stating the paragraph on transaction ids in Section 4.2 is non-normative
20020219	MJG	Changed BNF for arraySize to say non negative integer instead of positive integer
20020219	MJG	Changed arraySize to use nonNegativeInteger instead of positiveInteger
20020215	MJG	Removed old array attributes from encoding schema
20020215	MJG	Added new array attributes to encoding schema
20020215	MJG	Rewrote Section 3 from XML Infoset perspective
20020214	MJG	Removed NOTATION type and element decl from encoding schema
20020214	MJG	Rolled back Infoset rewrite of RPC section
20020214	MJG	Changed relevant occurences of Client and Server to Sender and Receiver for consistency with Part 1.
20020213	MJH	Removed (possibly defaulted) from encoding rule 2.
20020213	MJH	Changed encoding examples to better show inline multirefs and removed corresponding ednote.
20020208	MJG	Added examples to Appendix A
20020208	MJG	Changed Section 4.1 ednote
20020208	MJG	Rewrote Section 4.1 from Infoset perspective
20020201	MJH	Editorial fix to encoding array example narrative.
20020131	MJH	Added new "Decoding faults" subsection as resolution for issues 168 and 170.
20020129	MJH	Pulled out the single/multi ref descriptions in Simple Types/Strings and Simple Types/Array of Bytes into a new separate subsection of the Simple Types section.
20020129	MJH	Misc editorial fixes.
20020129	MJH	Fixed EBNF reference to use XML Recommendation notation.
20020129	MJH	Fixed reference to SOAP media type draft, removed duplicated information, renumbered following references.
20020125	HFN	In section on SOAP data model, changed "The SOAP data model represents information as a graph of typed objects" to "The SOAP data model represents information as a graph of typed nodes"
20020125	HFN	Removed ednote in section 7.1 regarding SOAP media type and added reference to the soap media type internet draft for details about use of media type parameters. I have not changed the use of SOAPAction during this.
20020121	MJH	Changed encoding references from anyURI to IDREF (Issue 170).
20020118	MJH	Changed rpc error text to use new SOAP fault subcodes (Issue 173).
20020117	MJH	Fixed indentation on more examples.
20020117	MJH	Removed sparse and partially transmitted arrays. Modified encoding section to use arraySize and itemTpe attributes. Resolves issues 117, 144 and 161.
20020117	JJM	Added text for resolution of issue 12.
20020114	MJH	Fixed indentation in 3 of the examples in SOAP encoding section.
20020114	MJH	Removed duplicate text for section 2 (SOAP Data Model) from section 3 (SOAP Encoding).
20020109	JJM	Incoporated comments from John Ibbotson.
20011220	JJM	Added resolution for 171 in section 4.1 "Rules for Encoding Types in XML".
20011219	JJM	Fixed abstract.
20011214	JJM	Fixed incorrect reference to XML Protocol Charter.
20011214	JJM	Fixed incorrect combination of olist, item and p in "A Mapping Application Defined Name to XML Name" section
20011214	JJM	Fixed incorrect reference to XLink.
20011213	JJM	Changed the namespace to http://www.w3.org/2001/12/.
20011211	JJM	In the new TBTF sections, use the passive voice instead of "we".
20011211	JJM	Replace application/soap+xml by application/soap in "HTTP Request Fields" table.
20011211	JJM	Replace text/xml by application/soap in "Responding State" table.
20011211	JJM	Fixed typo in section 6 noticed by Mario.
20011210	JJM	Incorporated David's editorial changes to section 6.
20011206	JJM	Fixes to occurrences of texting refering to blocks (instead of body elements).
20011206	JJM	Converted all the tables in sections 7 and 8 into proper XML.
20011206	JJM	Moved HTTP examples from old binding section to new binding section.
20011206	JJM	Replaced SOAPAction production rules in new binding section with that from old binding section (they were identical, but formatting was better).
20011206	JJM	Removed old binding section.
20011206	JJM	Updated references to XLink and XML Infoset (now recommandations).
20011206	JJM	Moved text about application/soap from old binding to new binding section.
20011206	JJM	Transformed references into proper hyperlinks.
20011206	JJM	Changed image format to GIF.
20011206	JJM	Reduced image size.
20011205	JJM	Incorporated TBTF Part 2 (Features).
20011205	JJM	Incorporated TBTF Part 3 (MEPs).
20011205	JJM	Incorporated TBTF Part 4 (HTTP Binding). There are still some HTML-icisms. Hopefully, they will go away after todays conference call.
20011204	MJH	Changes to encoding section - issue 18.
20011204	MJH	Updated DTD and appendix A to preserve subscripts in variable elements.
20011204	MJH	Updated reference to RFC2376 to RFC3023.
20011204	JJM	Updated the ednote for SOAPAction as an optional feature, now that this is defined in section 5..
20011204	JJM	Added quotes around "Required-SOAPAction".
20011129	MJG	Fixed ednote related to change from text/xml to application/soap
20011122	MJH	Removed placeholder and ednote for HTTP extension framework. The actual text of the section was removed prior to the previous draft and replaced with an ednote requesting feedback on the removal. As none was received the subsection has now been completely removed along with the corresponding bibliography entry.
20011121	MJH	Added appendix for mapping application names to XML element names. Added cross references to encoding and RPC sections to point readers to the new appendix. (Issue 1)
20011029	MJH	Added text to state that SOAP is no longer an acronym (Issue 125)
20011029	MJH	Amended introductory text (Issue 148)
20011029	MJH	Amended introductory text (Issue 147)
20011029	MJH	Amended abstract (Issue 147)
20011026	MJG	Amended BNF for arrayTypeValue to use form from XML 1.0 Rec (Issue 162)
20011026	MJG	Amended prose related to DTDs and PIs (Issue 4)
20011026	MJG	Updated schema change table to list change from ur-type to anyType
20011026	MJG	Added xml declaration to all XML examples with a root of env:Envelope or xs:schema
20011024	MJG	Changed media type from text/xml to application/soap and added associated ednote
20010926	MJG	Updated member list
20010926	MJG	Updated ednote in section 6.4
20010926	MJG	Changed rpc namespace to http://www.w3.org/2001/09/soap-rpc
20010921	MJG	Added rpc namespace to list in Section 2
20010921	MJG	Added new schema for rpc result element as described in section 5.1
20010921	MJG	Amended section 5.1 to incorporate description of rpc result element
20010921	MJG	Changed targetNamespace attribute of encoding schema to http://www.w3.org/2001/09/soap-encoding
20010921	JJM	Used text proposed by Noah for ednote on SOAPAction.
20010920	JJM	Make the wording clarification regarding issue 45 (descreasing order of precedence).
20010920	JJM	Removed current security section; added new security subsection to HTTP binding section, with a temporary ednote until we get text from Henrik and Chris).
20010920	JJM	Change the namespace of the envelope to http://www.w3.org/2001/09/...
20010920	JJM	Add an editorial note about why some sections are not written in terms of infoset.
20010920	JJM	Add ednote from Jacek regarding SOAPAction.
20010918	JJM	Added ednote to the "SOAPAction" section indicating that a HTTP status code needs to be obtained from IANA.
20010918	JJM	Removed last electrocommerce.org URL from examples.
20010914	JJM	Added text from Henrik to beef-up the "Data Model" section placeholder text.
20010914	JJM	Back to "Adjuncts" again.
20010914	JJM	Fixed issues 124, 126, 127, 128 and 132.
20010914	JJM	Fixed typos and indentation.
20010914	JJM	Reference the XML InfoSet Proposed Recommandation instead of the Candidate Recommandation.
20010911	JJM	Changed XML Information Set into a normative reference. Changed XML Protocol Comments Archive, Discussion Archive and Charter into non-normative references. Added a reference to RFC2396 in section 4, 3rd paragraph.
20010905	MJH	Wordsmithed abstract and introduction to better reflect split into parts 1 and 2. Rationalised list of references so only cited works appear. Removed envelope schema changes. Added bibref entries for cross references to Part 1, fixed links so they target the HTML instead of XML version of the doc.
20010831	JJM	Added a close paragraph tag before starting a new olist or ulist.
20010831	JJM	Properly declared the language for the spec, so that we can generate valid HTML.
20010831	JJM	Added text from Hugo to emphasize the fact that the SOAP root attribute is of type XMLSchema boolean.
20010830	MJG	Copied "Relation to XML" section from part 1.
20010830	MJG	Removed Design Goals section (design goals listed relevant to Part 1 not Part 2)
20010830	JJM	Removed terminology not relevant to part2.
20010830	JJM	Added SOAP examples from part 1, introductory sections.
20010830	JJM	Added SOAP example appendix from part1.
20010830	JJM	Added a paragraph to section 1 pointing to part2 for encoding, rpc and http binding.
20010830	JJM	Added a paragraph at the beginning of section 3 to cover serializations containing references to data outside the serialization, as per 20010829 teleconference.
20010830	JJM	Remove 2nd sentence, bullet 5, RPC faults section, as per 20010829 teleconference.
20010830	JJM	Remove 2nd sentence, bullet 1, RPC faults section, as per 20010822 teleconference.
20010829	JJM	Added a placehoder for the forthcoming Data Model section.
20010829	JJM	Removed the Envelope Example section, already present in part1.
20010829	JJM	Updated the specs title.
20010829	JJM	Replaced specref with xspecref for references to Part1 items.
20010829	JJM	Added bibliography entry for SOAP 1.2 Part 1.
20010829	JJM	Removed former sections 1, 2, 3 and 4, and the SOAP versioning appendix. Moved the RPC section before the HTTP binding section, as per the 20010815 teleconference call.
20010829	JJM	Did split the spec into two parts.
20010829	JJM	Refered to the proper DTD and stylesheet.
20010829	JJM	Updated the list of WG members: one person per line in the XML file, for easier updating.
20010816	MJH	Replaced a mustUnderstand="1" with mustUnderstand="true". Slight rewording in mu description.
20010810	MJH	Merged in RPC fault rules text from Jacek. Added new DataEncodingUnknown fault code to SOAP Fault Codes section. Added editorial notes about introduction of new fault code namespace for RPC.
20010809	MJH	Merged in "mustHappen" descriptive text from Glen and Noah.
20010809	MJH	Fixed language around "default" values of attributes.
20010809	MJH	Removed HTTP extension framework, added editorial note to describe why.
20010808	MJH	Added Infoset "specified" property text from Chris.
20010808	MJH	Removed assumption 4 from version transition appendix.
20010808	MJH	Added reference to SOAP 1.1 specification to references section, removed SOAP 1.1 author list from acknowledgments section.
20010807	MJH	Converted specification from HTML to XML conforming to W3C XMLSpec DTD. Numerous resulting formatting changes.
20010720	MJG	Applied Infoset terminology to sections 1, 2, 3 and 4.
20010629	MJG	Amended description of routing and intermediaries in Section 2.1
20010629	JJM	Changed "latest version" URI to end with soap12
20010629	JJM	Remove "previous version" URI
20010629	JJM	Removed "Editor copy" in <title>
20010629	JJM	Removed "Editor copy" in the title.
20010629	JJM	Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft.
20010629	JJM	Pre-filed publication URIs.
20010629	JJM	Incorporated Davids suggested changes for the examples in section 4.1.1 to 4.4.2
20010629	JJM	Fixed some remaining typos.
20010629	MJH	Fixed a couple of typos.
20010628	MJG	Made various formatting, spelling and grammatical fixes.
20010628	MJG	Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50
20010628	MJG	Changed text in Section 2.1 from "it is both a SOAP sender or a SOAP receiver" to "it is both a SOAP sender and a SOAP receiver"
20010628	MJG	Fixed caption on Example 24
20010628	MJH	Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence.
20010628	MJH	Updated figure 1, removed ednote to do so.
20010622	HFN	Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model.
20010622	HFN	Moved the definition of block to encapsulation section in terminology
20010622	HFN	Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and does not belong in a terminology section
20010622	HFN	Removed reference to "Web Characterization Terminology & Definitions Sheet" in terminology section as this is not an active WD
20010622	HFN	Added revised glossary
20010622	HFN	Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding
20010622	MJG	Added http://example.com/... to list of application/context specific URIs in section 1.2
20010622	MJG	Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes
20010622	MJG	Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1
20010622	MJG	In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match.
20010622	MJG	Moved MisunderstoodHeader from envelope schema into seperate faults schema. Removed entry in envelope schema change table in Appendix D.2 that refered to additon of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2
20010622	MJH	Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions.
20010622	MJG	Made BNF in section 6.1.1 into a table.
20010622	MJG	Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet
20010622	MJG	Amended text regarding namespace prefix mappings in section 1.2
20010622	MJG	Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote.
20010622	MJG	Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document
20010622	MJG	Reordered entries in schema change classification table in Appendix D.2
20010622	MJG	Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly
20010622	JJM	Manually numbered all the examples (53 in total!)
20010622	JJM	Added caption text to all the examples
20010622	JJM	Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>)
20010621	HFN	Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2
20010621	HFN	Added version transition appendix C
20010621	HFN	Applied new styles to examples
20010621	HFN	Changed term "transport" to "underlying protocol"
20010621	HFN	Changed example URNs to URLs of the style http://example.org/...
20010621	MJH	Updated the Acknowledgements section.
20010621	JJM	Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2.
20010621	JJM	Incorporated David Fallsides comments on section Status and Intro sections.
20010620	HFN	Changed the status section
20010620	HFN	Changed title to SOAP Version 1.2 and used that first time in abstract and in body
20010620	HFN	Removed question from section 2.4 as this is an issue and is to be listed in the issues list
20010620	HFN	Moved change log to appendix
20010615	JJM	Renamed default actor to anonymous actor for now (to be consistent)
20010615	JJM	Fixed typos in section 2
20010614	JJM	Updated section 2 to adopt the terminology used elsewhere in the spec.
20010613	MJH	Updated mustUnderstand fault text with additions from Martin Gudgin.
20010613	MJH	Added schema changes appendix from Martin Gudgin.
20010613	MJH	Added mustUnderstand fault text from Glen Daniels.
20010612	MJH	Fixed document <title>.
20010612	MJH	Moved terminology subsection from message exchange model section to introduction section.
20010612	MJH	Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate.
20010612	MJH	Removed trailing "/" from encoding namespace URI.
20010612	MJH	Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org.
20010612	MJH	Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places.
20010611	MJH	Incorporated new text for section 2.
20010611	JJM	Changed remaining namespaces, in particular next.
20010609	JJM	Changed the spec name from XMLP/SOAP to SOAP.
20010609	JJM	Changed the version number from 1.1 to 1.2.
20010609	JJM	Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-.
20010609	JJM	Replaced the remaining XS and XE prefixes to env and enc, respectively.
20010601	MJH	Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation.
20010601	JJM	Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation.
20010531	HFN	Removed appendices C and D and added links to live issues list and separate schema files.
20010531	MJH	Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation.

E.2 XML Schema Changes

The encoding schema has been updated to be compliant with the XML Schema Recomendation[4] [5] . The table below shows the categories of change.

Class	Meaning
Addition	New constructs have been added to the schema
Clarification	The meaning of the schema has been changed to more accurately match the specification
Change	The schema has been changed due to a change in the specification
Deletion	Constructs have been removed from the schema
Name	The schema has been changed due to a datatype name change in the XML Schema specification
Namespace	A namespace name has been changed
Semantic	The meaning of the schema has been changed
Style	Style changes have been made to the schema
Syntax	The syntax of the schema has been updated due to changes in the XML Schema specification

The table below lists the changes to the encoding schema.

Class	Description
Namespace	Updated to use the http://www.w3.org/2001/XMLSchema namespace
Namespace	Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-encoding
Semantic	Changed type of the root attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed.
Addition	Added processContents="lax" to all element and attribute wildcards
Syntax	Changed base64 simple type to be a vacuous restriction of the base64Binary type in the http://www.w3.org/2001/XMLSchema namespace
Syntax	Updated all complex type definitions with simple base types to new syntax
Syntax	Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type
Syntax	Added <xs:sequence> to all named model group definitions
Deletion	Removed the timeDuration datatype
Addition	Added duration datatype derived by extension from the duration datatype in the http://www.w3.org/2001/XMLSchema namespace.
Deletion	Removed the timeInstant datatype
Addition	Added dateTime datatype derived by extension from the dateTime datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added gYearMonth datatype derived by extension from the gYearMonth datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added gYear datatype derived by extension from the gYear datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added gMonthDay datatype derived by extension from the gMonthDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
Deletion	Removed the binary datatype
Addition	Added hexBinary datatype derived by extension from the hexBinary datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added base64Binary datatype derived by extension from the base64Binary datatype in the http://www.w3.org/2001/XMLSchema namespace.
Deletion	Removed the uriReference datatype
Addition	Added anyURI datatype derived by extension from the anyURI datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added normalizedString datatype derived by extension from the normalizedString datatype in the http://www.w3.org/2001/XMLSchema namespace.
Addition	Added token datatype derived by extension from the token datatype in the http://www.w3.org/2001/XMLSchema namespace.
Clarification	Added explicit namespace="##any" to all element and attribute wildcards which did not previously have an explicit namespace attribute
Style	Where possible comments have been changed into annotations
Addition	Added element declaration for anyType
Deletion	Removed the ur-type element declaration and complexType definition
Deletion	Removed the NOTATION element declaration and complexType definition
Deletion	Removed global attribute declarations for attributes associated with sparse arrays.
Addition	Added arraySize global attribute decl and associated type definitions
Addition	Added itemType global attribute decl
Change	Amended arrayAttribute attribute group removing sparse array attributes and adding arraySize and itemType attributes.
Change	Changed arraySize type to allow nonNegativeIntegers instead of positiveIntegers

Editorial note: JJM/JBI	20020109
The following table refers to PatternSpecificRole. This has not been defined previously. Should this be single:Role instead?

SOAP Version 1.2 Part 2: Adjuncts - CBF

Editors' copy $Date: 2002/03/27 18:04:24 $ @@ @@ 2002

Abstract

Status of this Document

Table of Contents

Appendices

1 Introduction

1.1 Notational Conventions

2 The SOAP Data Model

2.1 Graph Edges

2.1.1 Edge labels

2.2 Graph Nodes

2.2.1 Single and Multi reference nodes

2.3 Values

3 SOAP Encoding

3.1 Rules for Encoding Graphs in XML

3.1.1 Encoding graph edges and nodes

3.1.2 Encoding simple values

3.1.3 Encoding compound values

3.1.4 Unique identifiers

3.1.4.1 id Attribute Information Item

3.1.4.2 ref Attribute Information Item

3.1.4.3 Constraints on id and ref attribute information items

3.1.5 Computing the Type Name property

3.1.5.1 itemType Attribute Information Item

3.1.6 arraySize Attribute Information Item

Value of enc:arraySize

3.2 Decoding Faults

4 SOAP RPC Representation

4.1 RPC and SOAP Body

4.2 RPC and SOAP Header

4.3 RPC Faults

5 A Convention for Describing Features and Bindings

5.1 Model and Properties

5.1.1 Properties

5.1.2 Property Scope

5.1.3 Properties and Features

6 Message Exchange Patterns

6.1 Single-Request-Response MEP

6.1.1 Message Exchange Pattern Name

6.1.2 Informal Description

6.1.3 Formal Description

6.1.4 Fault Handling

7 SOAP HTTP Binding

7.1 Introduction

7.2 Binding Name

7.3 Supported Message Exchange Patterns

7.4 Single-Request-Reponse Message Exchange Operation

7.4.1 Behaviour of Requesting SOAP Node

7.4.1.1 Requesting

7.4.1.2 Waiting

7.4.1.3 Receiving

7.4.1.4 Success and Fail

7.4.2 Behaviour of Responding SOAP Node

7.4.2.1 Receiving

7.4.2.2 Processing

7.4.2.3 Responding

7.4.2.4 Success and Fail

7.5 Features Expressed External to the Message Envelope

7.5.1 SOAP Action

SOAP Action HTTP Header

Required SOAP Action HTTP Header

7.5.2 Content Negotiation Feature

7.6 Security Considerations

8 References

8.1 Normative References

8.2 Informative References

A Mapping Application Defined Name to XML Name

Hex Digits

A.1 Rules for mapping application defined name to XML Name

A.2 Examples

B Using W3C XML Schema with SOAP Encoding (Non-Normative)

B.1 Validating using the minimum schema

B.2 Validating using the SOAP Encoding schema

B.3 Validating using more specific schemas

C SOAP HTTP Binding Examples (Non-Normative)

C.1 Sample Encoding of Call Requests

C.2 Sample Encoding of Response

D Acknowledgements (Non-Normative)

E Part 2 Change Log (Non-Normative)

Value of `enc:arraySize`