W3C

SOAP Version 1.2 Part 1: Messaging Framework

W3C Working Draft 2 October 2001

This version:
http://www.w3.org/TR/2001/WD-soap12-part1-20011002/
Latest version:
http://www.w3.org/TR/soap12-part1/
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 for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of four parts: an envelope that defines a framework for describing what is in a message and how to process it, a transport binding framework for exchanging messages using an underlying protocol, a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls and responses. Part 1 (this document) describes the SOAP envelope and SOAP transport binding framework; Part 2[1]describes the SOAP encoding rules, the SOAP RPC convention and a concrete HTTP binding specification.

Status of this Document

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 second 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 transport binding framework, and SOAP Version 1.2 Part 2: Adjuncts, which describes the SOAP encoding rules the SOAP RPC convention and a concrete HTTP binding specification.

For a detailed list of changes since the last publication of this document, refer to appendix C Part 1 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[11]). 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[12] per the email communication rules in the XML Protocol Working Group Charter[13].

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 Design Goals
    1.2 Notational Conventions
    1.3 Example of SOAP Message
    1.4 SOAP Terminology
        1.4.1 Protocol Concepts
        1.4.2 Data Encapsulation Concepts
        1.4.3 Message Sender and Receiver Concepts
2 SOAP Message Exchange Model
    2.1 SOAP Nodes
    2.2 SOAP Actors and SOAP Nodes
    2.3 Targeting SOAP Header Blocks
    2.4 Understanding SOAP Headers
    2.5 Processing SOAP Messages
3 Relation to XML
4 SOAP Envelope
    4.1 Envelope Encoding and Versioning
        4.1.1 SOAP encodingStyle Attribute
        4.1.2 Envelope Versioning Model
    4.2 SOAP Header
        4.2.1 Use of Header Attributes
        4.2.2 SOAP actor Attribute
        4.2.3 SOAP mustUnderstand Attribute
    4.3 SOAP Body
        4.3.1 Relationship between SOAP Header and Body
    4.4 SOAP Fault
        4.4.1 SOAP Fault Codes
        4.4.2 MustUnderstand Faults
5 SOAP Transport Binding Framework
    5.1 Binding to Application-Specific Protocols
    5.2 Security Considerations
6 References
    6.1 Normative References
    6.2 Informative References

Appendices

A Version Transition From SOAP/1.1 to SOAP Version 1.2
B Acknowledgements (Non-Normative)
C Part 1 Change Log (Non-Normative)
    C.1 SOAP Specification Changes
    C.2 XML Schema Changes


1 Introduction

SOAP version 1.2 provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding application defined data. This allows SOAP to be used in a large variety of systems ranging from messaging systems to remote procedure calls (RPC).

SOAP consists of four parts:

  1. The SOAP envelope (4 SOAP Envelope) construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.

  2. The SOAP binding framework (5 SOAP Transport Binding Framework) defines an abstract framework for exchanging SOAP envelopes between peers using an underlying protocol for transport. The SOAP HTTP binding [1](SOAP in HTTP) defines a concrete instance of a binding to the HTTP protocol[2].

  3. The SOAP encoding rules [1](SOAP Encoding) defines a serialization mechanism that can be used to exchange instances of application-defined datatypes.

  4. The SOAP RPC representation [1]( SOAP for RPC) defines a convention that can be used to represent remote procedure calls and responses.

These four parts are functionally orthogonal. In recognition of this, the envelope and the encoding rules are defined in different namespaces.

1.1 Design Goals

Two major design goals for SOAP are simplicity and extensibility. SOAP attempts to meet these goals by omitting features often found in messaging systems and distributed object systems such as:

  • distributed garbage collection;

  • boxcarring or batching of messages;

  • objects-by-reference (which requires distributed garbage collection);

  • activation (which requires objects-by-reference).

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

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/09/soap-envelope" and "http://www.w3.org/2001/09/soap-encoding" respectively.

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 the choice of any namespace prefix is arbitrary and not semantically significant.

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

This specification uses the augmented Backus-Naur Form (BNF) as described in [2].

1.3 Example of SOAP Message

The following example shows a simple notification message expressed in SOAP. The message contains the header block alertcontrol and the body block alert which are both application defined and not defined by SOAP. The header block contains the parameters priority and expires which may be of use to intermediaries as well as the ultimate destination of the message. The body block contains the actual notification message to be delivered.

Example: SOAP message containing a header block and a body block
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
 <env:Header>
  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="http://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

1.4 SOAP Terminology

1.4.1 Protocol Concepts

SOAP

The formal set of conventions governing the format and processing rules of a SOAP message and basic control of interaction between SOAP nodes generating and accepting SOAP messages for the purpose of exchanging information along a SOAP message path.

SOAP binding

The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of transmission. Example SOAP bindings include carrying a SOAP message within an HTTP message, or on top of TCP.

SOAP node

A SOAP node processes a SOAP message according to the formal set of conventions defined by SOAP. The SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages and accesses the services provided by the underlying protocols through SOAP bindings. Non-compliance with SOAP conventions can cause a SOAP node to generate a SOAP fault (see also SOAP receiver and SOAP sender).

1.4.2 Data Encapsulation Concepts

SOAP message

A SOAP message is the basic unit of communication between peer SOAP nodes.

SOAP envelope

The outermost syntactic construct or structure of a SOAP message defined by SOAP within which all other syntactic elements of the message are enclosed.

SOAP block

A syntactic construct or structure used to delimit data that logically constitutes a single computational unit as seen by a SOAP node. The type of a SOAP block is identified by the fully qualified name of the outer element for the block, which consists of the namespace URI and the local name. A block encapsulated within the SOAP header is called a header block and a block encapsulated within a SOAP body is called a body block.

SOAP header

A collection of zero or more SOAP blocks which may be targeted at any SOAP receiver within the SOAP message path.

SOAP body

A collection of zero or more SOAP blocks targeted at the ultimate SOAP receiver within the SOAP message path.

SOAP fault

A special SOAP block which contains fault information generated by a SOAP node.

The following diagram illustrates how a SOAP message is composed.

Encapsulation model illustrating the parts of a SOAP message.

1.4.3 Message Sender and Receiver Concepts

SOAP sender

A SOAP sender is a SOAP node that transmits a SOAP message.

SOAP receiver

A SOAP receiver is a SOAP node that accepts a SOAP message.

SOAP message path

The set of SOAP senders and SOAP receivers through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and the ultimate SOAP receiver.

Initial SOAP sender

The SOAP sender that originates a SOAP message as the starting point of a SOAP message path.

SOAP intermediary

A SOAP intermediary is both a SOAP receiver and a SOAP sender, target-able from within a SOAP message. It processes a defined set of blocks in a SOAP message along a SOAP message path. It acts in order to forward the SOAP message towards the ultimate SOAP receiver.

Ultimate SOAP receiver

The SOAP receiver that the initial sender specifies as the final destination of the SOAP message within a SOAP message path. A SOAP message may not reach the ultimate recipient because of a SOAP fault generated by a SOAP node along the SOAP message path.

2 SOAP Message Exchange Model

SOAP messages are fundamentally one-way transmissions from a SOAP sender to a SOAP receiver; however, SOAP messages are often combined to implement patterns such as request/response.

SOAP implementations can be optimized to exploit the unique characteristics of particular network systems. For example, the HTTP binding described in [1](SOAP in HTTP) provides for SOAP response messages to be delivered as HTTP responses, using the same connection as the inbound request.

2.1 SOAP Nodes

A SOAP node can be the initial SOAP sender, the ultimate SOAP receiver, or a SOAP intermediary, in which case it is both a SOAP sender and a SOAP receiver. SOAP does not provide a routing mechanism, however SOAP does recognise that a SOAP sender originates a SOAP message which is sent to an ultimate SOAP receiver, via zero or more SOAP intermediaries.

A SOAP node receiving a SOAP message MUST perform processing, generate SOAP faults, SOAP responses, and if appropriate send additional SOAP messages, as provided by the remainder of this specification.

2.2 SOAP Actors and SOAP Nodes

In processing a SOAP message, a SOAP node is said to act in the role of one or more SOAP actors, each of which is identified by a URI known as the SOAP actor name. Each SOAP node MUST act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/next", and can additionally assume the roles of zero or more other SOAP actors. A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor. The roles assumed MUST be invariant during the processing of an individual SOAP message; because this specification deals only with the processing of individual SOAP messages, no statement is made regarding the possibility that a given piece of software might or might not act in varying roles when processing more than one SOAP message.

SOAP nodes MUST NOT act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/none" (see also 4.2.2 SOAP actor Attribute).

While the purpose of a SOAP actor name is to identify a SOAP node, there are no routing or message exchange semantics associated with the SOAP actor name. For example, SOAP Actors MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP actor roles with names that are related more indirectly to message routing (e.g. "http://example.org/banking/anyAccountMgr") or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concerned software that the containing SOAP message is idempotent, and can safely be cached and replayed.)

2.3 Targeting SOAP Header Blocks

SOAP header blocks carry optional attribute information items with a local name of actor and a namespace name of http://www.w3.org/2001/09/soap-envelope (see 4.2.2 SOAP actor Attribute) that are used to target them to the appropriate SOAP node(s). SOAP header blocks with no such attribute information item and the SOAP body are implicitly targeted at the anonymous SOAP actor, implying that they are to be processed by the ultimate SOAP receiver. The specification refers to the (implicit or explicit) value of the SOAP actor attribute as the SOAP actor for the corresponding SOAP block (either a SOAP header block or a SOAP body block).

A SOAP block is said to be targeted to a SOAP node if the SOAP actor (if present) on the block matches (see [7]) a role played by the SOAP node, or in the case of a SOAP block with no actor attribute information item (including SOAP body blocks), if the SOAP node has assumed the role of the anonymous SOAP actor.

2.4 Understanding SOAP Headers

It is likely that specifications for a wide variety of header functions will be developed over time, and that each SOAP node MAY include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.

SOAP header blocks carry optional attribute information items with a local name of mustUnderstand and a namespace name of http://www.w3.org/2001/09/soap-envelope (see 4.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory. For such SOAP blocks the targeted SOAP node MUST: either process the SOAP block according to the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block; or not process the SOAP message at all, and fail (see 4.4 SOAP Fault).

2.5 Processing SOAP Messages

This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing must be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification should be taken to prevent the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules.

  1. Generate a single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand Faults) if one or more SOAP blocks targeted at the SOAP node are mandatory and are not understood by that node. If such a fault is generated, any further processing MUST NOT be done.

  2. Process SOAP blocks targeted at the SOAP node, generating SOAP faults (see 4.4 SOAP Fault) if necessary. A SOAP node MUST process SOAP blocks identified as mandatory. A SOAP node MAY process or ignore SOAP blocks not so identified. In all cases where a SOAP block is processed, the SOAP node must understand the SOAP block and must do such processing in a manner fully conformant with the specification for that SOAP block. Faults, if any, must also conform to the specification for the processed SOAP block. It is possible that the processing of particular SOAP block would control or determine the order of processing for other SOAP blocks. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a SOAP block, the order of processing is at the discretion of the SOAP node. SOAP nodes can make reference to any information in the SOAP envelope when processing a SOAP block. For example, a caching function can cache the entire SOAP message, if desired.

If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

3 Relation to XML

All SOAP messages have an XML Information Set[10]

Editorial note: JJM20010918
The following paragraph is related to the versioning model described in 4.1.2 and the transition appendix. It has been suggested to remove the duplication with Section 4.1.2 so that the relevant information is presented only once.

A SOAP node MUST ensure that all element information items and attribute information items in messages that it generates are correctly namespace qualified. A SOAP node MUST be able to process SOAP namespace information in messages that it receives. It MUST discard messages that have incorrect namespace information (see 4.4 SOAP Fault)

This document defines the following namespaces[7]:

Schema documents for these namespaces can be found by dereferencing the namespace identifiers. These schemas are normative.

A SOAP message MUST NOT contain a Document Type Declaration. A SOAP message MUST NOT contain processing instruction information items[8].

SOAP uses unqualified attribute information items with a local name of id and a type of ID in the http://www.w3.org/2001/XMLSchema namespace to specify the unique identifier of an encoded element.

SOAP uses unqualified attribute information items with a local name of href and a type of anyURI in the http://www.w3.org/2001/XMLSchema namespace to specify a reference to such a value, in a manner conforming to the XML Specification[8], XML Schema Specification[5], and XML Linking Language Specification[9].

A SOAP message MUST NOT impose any XML schema processing (assessment and validation) requirement on the part of any receiving SOAP node. Therefore, SOAP REQUIRES that all attribute information items, whether specified in this specification or whether they belong to a foreign namespace be carried in the serialized SOAP envelope.

4 SOAP Envelope

Editorial note: JJM20010918
Trailers have been removed from this Working Draft, and will also be omitted from the next version of this specification unless significant evidence for the contrary is provided.

A SOAP message has an XML Infoset that consists of a document information item with exactly one child, which is an element information item as described below.

The document element information item has:

4.1 Envelope Encoding and Versioning

4.1.1 SOAP encodingStyle Attribute

SOAP defines an encodingStyle attribute information item which can be used to indicate the encoding rules used to serialize a SOAP message.

The encodingStyle attribute information item has:

  • A local name of encodingStyle

  • A namespace name of http://www.w3.org/2001/09/soap-envelope

Editorial note: MJG20010802
The following sentence conflicts with the definition of the Body

It may appear on any element information item in the SOAP message. Its scope is that of its owner element information item and that element information item's descendants, unless a descendant itself owns such an attribute information item.

The encodingStyle attribute information item is a whitespace delimited list where each item in the list is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema. Each item in the list identifies a set of serialization rules that can be used to deserialize the SOAP message. The sets of rules should be listed in the order most specific to least specific.

Example: Example values for the encodingStyle attribute
encodingStyle="http://www.w3.org/2001/09/soap-encoding"
encodingStyle="http://example.org/encoding/restricted http://example.org/encoding/"
encodingStyle=""

The serialization rules defined by SOAP (see [1]SOAP Encoding) are identified by the URI "http://www.w3.org/2001/09/soap-encoding". SOAP messages using this particular serialization SHOULD indicate this using the SOAP encodingStyle attribute information item. In addition, all URIs syntactically beginning with "http://www.w3.org/2001/09/soap-encoding" indicate conformance with the SOAP encoding rules defined in [1](SOAP Encoding), though with potentially tighter rules added.

A value of the zero-length URI ("") explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.

4.1.2 Envelope Versioning Model

SOAP does not define a traditional versioning model based on major and minor version numbers. If a SOAP message is received by a SOAP 1.2 node in which the document element information item does NOT have a local name of Envelope and a namespace name of http://www.w3.org/2001/09/soap-envelope the SOAP node MUST treat this as a version error and generate a VersionMismatch SOAP fault (see 4.4 SOAP Fault). A SOAP VersionMismatch fault message MUST use the SOAP/1.1 envelope namespace "http://schemas.xmlsoap.org/soap/envelope/" (see A Version Transition From SOAP/1.1 to SOAP Version 1.2).

4.2 SOAP Header

SOAP provides a flexible mechanism for extending a SOAP message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as SOAP header blocks are authentication, transaction management, payment, etc.

The Header element information item has:

  • A local name of Header

  • A namespace name of http://www.w3.org/2001/09/soap-envelope

  • Zero or more namespace qualified attribute information item children.

  • Zero or more namespace qualified element information item children.

All child element information items of the SOAP Header are called SOAP header blocks.

Each SOAP header block element information item:

  • MUST be namespace qualified;

  • MAY have an encodingStyle attribute information item

  • MAY have an actor attribute information item

  • MAY have a mustUnderstand attribute information item

4.2.1 Use of Header Attributes

The SOAP header block attribute information items defined in this section determine how a SOAP receiver should process an incoming SOAP message, as described in 2 SOAP Message Exchange Model.

A SOAP sender generating a SOAP message SHOULD only use the SOAP header block attribute information items on child element information items of the SOAP Header element information item.

A SOAP receiver MUST ignore all SOAP header block attribute information items that are applied to other descendant element information items of the SOAP Header element information item.

Example: Example header with a single header block
<env:Header xmlns:env="http://www.w3.org/2001/09/soap-envelope" >
  <t:Transaction xmlns:t="http://example.org/2001/06/tx" env:mustUnderstand="1" >
    5
  </t:Transaction>
</env:Header>

SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 3 Relation to XML).

4.2.2 SOAP actor Attribute

As described in 2 SOAP Message Exchange Model, not all parts of a SOAP message may be intended for the ultimate SOAP receiver. SOAP defines an actor attribute information item that can be used to indicate the SOAP node at which a particular SOAP header block is targeted.

The actor attribute information item has the following Infoset properties:

  • A local name of actor;

  • A namespace name of http://www.w3.org/2001/09/soap-envelope;

  • A specified property with a value of true.

The type of the actor attribute information item is anyURI in the namespace http://www.w3.org/2001/XMLSchema . The value of the actor attribute information item is a URI that names a role that a SOAP node may assume.

At a SOAP receiver, the special URI "http://www.w3.org/2001/09/soap-envelope/actor/next" indicates that the SOAP header block is targetted at the current SOAP node. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP. Blocks marked with this special actor URI are subject to the same processing rules, outlined in 2 SOAP Message Exchange Model, as user defined URIs.

At a SOAP receiver, the special URI "http://www.w3.org/2001/09/soap-envelope/actor/none" indicates that the SOAP header block is not targetted at any SOAP node. This allows data which is common to several blocks to be referenced from them, without being processed.

Omitting the SOAP actor attribute information item implicitly targets the SOAP header block at the ultimate SOAP receiver.

4.2.3 SOAP mustUnderstand Attribute

As described in 2.4 Understanding SOAP Headers, the SOAP mustUnderstand attribute information item is used to indicate whether the processing of a SOAP header block is mandatory or optional at the target SOAP node.

The mustUnderstand attribute information item has the following Infoset properties:

  • A local name of mustUnderstand;

  • A namespace name of http://www.w3.org/2001/09/soap-envelope;

  • A specified property with a value of true.

The type of the mustUnderstand attribute information item is boolean in the namespace http://www.w3.org/2001/XMLSchema. Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".

The SOAP mustUnderstand attribute information item allows for robust evolution of SOAP itself, of related services such as security mechanisms, and of applications using SOAP. SOAP blocks tagged with a SOAP mustUnderstand attribute information item with a value of "true" MUST be presumed to somehow modify the semantics of their parent or peer element information items. Tagging SOAP blocks in this manner assures that this change in semantics will not be silently (and, presumably, erroneously) ignored by those who may not fully understand it. Specific rules for processing header blocks with mustUnderstand attribute information items are provided in 2.4 Understanding SOAP Headers and 2.5 Processing SOAP Messages.

The SOAP mustUnderstand attribute information item is useful for detecting situations in which a SOAP block targetted at a node is not understood (see 2.4 Understanding SOAP Headers) by that node; it is not intended as a mechanism for detecting errors in routing, misidentification of nodes, failure of a node to serve in its intended role(s), etc. any of which may result in a failure to even attempt processing of a given header block. For that reason, this specification does not require any fault to be generated based on the presence or value of the mustUnderstand attribute information item on a header block not targeted to the processing node. Processors SHOULD NOT generate such faults, and this specification includes no standard representation for such a fault. This rule applies to the endpoint as well as to intermediaries; it is not in general an error for a mustUnderstand header block targeted to a node other than the endpoint to reach the endpoint without having been processed.

Note:

SOAP extensions can be defined for indicating the order in which processing is to occur, and for generating faults when a header entry is not processed in the appropriate order. Specifically, it is possible to create SOAP header blocks which are themselves targeted to the endpoint (or intermediaries), have a mustUnderstand attribute information item with a value of "true", and which have as their semantic a requirement to generate some particular fault if other headers have inadvertently survived past the intended point in the message path message (presumably due to a failure to reach the intended processing node earlier in the path). Such extensions MAY depend on the presence or value of the mustUnderstand attribute information item in the surviving headers when determining whether an error has occurred.

4.3 SOAP Body

The SOAP Body element information item provides a simple mechanism for exchanging mandatory information intended for the ultimate SOAP receiver of a SOAP message. Example uses of SOAP Body include marshalling RPC calls and error reporting.

The Body element information item has:

  • A local name of Body

  • A namespace name of http://www.w3.org/2001/09/soap-envelope

  • Zero or more element information item children.

Editorial note: MJG20010802
The description of Body does not allow additional attributes.

All child element information items of the SOAP Body element information item are called SOAP body blocks.

Each SOAP body block element information item:

  • MAY be namespace qualified.

  • MAY have an encodingStyle attribute information item

SOAP defines one particular SOAP body block, the SOAP fault, which is used for reporting errors (see 4.4 SOAP Fault).

4.3.1 Relationship between SOAP Header and Body

While both SOAP Header and SOAP Body are defined as independent element information items, they are in fact related. The relationship between a SOAP body block and a SOAP header block is as follows: a SOAP body block is semantically equivalent to a SOAP header block targeted at the default actor and with a SOAP mustUnderstand attribute information item with a value of true. The default actor is indicated by omitting the actor attribute information item (see 4.2.2 SOAP actor Attribute).

4.4 SOAP Fault

The SOAP Fault element information item is used to carry error and/or status information within a SOAP message. If present, the SOAP Fault MUST appear as a SOAP body block and MUST NOT appear more than once within a SOAP Body.

The Fault element information item has:

  • A local name of Fault;

  • A namespace name of http://www.w3.org/2001/09/soap-envelope;

  • Two or more child element information items in order as follows:

    1. A mandatory faultcode element information item as described below;

    2. A mandatory faultstring element information item as described below;

    3. An optional faultactor element information item as described below;

    4. An optional detail element information item as described below.

The faultcode element information item has:

  • A local name of faultcode

  • A namespace name which is empty

The type of the faultcode element information item is QName in the http://www.w3.org/2001/XMLSchema namespace. It is intended for use by software to provide an algorithmic mechanism for identifying the fault. SOAP defines a small set of SOAP fault codes covering basic SOAP faults (see 4.4.1 SOAP Fault Codes)

The faultstring element information item has:

  • A local name of faultstring;

  • A namespace name which is empty.

The type of the faultstring element information item is string in the http://www.w3.org/2001/XMLSchema namespace. It is intended to provide a human readable explanation of the fault and is not intended for algorithmic processing. This element information item is similar to the 'Reason-Phrase' defined by HTTP[2] and SHOULD provide at least some information explaining the nature of the fault.

The faultactor element information item has:

  • A local name of faultactor

  • A namespace name which is empty

The type of the faultactor element information item is anyURI in the http://www.w3.org/2001/XMLSchema namespace. It is intended to provide information about which SOAP node on the SOAP message path caused the fault to happen (see 2 SOAP Message Exchange Model). It is similar to the SOAP actor attribute information item (see 4.2.2 SOAP actor Attribute) but instead of indicating the target of a SOAP header block, it indicates the source of the fault. The value of the faultactor element information item identifies the source of the fault. SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item The ultimate SOAP receiver MAY include this element information item to indicate explicitly that it generated the fault.

The detail element information item has:

  • A local name of detail;

  • A namespace name which is empty;

  • Zero or more attribute information items;

  • Zero or more child element information items.

The detail element information item is intended for carrying application specific error information related to the SOAP Body. It MUST be present when the contents of the SOAP Body could not be processed successfully . It MUST NOT be used to carry error information about any SOAP header blocks. Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.

The absence of the detail element information item indicates that a SOAP Fault is not related to the processing of the SOAP Body. This can be used to find out whether the SOAP Body was at least partially processed by the ultimate SOAP receiver before the fault occurred, or not.

All child element information items of the detail element Information Item are called detail entries.

Each such element information item:

  • MAY be namespace qualified;

  • MAY have an encodingStyle attribute information item.

The SOAP encodingStyle attribute information item is used to indicate the encoding style used for the detail entries (see 4.1.1 SOAP encodingStyle Attribute).

4.4.1 SOAP Fault Codes

The SOAP faultcode values defined in this section MUST be used as values for the SOAP faultcode element information item when describing faults defined by SOAP 1.2 Part 1 (this document). The namespace identifier for these SOAP faultcode values is "http://www.w3.org/2001/09/soap-envelope". Use of this namespace is recommended (but not required) in the specification of methods defined outside of the present specification.

SOAP faultcode values are defined in an extensible manner that allows for new SOAP faultcode values to be defined while maintaining backwards compatibility with existing SOAP faultcode values. The mechanism used is very similar to the 1xx, 2xx, 3xx etc basic status classes classes defined in HTTP (see [2] section 10). However, instead of integers, they are defined as XML qualified names[7]. The character "." (dot) is used as a separator of SOAP faultcode values indicating that what is to the left of the dot is a more generic fault code value than the value to the right. This is illustrated in the following example.

Example: Sample authentication fault code
Client.Authentication

The faultcode values defined by SOAP are listed in the following table.

Name Meaning
VersionMismatch The processing party found an invalid namespace for the SOAP Envelope element information item (see 4.1.2 Envelope Versioning Model)
MustUnderstand An immediate child element information item of the SOAP Header element information item that was either not understood or not obeyed by the processing party contained a SOAP mustUnderstand attribute information item with a value of "true" (see 4.2.3 SOAP mustUnderstand Attribute)
DataEncodingUnknown A header or body block targetted at the current SOAP node is scoped ( See 4.1.1 SOAP encodingStyle Attribute) with a data encoding that the current node does not support.
Client The Client class of errors indicate that the message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change. See also 4.4 SOAP Fault for a description of the SOAP fault detail sub-element.
Server The Server class of errors indicate that the message could not be processed for reasons not directly attributable to the contents of the message itself but rather to the processing of the message. For example, processing could include communicating with an upstream SOAP node, which did not respond. The message may succeed at a later point in time. See also 4.4 SOAP Fault for a description of the SOAP fault detail sub-element.

4.4.2 MustUnderstand Faults

When a SOAP node generates a MustUnderstand fault, it SHOULD provide, in the generated fault message, header blocks as described below which detail the qualified names (QNames, per the XML Schema Datatypes specification[5]) of the particular header block(s) which were not understood.

Each such header block element information item has:

  • A local name of Misunderstood;

  • A namespace name of http://www.w3.org/2001/09/soap-faults;

  • A qname attribute information item as desribed below.

The qname attribute information item has the following Infoset properties:

  • A local name of qname;

  • A namespace name which is empty;

  • A specified property with a value of true.

The type of the qname attribute information item is QName in the http://www.w3.org/2001/XMLSchema namespace. Its value is the QName of a header block which the faulting node failed to understand.

Consider the following message:

Example: SOAP envelope that will cause a SOAP MustUnderstand fault if Extension1 or Extension2 are not understood
<env:Envelope xmlns:env='http://www.w3.org/2001/09/soap-envelope'>
  <env:Header>
    <abc:Extension1 xmlns:abc='http://example.org/2001/06/ext'
                       env:mustUnderstand='1' />
    <def:Extension2 xmlns:def='http://example.com/stuff'
                       env:mustUnderstand='1' />
  </env:Header>
  <env:Body>
  . . .
  </env:Body>
</env:Envelope>

The above message would result in the fault message shown below if the recipient of the initial message does not understand the two header elements abc:Extension1 and def:Extension2.

Example: SOAP fault generated as a result of not understanding Extension1 and Extension2
<env:Envelope xmlns:env='http://www.w3.org/2001/09/soap-envelope'
                      xmlns:f='http://www.w3.org/2001/09/soap-faults' >
  <env:Header>
    <f:Misunderstood qname='abc:Extension1'
                                xmlns:abc='http://example.org/2001/06/ext' />
    <f:Misunderstood qname='def:Extension2'
                                xmlns:def='http://example.com/stuff' />
  </env:Header>
  <env:Body>
    <env:Fault>
      <faultcode>env:MustUnderstand</faultcode>
      <faultstring>One or more mandatory headers not understood</faultstring>
    </env:Fault>
  </env:Body>
</env:Envelope>

Note that when serializing the qname attribute information item there must be an in-scope namespace declaration for the namespace name of the misunderstood header and the value of the attribute information item must use the prefix of such a namespace declaration

Note also that there is no guarantee that each MustUnderstand error contains ALL misunderstood header QNames. SOAP nodes MAY generate a fault after the first header block that causes an error containing details about that single header block only, alternatively SOAP nodes MAY generate a combined fault detailing all of the MustUnderstand problems at once.

5 SOAP Transport Binding Framework

Editorial note: JJM20010920
This section will, in due time, contain a complete description of the SOAP Transport Binding Framework. This framework will describe what logical operations are necessary to use a new or existing transport to transfer SOAP messages from an initial SOAP sender to an ultimate SOAP recipient. The HTTP binding provided in the second part of this specification will then be rewritten to use the terminology and concepts defined in this section. Currently, this section contains a fraction of the text that will be available in the final version.

5.1 Binding to Application-Specific Protocols

Some underlying protocols may be designed for a particular purpose or application profile. SOAP bindings to such protocols MAY use the same endpoint identification (e.g., TCP port number) as the underlying protocol, in order to reuse the existing infrastructure associated that protocol.

However, the use of well-known ports by SOAP may incur additional, unintended handling by intermediaries and underlying implementations. For example, HTTP is commonly thought of as a 'Web browsing' protocol, and network administrators may place certain restrictions upon its use, or may interpose services such as filtering, content modification, routing, etc. Often, these services are interposed using port number as a heuristic.

As a result, binding definitions for underlying protocols with well-known default ports or application profiles SHOULD document potential (harmful?) interactions with commonly deployed infrastructure at those default ports or in-conformance with default application profiles. Binding definitions SHOULD also illustrate the use of the binding on a non-default port as a means of avoiding unintended interaction with such services.

5.2 Security Considerations

Editorial note: MJG20010926
This section will in a future revision provide some guidelines for the security considerations that should be taken into account when using the binding framework defined in this document.

6 References

6.1 Normative References

1
W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 October 2001 (See http://www.w3.org/TR/2001/WD-soap12-part2-20011002/.)
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 Proposed Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 20 December 2000. (See http://www.w3.org/TR/2000/PR-xlink-20001220/.)
10
W3C Proposed Recommendation "XML Information Set", John Cowan, Richard Tobin, 10 August 2001. (See http://www.w3.org/TR/2001/PR-xml-infoset-20010810/.)

6.2 Informative References

11
XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)
12
XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)
13
XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)
14
W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/SOAP/.)

A Version Transition From SOAP/1.1 to SOAP Version 1.2

Editorial note20010806
The scope of the mechanism provided in this section is for transition between SOAP/1.1 and SOAP version 1.2. The Working Group is considering providing a more general transition mechanism that can apply to any version.| Such a general mechanism may or may not be the mechanism provided here depending on whether it is deemed applicable.

The SOAP/1.1 specification[14] says the following on versioning in section 4.1.2:

"SOAP does not define a traditional versioning model based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the "http://schemas.xmlsoap.org/soap/envelope/" namespace. If a message is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace, the application MUST treat this as a version error and discard the message. If the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message (see section 4.4) using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace."

That is, rather than a versioning model based on shortnames (typically version numbers), SOAP uses a declarative extension model which allows a sender to include the desired features within the SOAP envelope construct. SOAP says nothing about the granularity of extensions nor how extensions may or may not affect the basic SOAP processing model. It is entirely up to extension designers be it either in a central or a decentralized manner to determine which features become SOAP extensions.

The SOAP extensibility model is based on the following three basic assumptions:

  1. SOAP versioning is directed only at the SOAP envelope. It explicitly does not address versioning of blocks, encodings, protocol bindings, or otherwise.

  2. A SOAP node must determine whether it supports the version of a SOAP message on a per message basis. In the following, "support" means understanding the semantics of the envelope version identified by the QName of the Envelope element information item:

    • A SOAP node receiving an envelope that it doesn't support must not attempt to process the message according to any other processing rules regardless of other up- or downstream SOAP nodes.

    • A SOAP node may provide support for multiple envelope versions. However, when processing a message a SOAP node must use the semantics defined by the version of that message.

  3. It is essential that the envelope remains stable over time and that new features are added using the SOAP extensibility mechanism. Changing the envelope inherently affects interoperability, adds complexity, and requires central control of extensions -- all of which directly conflicts with the SOAP requirements.

The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:

  1. Because of the SOAP/1.1 rules, a compliant SOAP/1.1 node receiving a SOAP Version 1.2 message will generate a VersionMismatch SOAP fault using an envelope qualified by the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier.

  2. A SOAP Version 1.2 node receiving a SOAP/1.1 message may either process the message as SOAP/1.1 or generate a SOAP VersionMismatch fault using the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier. As part of the SOAP VersionMismatch fault, a SOAP Version 1.2 node should include the list of envelope versions that it supports using the SOAP upgrade extension identified by the "http://www.w3.org/2001/09/soap-upgrade" identifier.

The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred. Following is an example of a VersionMismatch fault generated by a SOAP Version 1.2 node including the SOAP upgrade extension:

Example: VersionMismatch fault generated by a SOAP Version 1.2 node, and including a SOAP upgrade extension
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header>
    <V:Upgrade xmlns:V="http://www.w3.org/2001/09/soap-upgrade">
      <envelope qname="ns1:Envelope" xmlns:ns1="http://www.w3.org/2001/09/soap-envelope"/>
    </V:Upgrade>
  </env:Header>
  <env:Body>
    <env:Fault>
      <faultcode>env:VersionMismatch</faultcode>
      <faultstring>Version Mismatch</faultstring>
    </env:Fault>
  </env:Body>
</env:Envelope>

Note that existing SOAP/1.1 nodes are not likely to indicate which envelope versions they support. If nothing is indicated then this means that SOAP/1.1 is the only supported envelope.

B 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 Mischinsky (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.

C Part 1 Change Log (Non-Normative)

C.1 SOAP Specification Changes

Date Author Description
20010926 MJG Updated member list
20010926 MJG Removed extra double quotes around certain URLs
20010921 MJG Changed targetNamespace attribute of faults schema to http://www.w3.org/2001/09/soap-faults
20010921 MJG Changed targetNamespace attribute of upgrade schema to http://www.w3.org/2001/09/soap-upgrade
20010921 MJG Changed targetNamespace attribute of envelope schema to http://www.w3.org/2001/09/soap-envelope
20010921 MJG Modified content model of Envelope complex type in envelope schema to disallow content after the Body element.
20010920 JJM Included MarkN's text regarding issue 11 and 13 as amended by Stuart in the specification and expand the ednote appropriately.
20010920 JJM Change the namespace of the envelope to http://www.w3.org/2001/09/...
20010918 JJM Incorporated several editorial comments from Stuart Williams.
20010918 JJM Removed reference to trailer from the "SOAP Envelope" section.
20010914 JJM Fixed issues 124, 126, 127, 128 and 132.
20010914 JJM Used the rewrite from Mark Nottingham for section "SOAPAction attribute".
20010914 JJM Incoporated text from Mark Nottingham clarifying the role of none blocks.
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. Removed "as illustrated above" from section 2. Added missing parantheses in sections 2.5 and 4.1.1.
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 encoding schema changes. Added bibref entries for cross references to Part 2, 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.
20010830 MJG Added an element declaration for a Fault element of type Fault to the envelope schema
20010830 JJM Removed terminology not relevant for part1.
20010830 JJM Moved some introductory examples to part2.
20010830 JJM Moved SOAP example appendix to part2.
20010830 JJM Added a paragraph to section 1 pointing to part2 for encoding, rpc and http binding.
20010829 JJM Added a placeholder for the forthcoming Transport Binding Framework section.
20010829 JJM Updated the spec's title.
20010829 JJM Replaced specref with xspecref for references to Part2 items.
20010829 JJM Added bibliography entry for SOAP 1.2 Part 2.
20010829 JJM Removed former sections 5, 6, 7 and 8.
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 David's 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 doesn't 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 Fallside's 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.

C.2 XML Schema Changes

The envelope 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
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 envelope 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-envelope
Clarification Changed element and attribute wildcards in Envelope complex type to namespace="##other"
Clarification Changed element and attribute wildcards in Header complex type to namespace="##other"
Clarification Added explicit namespace="##any" to element and attribute wildcards in Body complex type
Clarification Added explicit namespace="##any" to element and attribute wildcards in detail complex type
Clarification Added an element wildcard with namespace="##other" to the Fault complex type
Name Changed item type of encodingStyle from uri-reference to anyURI
Name Changed type of actor attribute from uri-reference to anyURI
Name Changed type of faultactor attribute from uri-reference to anyURI
Semantic Added processContents="lax" to all element and attribute wildcards
Semantic Changed type of the mustUnderstand 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.
Style Where possible comments have been changed into annotations
Syntax Changed all occurences of maxOccurs="*" to maxOccurs="unbounded"
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

In addition several changes occured in the names of datatypes in the XML Schema specification and some datatypes were removed. The following table lists those changes.

Datatype Class Description
timeDuration Renamed New name is duration
timeInstant Renamed New name is dateTime
recurringDuration Removed The recurringDuration datatype no longer exists.
recurringInstant Removed The recurringInstant datatype no longer exists.
binary Removed The binary datatype has been replaced by the hexBinary and base64Binary datatypes.
month Renamed New name is gYearMonth
timePeriod Removed The timePeriod datatype no longer exists
year Renamed New name is gYear
century Removed The century datatype no longer exists
recurringDate Renamed New name is gMonthDay
recurringDay Renamed New name is gDay