SOAP Version 1.2 Part 2: Adjuncts

Editors' copy Mar 23 2002

This version:
soap12-part2.html
Latest version:
http://www.w3.org/TR/soap12-part2/
Previous versions:
http://www.w3.org/TR/2001/WD-soap12-20010709/
Editors:
Martin Gudgin, DevelopMentor
Marc Hadley, Sun Microsystems
Jean-Jacques Moreau, Canon
Henrik Frystyk Nielsen, Microsoft

Abstract

SOAP Version 1.2 is a lightweight protocol intended for exchange of structured information in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. The SOAP specification is split 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. Adjuncts include a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls and responses.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is the fourth W3C Working Draft of the SOAP Version 1.2 specification for review by W3C members and other interested parties. It has been produced by the XML Protocol Working Group (WG), which is part of the XML Protocol Activity.

The specification has been split into two documents: SOAP Version 1.2 Part 1: Messaging Framework which describes the SOAP envelope and the SOAP underlying protocol binding framework, and SOAP Version 1.2 Part 2: Adjuncts, which describes the SOAP Encoding rules, the SOAP RPC Representation and a concrete HTTP binding specification.

For a detailed list of changes since the last publication of this document, refer to appendix E Part 2 Change Log. A list of open issues against this document can be found at "http://www.w3.org/2000/xp/Group/xmlp-issues".

Comments on this document should be sent to xmlp-comments@w3.org (public archive [13]). It is inappropriate to send discussion emails to this address.

Discussion of this document takes place on the public xml-dist-app@w3.org mailing list [14] under the email communication rules in the XML Protocol Working Group Charter [15].

This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.

Table of Contents

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
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 Message Exchange Operation
7.4.1 Single-Request-Response MEP
7.4.1.1 Behaviour of Requesting SOAP Node
7.4.1.1.1 Requesting State
7.4.1.1.2 Waiting State
7.4.1.1.3 Receiving State
7.4.1.1.4 Success and Fail
7.4.1.2 Behaviour of Responding SOAP Node
7.4.1.2.1 Receiving
7.4.1.2.2 Processing
7.4.1.2.3 Responding
7.4.1.2.4 Success and Fail
7.5 Features Expressed External to the Message Envelope
7.5.1 SOAP Action
7.6 Security Considerations
8 References
8.1 Normative References
8.2 Informative References

Appendices

A Mapping Application Defined Name to XML Name
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)
E.1 SOAP Specification Changes
E.2 XML Schema Changes


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:

  1. The SOAP Data Model represents application-defined data as a directed, edge-labeled graph of nodes (see 2 The SOAP Data Model).

  2. 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).

  3. 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).

  4. 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 this 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:

  1. Their local name values are the same.

  2. 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:

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

  2. A non-terminal whose outbound edges are distinguished solely by label is known as a "struct".

  3. 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:

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

  2. 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:

  1. If the element information item representing the edge does not have a refattribute 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.

  2. If the element information item representing the edge does have a refattribute 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 idattribute 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 idattribute 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:

  1. 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:
  2. 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 distinguised only by position ( "array" ) then the local name and namespace name properties of the element information item are not significant.

  3. The following rules apply to the encoding of a node that represents an "array":

  4. 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:nilattribute information item.

3.1.4 Unique identifiers

3.1.4.1 id Attribute Information Item

The idattribute 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 idattribute information item is ID in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the idattribute information item is a unique identifier that can be refered to by a refattribute information item (see 3.1.4.2 ref Attribute Information Item).

3.1.4.2 ref Attribute Information Item

The refattribute 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 refattribute information item is IDREF in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the refattribute information item is a reference to a unique identifier defined by an idattribute 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 refattribute information item MUST also be the value of exactly one idattribute information item.

A refattribute information item and an idattribute 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;

  1. If the element information item representing the graph node has an xsi:typeattribute information item amongst its attributes then the type name property of the graph node is the value of the xsi:typeattribute 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.

  2. Otherwise if the parent element information item of the element information item representing the graph node has a soap:itemTypeattribute 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:itemTypeattribute information item

  3. 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 itemTypeattribute 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 itemTypeattribute information item is QName in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the itemTypeattribute 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 arraySizeattribute 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 arraySizeattribute 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 refattribute 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 encodingStyleattribute 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:

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 encodingStyleattribute 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):

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

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

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

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

  5. 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:

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

SOAP State Transition diagram.

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 Input NextState Action
Requesting Fail Set "context:FailureReason" to "transmissionFailure"
Waiting
Waiting Fail Set "context:FailureReason" to "NoResponse"
Receiving
Receiving Fail Set "context:FailureReason" to "ReceptionFailure"
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 Response Message

Responding SOAP Node State transition table
CurrentState Input NextState Action
Receiving Fail Set "context:FailureReason" to "ReceptionFailure"
Processing

Set "context:ImmediateSender" to denote the sender of the Request Message (if determinable)

Set "context:CurrentMessage" with abstraction representing Request Message

Pass control of message exchange context to SOAP Processor.

Processing Fail Set "context:FailureReason" to "NoResponse";
Responding

SOAP Processor has replaced "context:CurrentMessage" with an abstraction of the Response Message.;

Initiate transmission of Response Message.

Responding Fail Set "context:FailureReason" to "transmissionFailure"
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 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

This protocol binding specification adheres to the SOAP Binding Framework (see SOAP Protocol Binding Framework), and as such uses abstract properties as a descriptive tool for defining the functionality of certain features.

The purpose of the SOAP HTTP Binding is to provide a binding of SOAP to HTTP. It is important to note that use of the SOAP HTTP Binding is optional and that nothing precludes the specification of different bindings to other protocols, or indeed to define 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 me to be said to "conform to the SOAP 1.2 HTTP binding."

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 tables lists the standard prefix mappings which we assume to hold throughout this specification:

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

HTTP applications MUST use the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges. Please see [12] for parameters defined by this mecia type and their recommended use.

7.2 Binding Name

The binding described here is identified with the URI:

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

The binding described here is provided as a default binding when using HTTP as the underlying protocol.

7.3 Supported Message Exchange Patterns

An instance of an underlying protocol binding to HTTP [2] conforming to this underlying protocol binding specification MUST support the following message exchange pattern:

Editorial note: JJM/TBTF 20011205
Here I think we should say that the request part is mapped to a HTTP request and the response to a HTTP response - obvious but worth saying.

7.4 Message Exchange Operation

The Underlying Protocol Binding Framework (see SOAP Underlying 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 and vice versa.

7.4.1 Single-Request-Response MEP

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 take on the role (i.e. the property single:Role) of RequestingSOAPNode.

  • A SOAP Node instantiated at an HTTP server may take on the role (ie. the property single:Role) of RespondingSOAPNode.

The remainder of this section consists of descriptions of 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.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.

Requesting SOAP Node State Transition Diagram
Editorial note: JJM/SKW 20011205
std included here, some suggest we should include it here, others suggest referencing the mep description and avoiding the repetition.
7.4.1.1.1 Requesting State
Requesting State
Statename Requesting
Preconditions See 6.1.3 Formal Description
Description Formulate and send HTTP Request (see table below)
Actions on Leaving State
Transitions Event/Condition NextState Failure Reason
Successfully sent HTTP Request Waiting N/A
Failure to send HTTP Request Fail fail:TransmissionFailure

HTTP Request Fields
HTTP Request Fields 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)
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.

Editorial note: JJM/SKW - Pending TBTF 20011205
Note that we have said nothing about attachments here. The simple interpretation is that this binding does not support attachments. I think that we could do further work to abstract message encapsulation as a feature... in which case we would have some properties that would influence the selection of content type in the second step above and which would influence the message serialisation.
7.4.1.1.2 Waiting State
Waiting State
Statename Waiting
Preconditions None
Description Wait for HTTP Response
Actions on Leaving State
  • Instantiate or replace the property context:ImmediateSender with a URI value that denotes the sender of the HTTP response (if known)

  • In all cases, any HTTP headers that are significant to features expressed outside the SOAP envelope are processed in accordance with the relevant feature specification.

Transitions Event/Condition NextState Failure Reason
Received HTTP Response Status Line and HTTP Headers (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.

Editorial note: JJM/SKW - Pending TBTF 20011205
This is a large table and it would be good shrink it somewhat. It does not cover all generally possible HTTP status codes and may cover more than it should. This is one that we should be able to address provided the direction and style are to peoples taste.

Editorial note: JJM/SKW - Pending TBTF 20011205
Do we need the "*xx" rows at all?

HTTP status code dependent transitions upon reception of an HTTP status line and response headers.
HTTP Status Code HTTP reason phrase (informative) 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. Then 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 or replaced Property QName Property Value
context:CurrentMessage Replace contents with a value that represents and empty SOAP Envelope.
context:ImmediateSender If known instantiate this property with a URI denoting the sender of the HTTP response.
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 or replaced Property QName Property Value
context:FailureReason fail:BadRequest
401 Unauthorized

Indicates that the HTTP Request requires authorization.

Requesting
Instantiated or replaced Property QName 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 or replaced Property QName 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 or replaced Property QName 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 or replaced Property QName 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 or replaced Property QName 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.1.3 Receiving State
Receiving State
Statename Receiving
Preconditions
Description Receive HTTP response entity body, which is assumed to be a SOAP envelope serialized according to XML 1.0.
Actions on Leaving State On transitions to Success, instantiate or replace the property context:CurrentMessage with an Infoset representation of the serialized envelope in the response body.
Transitions Event/Condition NextState Failure Reason
Well formed Response Message Received Success
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.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.1.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.

Responding SOAP Node State Transition Diagram
Editorial note: JJM/SKW 20011205
std included here, some suggest we should include it here, others suggest referencing the mep description and avoiding the repetition.

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.1.2.1 Receiving
Receiving State
Statename Receiving
Preconditions Reception of an HTTP POST request at an HTTP endpoint bound to the local SOAP Node.
Description Receive and validate the inbound Request Message
Actions on Leaving State
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.

Editorial note: JJM/SKW 20011205
As described this model tends to hide a malformed message from the local SOAP Node and handle the malformation in the binding - basically because it would not be possible to instantiate the CurrentMessage to pass up for processing. An alternate formulation might be to allow CurrentMessage to carry badly formed messages and let the SOAP processor/node deal with it. As presented here we can have define the bindings behaviour with respect to particular failures.

Receiving State
Problem with Message HTTP Status Code HTTP reason phrase (informative) SOAP fault
Well-formed XML, unsupported SOAP Envelope Version ??? ??? env:VersionMismatch (see SOAP Version Transition)
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.1.2.2 Processing
Processing State
Statename Processing
Preconditions
Description The SOAP Node processes the Request Message and replace it a Response Message.
Actions on Leaving State
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.1.2.3 Responding
Responding State
Statename Responding
Preconditions context:CurrentMessage contains a value that represents the Response Message (which may contain a SOAP fault).
Description Formulate and send Response Message (see table below)
Actions on Leaving State
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.

Responding State
HTTP Response Field
HTTP status line Set according to the following table
Content-Type header "application/soap+xml" (see 7.1 Introduction)
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.

Responding State SOAP Faults
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.1.2.4 Success and Fail

These are the terminal states of 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 Receivers 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.

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)
HTTP Client
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)

HTTP Server

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

  1. XML Name has two parts: Prefix and LocalPart. Let Prefix be computed per the rules and constraints specified in Namespaces in XML [7].

  2. 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 T1, T2, ... , TN be the characters of TAG, in order from left to right.

  3. Let M be the implementation-defined mapping of the characters of the application to characters of Unicode.

  4. For each i between 1 (one) and N, let Mi be M(Ti).

  5. For each i between 1 (one) and N, let Xi be the Unicode character string defined by the following rules.

    Case:

    1. If Ti has no mapping to Unicode (i.e. M(Ti) is undefined), then Xi is implementation-defined

    2. If i<=N-1, Ti is "_" (underscore), and Ti+1 is "x" (lowercase letter x), then let Xi be "_x005F_".

    3. If i=1, N>=3, T1 is either "x" (lowercase letter x) or "X" (uppercase letter X), T2 is either "m" (lowercase letter m) or "M" (uppercase letter M), and T3 is either "l" (lowercase letter l) or "L" (uppercase letter L), then let Xi be "_xFFFF_"T1

    4. If Ti is not a valid XML NCName character or if i=1 (one) and T1 is not a valid first character of an XML NCName, then:

      Let U1, U2, ... , U8 be the eight hex digits [PROD: 7] such that Ti is "U+"U1U2 ... U8 in the UCS-4 encoding.

      Case:

      1. If U1=0, U2=0, U3=0, and U4=0, then let Xi="_x"U5U6U7U8"_".

        This case implies that Ti has a UCS-2 encoding, which is U+U5U6U7U8.

      2. Otherwise, let Xi be "_x"U1U2U3U4U5U6U7U8"_".

    5. Otherwise, let Xi be Mi. That is, any character in TAG that is a valid character in an XML NCName is simply copied.

  6. Let LocalPart be the character string concatenation of X1, X2, ... , XN in order from left to right.

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

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