SOAP Version 1.2 Part 2: Adjuncts

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). In previous versions of this specification the SOAP name was an acronym. This is no longer the case.

Part 2 of the SOAP specification (this document) describes:

The SOAP data model (3 The SOAP Data Model) defines the data model underlying the SOAP encoding and SOAP RPC representation.
The SOAP encoding rules (4 SOAP Encoding) define a serialization mechanism that can be used to exchange instances of application-defined datatypes.
The SOAP RPC representation (5 Using SOAP for RPC) defines a convention that can be used to represent remote procedure calls and responses.
The SOAP HTTP binding (8 Default HTTP Binding defines a concrete instance of a binding to the HTTP protocol[2].

Part 1[1] of the SOAP specification describes the SOAP envelope (SOAP Envelope) and the SOAP binding framework (SOAP Transport Binding Framework).

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 [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/12/soap-envelope" and "http://www.w3.org/2001/12/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].

Editorial note: MJH	20011029
This spec no longer uses ABNF (Issue 162). We need a reference for BNF instead

1.2 Examples of SOAP Messages

SOAP messages may be bound to different underlying protocols and used in a variety of message exchange patterns. The following two examples show SOAP used in connection with HTTP as the underlying protocol taking advantage of the request/response mechanism provided by HTTP (8 Default HTTP Binding).

The following example shows a sample SOAP/HTTP request. The SOAP/HTTP request contains a body element called GetLastTradePrice which takes a single parameter, the ticker symbol for a stock. Note that the GetLastTradePrice element is not defined by SOAP itself. The service's response to this request contains a single parameter, the price of the stock. The SOAP Envelope element is the top element of the XML document representing the SOAP message. XML namespaces are used to disambiguate SOAP identifiers from application specific identifiers.

Example: Sample SOAP Message embedded in an HTTP Request

POST /StockQuote HTTP/1.1
Host: www.example.org
Content-Type: application/soap; 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:GetLastTradePrice
        env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
        xmlns:m="http://example.org/2001/06/quotes">
    <symbol>DIS</symbol>
  </m:GetLastTradePrice>
 </env:Body>
</env:Envelope>

The following example shows the SOAP message sent by the StockQuote service in response to the request shown in the preceeding example.

Example: Sample SOAP Message embedded in an HTTP Response

HTTP/1.1 200 OK
Content-Type: application/soap; 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">
   <Price>34.5</Price>
  </m:GetLastTradePriceResponse>
 </env:Body>
</env:Envelope>

More examples are available in B SOAP Envelope Examples.

1.3 SOAP Terminology

1.3.1 Data Encoding Concepts

SOAP data model: A set of abstract constructs that can be used to describe common data types and link relationships in data.
SOAP data encoding: The syntactic representation of data described by the SOAP data model within one or more SOAP header blocks or SOAP body element in a SOAP message.

2 Relation to XML

All SOAP messages have an XML Information Set[10]

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 [1]SOAP Fault)

This document defines the following namespaces[7]:

The SOAP serialisation has the namespace identifier "http://www.w3.org/2001/12/soap-encoding"
The RPC result element has the namespace identifier "http://www.w3.org/2001/12/soap-rpc"

A schema document for these namespace can be found by dereferencing the relevant namespace identifier.

A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with faultcode of "Client.DTD". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives.

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.

3 The SOAP Data Model

Editorial note: JJM

20010914

Section 4 currently defines a data model in the form of a directed graph. Elements of the data model include struct, array, and id/href. In addition to the data model, section 4 includes a particular encoding of that model without clearly separating the two. The WG would like to clarify the relationship between the data model and the particular encoding by saying that the SOAP encoding is one of several potential encodings of the SOAP data model. This section is the placeholder for the description of the SOAP data model (see also section 3.5 in the XML Protocol WG Draft Requirements)

4 SOAP Encoding

Editorial note: JJM	20010920
The Working Group is aware that the following section does not use the XML Infoset terminology used elsewhere in this specification, and most notably in Part 1. The WG expects to rewrite this section using the XML Infoset terminalogy at a later date.

The SOAP encoding style is based on a simple type system that is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. A type either is a simple (scalar) type or is a compound type constructed as a composite of several parts, each with a type. This is described in more detail below.

This section defines rules for serialization of a graph of typed objects. It operates on two levels. First, given a schema in any notation consistent with the type system described, a schema for an XML grammar may be constructed. Second, given a type-system schema and a particular graph of values conforming to that schema, an XML instance may be constructed. In reverse, given an XML instance produced in accordance with these rules, and given also the original schema, a copy of the original value graph may be constructed.

The data serialized according to the rules defined in this section MAY contain references to data outside the serialization. When present, these references MUST be Uniform Resource Identifiers (see [6]).

The namespace identifier for the elements and attributes defined in this section is "http://www.w3.org/2001/12/soap-encoding". The encoding samples shown assume all namespace declarations are at a higher element level.

Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see [1]SOAP Encoding Attribute).

4.1 Rules for Encoding Types in XML

XML allows very flexible encoding of data. SOAP defines a narrower set of rules for encoding. This section defines the encoding rules at a high level, and the next section describes the encoding rules for specific types when they require more detail. The encodings described in this section can be used in conjunction with the mapping of RPC calls and responses specified in 5 Using SOAP for RPC.

To describe encoding, the following terminology is used:

A "value" is a string, the name of a measurement (number, date, enumeration, etc.) or a composite of several such primitive values. All values are of specific types.
A "simple value" is one without named parts. Examples of simple values are particular strings, integers, enumerated values etc.
A "compound value" is an aggregate of relations to other values. Examples of Compound Values are particular purchase orders, stock reports, street addresses, etc.
Within a compound value, each related value is potentially distinguished by a role name, ordinal or both. This is called its "accessor." Examples of compound values include particular Purchase Orders, Stock Reports etc. Arrays are also compound values. It is possible to have compound values with several accessors each named the same, as for example, RDF does.
An "array" is a compound value in which ordinal position serves as the only distinction among member values.
A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
A "simple type" is a class of simple values. Examples of simple types are the classes called "string," "integer," enumeration classes, etc.
A "compound type" is a class of compound values. An example of a compound type is the class of purchase order values sharing the same accessors (shipTo, totalCost, etc.) though with potentially different values (and perhaps further constrained by limits on certain values).
Within a compound type, if an accessor has a name that is distinct within that type but is not distinct with respect to other types, that is, the name plus the type together are needed to make a unique identification, the name is called "locally scoped." If however the name is based in part on a Uniform Resource Identifier, directly or indirectly, such that the name alone is sufficient to uniquely identify the accessor irrespective of the type within which it appears, the name is called "universally scoped."
Given the information in the schema relative to which a graph of values is serialized, it is possible to determine that some values can only be related by a single instance of an accessor. For others, it is not possible to make this determination. If only one accessor can reference it, a value is considered "single-reference". If referenced by more than one, actually or potentially, it is "multi-reference." Note that it is possible for a certain value to be considered "single-reference" relative to one schema and "multi-reference" relative to another.

SOAP Encoding 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 Encoding 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 possibly to elements specified by an ID per above, possibly to other (even external) resources, in a manner conforming to the XML Specification[8], XML Schema Specification[4],[5], and XML Linking Language Specification[9].

Although it is possible to use the xsi:type attribute such that a graph of values is self-describing both in its structure and the types of its values, the serialization rules permit that the types of values MAY be determinate only by reference to a schema. Such schemas MAY be in the notation described by "XML Schema Part 1: Structures" [4] and "XML Schema Part 2: Datatypes" [5] or MAY be in any other notation. Note also that, while the serialization rules apply to compound types other than arrays and structs, many schemas will contain only struct and array types.

The rules for serialization are as follows:

All values are represented as element content.
For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an xsi:type attribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted) enc:arrayType attribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.
A simple value is represented as character data, that is, without any subelements. Every simple value must have a type that is either listed in the XML Schemas Specification, part 2[5] or whose source type is listed therein (see also 4.2 Simple Types).
A Compound Value is encoded as a sequence of elements, each accessor represented by an embedded element whose name corresponds to the name of the accessor (see A Mapping Application Defined Name to XML Name). Accessors whose names are local to their containing types have unqualified element names; all others have qualified names (see also 4.4 Compound Types).
A multi-reference simple or compound value is encoded as an element containing a local, unqualified attribute named id and of type "ID" per the XML Specification [8]. A referencing accessor to this value is an empty element having a local, unqualified attribute named href and of type "uri-reference" per the XML Schema Specification[5], with a href attribute value of a URI fragment identifier referencing the corresponding id.
Strings and byte arrays are represented as multi-reference simple types, but special rules allow them to be represented efficiently for common cases (see also 4.2.1 Strings and 4.2.3 Array of Bytes ). An accessor to a string or byte-array value MAY have an attribute named id and of type "ID" per the XML Specification[8]. If so, all other accessors to the same value are encoded as empty elements having a local, unqualified attribute named href and of type "uri-reference" per the XML Schema Specification[5], with a href attribute value of a URI fragment identifier referencing the single element containing the value.
It is permissible to encode several references to a value as though these were references to several distinct values, but only when from context it is known that the meaning of the XML instance is unaltered.

Arrays are compound values (see also 4.4.2 Arrays). SOAP arrays are defined as having a type of "enc:Array" or a type derived there from.

SOAP arrays have one or more dimensions (rank) whose members are distinguished by ordinal position. An array value is represented as a series of elements reflecting the array, with members appearing in ascending ordinal sequence. For multi-dimensional arrays the dimension on the right side varies most rapidly. Member elements may be named to reflect their type (see rule 2/>).

SOAP arrays MUST contain a enc:arrayType attribute whose value specifies the type of the contained elements as well as the dimension(s) of the array. The value of the enc:arrayType attribute is defined as follows:

Value of `enc:arrayType`

[1]	`arrayTypeValue`	::=	`atype asize`
[2]	`atype`	::=	`QName rank*`
[3]	`rank`	::=	`'[' (',')* ']'`
[4]	`asize`	::=	`'[' length~ ']'`
[5]	`length`	::=	`nextDimension* Digit+`
[6]	`nextDimension`	::=	`Digit+ ','`

QName (see XML Namespaces 1.0) [7]

Digit (see XML 1.0) [8]

The "atype" construct is the type name of the contained elements expressed as a QName as would appear in the type attribute of an XML Schema element declaration and acts as a type constraint (meaning that all values of contained elements are asserted to conform to the indicated type; that is, the type cited in enc:arrayType must be the type or a supertype of every array member). In the case of arrays of arrays or "jagged arrays", the type component is encoded as the "innermost" type name followed by a rank construct for each level of nested arrays starting from 1. Multi-dimensional arrays are encoded using a comma for each dimension starting from 1.

The "asize" construct contains a comma separated list of zero, one, or more integers indicating the lengths of each dimension of the array. A value of zero integers indicates that no particular quantity is asserted but that the size may be determined by inspection of the actual members.

For example, an array with 5 members of type array of integers would have an arrayTypeValue value of "int[][5]" of which the atype value is "int[]" and the asize value is "[5]". Likewise, an array with 3 members of type two-dimensional arrays of integers would have an arrayTypeValue value of "int[,][3]" of which the atype value is "int[,]" and the asize value is "[3]".

A SOAP array member MAY contain a enc:offset attribute indicating the offset position of that item in the enclosing array. This can be used to indicate the offset position of a partially represented array (see 4.4.2.1 PartiallyTransmitted Arrays). Likewise, an array member MAY contain a enc:position attribute indicating the position of that item in the enclosing array. This can be used to describe members of sparse arrays (see 4.4.2.2 SparseArrays). The value of the enc:offset and the enc:position attribute is defined as follows:

Value of `enc:offset` and `enc:position`

[7] arrayPoint ::= "[" #length "]"

with offsets and positions based at 0.

A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:nil with value "1 or true" or possibly other application-dependent attributes and values.

Note that rule 2 allows elements to have names which are not identical to the type of the contained value.

4.2 Simple Types

For simple types, SOAP adopts all the types found in the section "Built-in datatypes" of the "XML Schema Part 2: Datatypes" Specification[5], both the value and lexical spaces. Examples include:

Type	Example
int	58502
float	314159265358979E+1
negativeInteger	-32768
string	Louis "Satchmo" Armstrong

The datatypes declared in the XML Schema specification may be used directly in element schemas. Types derived from these may also be used. For example, for the following schema:

Example: Schema with simple types

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >

  <xs:element name="age" type="xs:int" />
  <xs:element name="height" type="xs:float" />
  <xs:element name="displacement" type="xs:negativeInteger" />
  <xs:element name="color" >
    <xs:simpleType base="xsd:string">
      <xs:restriction base="xs:string">
        <xs:enumeration value="Green"/>
        <xs:enumeration value="Blue"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

</xs:schema>

the following elements would be valid instances:

Example: Message fragment corresponding to the preceding schema

<age>45</age>
<height>5.9</height>
<displacement>-450</displacement>
<color>Blue</color>

All simple values MUST be encoded as the content of elements whose type is either defined in "XML Schema Part 2: Datatypes" Specification[5], or is based on a type found there by using the mechanisms provided in the XML Schema specification.

If a simple value is encoded as an element whose name does not matter (such as a member of a heterogenous array) it is convenient to have an element declaration corresponding to the datatype. Because the "XML Schema Part 2: Datatypes" Specification[5] includes type definitions but does not include corresponding element declarations, the enc schema and namespace declares an element for every simple datatype. These MAY be used.

Example: Using elements declared in SOAP encoding schema

<enc:int xmlns:enc="http://www.w3.org/2001/12/soap-encoding" id="int1">45</enc:int>

4.2.1 Strings

The datatype "string" is defined in "XML Schema Part 2: Datatypes" Specification[5]. Note that this is not identical to the type called "string" in many database or programming languages, and in particular may forbid some characters those languages would permit. (Those values must be represented by using some datatype other than xsd:string.)

A string MAY be encoded as a single-reference or a multi-reference value.

The containing element of the string value MAY have an id attribute. Additional accessor elements MAY then have matching href attributes.

For example, two accessors to the same string could appear, as follows:

Example: Two accessors for the same string

<greeting id="String-0">Hello</greeting>
<salutation href="#String-0"/>

However, if the fact that both accessors reference the same instance of the string (or subtype of string) is immaterial, they may be encoded as two single-reference values as follows:

Example: Two accessors for the same string

<greeting>Hello</greeting>
<salutation>Hello</salutation>

Schema fragments for these examples could appear similar to the following:

Example: Schema for preceding example

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding" >

  <xs:import namespace="http://www.w3.org/2001/12/soap-encoding" />

  <xs:element name="greeting" type="enc:string" />
  <xs:element name="salutation" type="enc:string" />

</xs:schema>

(In this example, the type enc:string is used as the element's type as a convenient way to declare an element whose datatype is "xsd:string" and which also allows id and href attributes. See the SOAP Encoding schema for the exact definition. Schemas MAY use these declarations from the SOAP Encoding schema but are not required to.)

4.2.2 Enumerations

The "XML Schema Part 2: Datatypes" Specification[5] defines a mechanism called "enumeration." The SOAP data model adopts this mechanism directly. However, because programming and other languages often define enumeration somewhat differently, the specification further describes how a value that is a member of an enumerated list of possible values is to be encoded. Specifically, it is encoded as the name of the value.

"Enumeration" as a concept indicates a set of distinct names. A specific enumeration is a specific list of distinct values appropriate to the base type. For example the set of color names ("Green", "Blue", "Brown") could be defined as an enumeration based on the string built-in type. The values ("1", "3", "5") are a possible enumeration based on integer, and so on. "XML Schema Part 2: Datatypes"[5] supports enumerations for all of the simple types except for boolean. The language of "XML Schema Part 1: Structures" Specification[4] can be used to define enumeration types. If a schema is generated from another notation in which no specific base type is applicable, use "string". In the following schema example "EyeColor" is defined as a string with the possible values of "Green", "Blue", or "Brown" enumerated, and instance data is shown accordingly.

Example: Schema with enumeration

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/2001/06/samples"
                   targetNamespace="http://example.org/2001/06/samples" >

  <xs:element name="EyeColor" type="tns:EyeColor" />
  <xs:simpleType name="EyeColor" >
    <xs:restriction base="xs:string" >
      <xs:enumeration value="Green" />
      <xs:enumeration value="Blue" />
      <xs:enumeration value="Brown" />
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Example: Message fragment corresponding to the preceding schema

<p:EyeColor xmlns:p="http://example.org/2001/06/samples" >Brown</p:EyeColor>

4.2.3 Array of Bytes

An array of bytes MAY be encoded as a single-reference or a multi-reference value. The rules for an array of bytes are similar to those for a string.

In particular, the containing element of the array of bytes value MAY have an id attribute. Additional accessor elements MAY then have matching href attributes.

The recommended representation of an opaque array of bytes is the 'base64' encoding defined in XML Schemas[4][5], which uses the base64 encoding algorithm defined in MIME[15]. However, the line length restrictions that normally apply to base64 data in MIME do not apply in SOAP. A "enc:base64" subtype is supplied for use with SOAP.

Example: Image with base64 encoding

<picture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
         xsi:type="enc:base64" >
   aG93IG5vDyBicm73biBjb3cNCg==
</picture>

4.3 Polymorphic Accessor

Many languages allow accessors that can polymorphically access values of several types, each type being available at run time. A polymorphic accessor instance MUST contain an xsi:type attribute that describes the type of the actual value.

For example, a polymorphic accessor named "cost" with a value of type "xsd:float" would be encoded as follows:

Example: Polymorphic accessor

<cost xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xsi:type="xs:float">29.95</cost>

as contrasted with a cost accessor whose value's type is invariant, as follows:

Example: Accessor whose value type is invariant

<cost>29.95</cost>

4.4 Compound Types

SOAP defines types corresponding to the following structural patterns often found in programming languages:

Struct: A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
Array: An "array" is a compound value in which ordinal position serves as the only distinction among member values.

SOAP also permits serialization of data that is neither a Struct nor an Array, for example data such as is found in a Directed-Labeled-Graph Data Model in which a single node has many distinct accessors, some of which occur more than once. SOAP serialization does not require that the underlying data model make an ordering distinction among accessors, but if such an order exists, the accessors MUST be encoded in that sequence.

4.4.1 Compound Values and References to Values

The members of a Compound Value are encoded as accessor elements. When accessors are distinguished by their name (as for example in a struct), the accessor name is used as the element name. Accessors whose names are local to their containing types have unqualified element names; all others have qualified names.

The following is an example of a struct of type "Book":

Example: Book structure

<e:Book xmlns:e="http://example.org/2001/06/books" >
   <author>Henry Ford</author>
   <preface>Prefactory text</preface>
   <intro>This is a book.</intro>
</e:Book>

And this is a schema fragment describing the above structure:

Example: Schema for Book structure

<xs:element name="Book"
            xmlns:xs='http://www.w3.org/2001/XMLSchema' >
  <xs:complexType>
    <xs:sequence>
      <xs:element name="author" type="xs:string" />
      <xs:element name="preface" type="xs:string" />
      <xs:element name="intro" type="xs:string" />
    </xs:sequence>
  </xs:complexType>
</xs:element>

Below is an example of a type with both simple and complex members. It shows two levels of referencing. Note that the href attribute of the Author accessor element is a reference to the value whose id attribute matches. A similar construction appears for the Address accessor element.

Example: Book with muli-reference addresses

<e:Book xmlns:e="http://example.org/2001/06/books" >
  <title>My Life and Work</title>
  <author href="#Person-1"/>
</e:Book>
<e:Person xmlns:e="http://example.org/2001/06/books"
          id="Person-1" >
  <name>Henry Ford</name>
  <address href="#Address-2"/>
</e:Person>
<e:Address xmlns:e="http://example.org/2001/06/books"
           id="Address-2" >
  <email>mailto:henryford@hotmail.com</email>
  <web>http://www.henryford.com</web>
</e:Address>

The form above is appropriate when the "Person" value and the "Address" value are multi-reference. If these were instead both single-reference, they SHOULD be embedded, as follows:

Example: Book with single-reference addresses

<e:Book xmlns:e="http://example.org/2001/06/books" >
   <title>My Life and Work</title>
   <author>
       <name>Henry Ford</name>
       <address>
          <email>mailto:henryford@hotmail.com</email>
          <web>http://www.henryford.com</web>
       </address>
   </author>
</e:Book>

If instead there existed a restriction that no two persons can have the same address in a given instance and that an address can be either a Street-address or an Electronic-address, a Book with two authors would be encoded as follows:

Example: Book with two authors having different addresses

<e:Book xmlns:e="http://example.org/2001/06/books" >
   <title>My Life and Work</title>
   <firstauthor href="#Person-1"/>
   <secondauthor href="#Person-2"/>
</e:Book>
<e:Person xmlns:e="http://example.org/2001/06/books"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          id="Person-1" >
   <name>Henry Ford</name>
   <address xsi:type="e:ElectronicAddressType">
       <email>mailto:henryford@hotmail.com</email>
       <web>http://www.henryford.com</web>
   </address>
</e:Person>
<e:Person xmlns:e="http://example.org/2001/06/books"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          id="Person-2">
   <name>Samuel Crowther</name>
   <address xsi:type="e:StreetAddressType">
       <street>Martin Luther King Rd</street>
       <city>Raleigh</city>
       <state>North Carolina</state>
   </address>
</e:Person>

Serializations can contain references to values not in the same resource:

Example: Book with external references

<e:Book xmlns:e="http://example.org/2001/06/books" >
   <title>Paradise Lost</title>
   <firstAuthor href="http://www.dartmouth.edu/~milton/" />
</e:Book>

And this is a schema fragment describing the above structures:

Example: Schema for preceding example

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:tns="http://example.org/2001/06/books"
                   targetNamespace="http://example.org/2001/06/books" >

  <xs:element name="Book" type="tns:BookType" />
  <xs:complexType name="BookType" >
    <xs:annotation>
          <xs:documentation>
            <info>
        Either the following group must occur or else the
        href attribute must appear, but not both.
                </info>
          </xs:documentation>
    </xs:annotation>
    <xs:sequence minOccurs="0" maxOccurs="1" >
      <xs:element name="title" type="xs:string" />
      <xs:element name="firstAuthor" type="tns:PersonType" />
      <xs:element name="secondAuthor" type="tns:PersonType" />
    </xs:sequence>
    <xs:attribute name="href" type="xs:anyURI" />
    <xs:attribute name="id" type="xs:ID" />
    <xs:anyAttribute namespace="##other" />
  </xs:complexType>

  <xs:element name="Person" type="tns:PersonType" />
  <xs:complexType name="PersonType" >
    <xs:annotation>
          <xs:documentation>
            <info>
        Either the following group must occur or else the
        href attribute must appear, but not both.
                </info>
          </xs:documentation>
        </xs:annotation>
    <xs:sequence minOccurs="0" maxOccurs="1" >
      <xs:element name="name" type="xs:string" />
      <xs:element name="address" type="tns:AddressType" />
    </xs:sequence>
    <xs:attribute name="href" type="xs:anyURI" />
    <xs:attribute name="id" type="xs:ID" />
    <xs:anyAttribute namespace="##other" />
  </xs:complexType>

  <xs:element name="Address" base="tns:AddressType" />
  <xs:complexType name="AddressType" abstract="true" >
    <xs:annotation>
          <xs:documentation>
            <info>
        Either one of the following sequences must occur or
                else the href attribute must appear, but not both.
                </info>
          </xs:documentation>
        </xs:annotation>
    <xs:choice>
          <xs:sequence minOccurs="0" maxOccurs="1" >
            <xs:element name="email" type="xs:string" />
                <xs:element name="web" type="xs:anyURI" />
          </xs:sequence>
          <xs:sequence minOccurs='0' maxOccurs='1' >
        <xs:element name="street" type="xs:string" />
        <xs:element name="city" type="xs:string" />
        <xs:element name="state" type="xs:string"/>
          </xs:sequence>
        </xs:choice>
    <xs:attribute name="href" type="xs:anyURI"/>
    <xs:attribute name="id" type="xs:ID"/>
    <xs:anyAttribute namespace="##other"/>
  </xs:complexType>

  <xs:complexType name="StreetAddressType">
    <xs:annotation>
          <xs:documentation>
            <info>
        Either the second sequence in the following group
                must occur or else the href attribute must appear,
                but not both.
                </info>
          </xs:documentation>
        </xs:annotation>
        <xs:complexContent>
          <xs:restriction base="tns:AddressType" >
            <xs:sequence>
              <xs:sequence minOccurs="0" maxOccurs="0" >
                <xs:element name="email" type="xs:string" />
                    <xs:element name="web" type="xs:anyURI" />
              </xs:sequence>
          <xs:sequence minOccurs="0" maxOccurs="1">
            <xs:element name="street" type="xs:string" />
            <xs:element name="city" type="xs:string" />
            <xs:element name="state" type="xs:string"/>
          </xs:sequence>
                </xs:sequence>
        <xs:attribute name="href" type="xs:anyURI"/>
        <xs:attribute name="id" type="xs:ID"/>
        <xs:anyAttribute namespace="##other"/>
          </xs:restriction>
        </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="ElectronicAddressType">
    <xs:annotation>
          <xs:documentation>
            <info>
        Either the first sequence in the following group
                must occur or else the href attribute must appear,
                but not both.
                </info>
          </xs:documentation>
        </xs:annotation>
        <xs:complexContent>
          <xs:restriction base="tns:AddressType" >
            <xs:sequence>
          <xs:sequence minOccurs="0" maxOccurs="1">
            <xs:element name="email" type="xs:string" />
            <xs:element name="web" type="xs:anyURI" />
          </xs:sequence>
                  <xs:sequence minOccurs="0" maxOccurs="0">
            <xs:element name="street" type="xs:string" />
            <xs:element name="city" type="xs:string" />
            <xs:element name="state" type="xs:string"/>
          </xs:sequence>
                </xs:sequence>
            <xs:attribute name="href" type="xs:anyURI"/>
        <xs:attribute name="id" type="xs:ID"/>
        <xs:anyAttribute namespace="##other"/>
          </xs:restriction>
        </xs:complexContent>
  </xs:complexType>

</xs:schema>

4.4.2 Arrays

SOAP arrays are defined as having a type of enc:Array or a derived type having that type in its derivation hierarchy (see also rule 8 in 4.1 Rules for Encoding Types in XML). Such derived types would be restrictions of the enc:Array type and could be used to represent, for example, arrays limited to integers or arrays of some user-defined enumeration. Arrays are represented as element values, with no specific constraint on the name of the containing element (just as values generally do not constrain the name of their containing element). The elements which make up the array can themselves can be of any type, including nested arrays.

The representation of the value of an array is an ordered sequence of elements constituting the items of the array. Within an array value, element names are not significant for distinguishing accessors. Elements may have any name. In practice, elements will frequently be named so that their declaration in a schema suggests or determines their type. As with compound types generally, if the value of an item in the array is a single-reference value, the item contains its value. Otherwise, the item references its value via an href attribute.

The following example is a schema fragment and an array containing integer array members:

Example: Schema declaring an array of integers

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding" >
  <xs:import namespace="http://www.w3.org/2001/12/soap-encoding" />
  <xs:element name="myFavoriteNumbers" type="enc:Array" />
</xs:schema>

Example: Array conforming to the preceding schema

<myFavoriteNumbers xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
                   enc:arrayType="xs:int[2]" >
  <number>3</number>
  <number>4</number>
</myFavoriteNumbers>

In the preceding example, the array myFavoriteNumbers contains several members each of which is a value of type xs:int. This can be determined by inspection of the enc:arrayType attribute. Note that the enc:Array type allows both unqualified element names and qualified element names from any namespace. These convey no type information, so when used they must either have an xsi:type attribute or the containing element must have a enc:arrayType attribute. Naturally, types derived from enc:Array may declare local elements, with type information.

As previously noted, the enc schema contains declarations of elements with names corresponding to each simple type in the "XML Schema Part 2: Datatypes" Specification[5]. It also contains a declaration for Array . They are used in the following example:

Example: Using the enc:Array element

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           enc:ArrayType="xs:int[2]" >
  <enc:int>3</enc:int>
  <enc:int>4</enc:int>
</enc:Array>

Arrays can contain instances of any subtype of the specified arrayType. That is, the members may be of any type that is substitutable for the type specified in the arrayType attribute, according to whatever substitutability rules are expressed in the schema. So, for example, an array of integers can contain any type derived from integer (for example "int" or any user-defined derivation of integer). Similarly, an array of "address" might contain a restricted or extended type such as "internationalAddress". Because the supplied enc:Array type admits members of any type, arbitrary mixtures of types can be contained unless specifically limited by use of the arrayType attribute.

Types of member elements can be specified using the xsi:type attribute in the instance, or by declarations in the schema of the member elements, as the following two arrays demonstrate respectively:

Example: Array with elements of varying types

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           enc:arrayType="xs:anyType[4]">
   <thing xsi:type="xs:int">12345</thing>
   <thing xsi:type="xs:decimal">6.789</thing>
   <thing xsi:type="xs:string">
      Of Mans First Disobedience, and the Fruit
      Of that Forbidden Tree, whose mortal tast
      Brought Death into the World, and all our woe,
   </thing>
   <thing xsi:type="xs:anyURI">
      http://www.dartmouth.edu/~milton/reading_room/
   </thing>
</enc:Array>

Example: Array with elements of varying types

<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           enc:arrayType="xs:anyType[4]" >
   <enc:int>12345</enc:int>
   <enc:decimal>6.789</enc:decimal>
   <enc:string>
      Of Mans First Disobedience, and the Fruit
      Of that Forbidden Tree, whose mortal tast
      Brought Death into the World, and all our woe,
   </enc:string>
   <enc:anyURI>
      http://www.dartmouth.edu/~milton/reading_room/
   </enc:anyURI >
</enc:Array>

Array values may be structs or other compound values. For example an array of "xyz:Order" structs :

Example: Arrays containing structs and other compound values

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xyz="http://example.org/2001/06/Orders"
           enc:arrayType="xyz:Order[2]">
   <Order>
       <Product>Apple</Product>
       <Price>1.56</Price>
   </Order>
   <Order>
       <Product>Peach</Product>
       <Price>1.48</Price>
   </Order>
</enc:Array>

Arrays may have other arrays as member values. The following is an example of an array of two arrays, each of which is an array of strings.

Example: Array containing other arrays

<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           enc:arrayType="xs:string[][2]" >
   <item href="#array-1"/>
   <item href="#array-2"/>
</enc:Array>
<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           id="array-1"
           enc:arrayType="xs:string[3]">
   <item>r1c1</item>
   <item>r1c2</item>
   <item>r1c3</item>
</enc:Array>
<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           id="array-2"
           enc:arrayType="xs:string[2]">
   <item>r2c1</item>
   <item>r2c2</item>
</enc:Array>

The element containing an array value does not need to be named "enc:Array". It may have any name, provided that the type of the element is either enc:Array or is derived from enc:Array by restriction. For example, the following is a fragment of a schema and a conforming instance array:

Example: Schema for an array

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:tns="http://example.org/2001/06/numbers"
           targetNamespace="http://example.org/2001/06/numbers" >

  <xs:simpleType name="phoneNumberType" >
    <xs:restriction base="xs:string" />
  </xs:simpleType>

  <xs:element name="ArrayOfPhoneNumbers" type="tns:ArrayOfPhoneNumbersType" />

  <xs:complexType name="ArrayOfPhoneNumbersType" >
    <xs:complexContent>
      <xs:restriction base="enc:Array" >
            <xs:sequence>
          <xs:element name="phoneNumber" type="tns:phoneNumberType" maxOccurs="unbounded" />
            </xs:sequence>
        <xs:attributeGroup ref="enc:arrayAttributes" />
        <xs:attributeGroup ref="enc:commonAttributes" />
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

Example: Array conforming to the preceding schema

<abc:ArrayOfPhoneNumbers xmlns:abc="http://example.org/2001/06/numbers"
                         xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
                         enc:arrayType="abc:phoneNumberType[2]" >
   <phoneNumber>206-555-1212</phoneNumber>
   <phoneNumber>1-888-123-4567</phoneNumber>
</abc:ArrayOfPhoneNumbers>

Arrays may be multi-dimensional. In this case, more than one size will appear within the asize part of the arrayType attribute:

Example: Multi-dimensonal array

<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           enc:arrayType="xs:string[2,3]" >
   <item>r1c1</item>
   <item>r1c2</item>
   <item>r1c3</item>
   <item>r2c1</item>
   <item>r2c2</item>
   <item>r2c3</item>
</enc:Array>

While the examples above have shown arrays encoded by reference, array values SHOULD appear embedded.

The following is an example of a schema fragment and an array of phone numbers embedded in a struct of type "Person" and accessed through the accessor "phoneNumbers":

Example: Schema fragment for array of phone numbers embedded in a struct

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:tns="http://example.org/2001/06/numbers"
                   targetNamespace="http://example.org/2001/06/numbers" >

  <xs:import namespace="http://www.w3.org/2001/12/soap-encoding" />

  <xs:simpleType name="phoneNumberType" >
    <xs:restriction base="xs:string" />
  </xs:simpleType>


  <xs:element name="ArrayOfPhoneNumbers" type="tns:ArrayOfPhoneNumbersType" />

  <xs:complexType name="ArrayOfPhoneNumbersType" >
    <xs:complexContent>
      <xs:restriction base="enc:Array" >
            <xs:sequence>
          <xs:element name="phoneNumber" type="tns:phoneNumberType" maxOccurs="unbounded" />
            </xs:sequence>
        <xs:attributeGroup ref="enc:arrayAttributes" />
        <xs:attributeGroup ref="enc:commonAttributes" />
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="Person">
    <xs:complexType>
          <xs:sequence>
        <xs:element name="name" type="xs:string" />
        <xs:element name="phoneNumbers" type="tns:ArrayOfPhoneNumbersType" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

Example: Array of phone numbers embedded in a struct conforming to the preceding schema

<def:Person xmlns:def="http://example.org/2001/06/numbers"
            xmlns:enc="http://www.w3.org/2001/12/soap-encoding" >
   <name>John Hancock</name>
   <phoneNumbers enc:arrayType="def:phoneNumber[2]">
       <phoneNumber>206-555-1212</phoneNumber>
       <phoneNumber>1-888-123-4567</phoneNumber>
   </phoneNumbers>
</def:Person>

Here is another example of a single-reference array value encoded as an embedded element whose containing element name is the accessor name:

Example: Single-reference array encoded as en embedded element

<xyz:PurchaseOrder xmlns:xyz="http://example.org/2001/06/Orders" >
   <CustomerName>Henry Ford</CustomerName>
   <ShipTo>
       <Street>5th Ave</Street>
       <City>New York</City>
       <State>NY</State>
       <Zip>10010</Zip>
   </ShipTo>
   <PurchaseLineItems xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
                      enc:arrayType="xyz:Order[2]">
       <Order>
           <Product>Apple</Product>
           <Price>1.56</Price>
       </Order>
       <Order>
           <Product>Peach</Product>
           <Price>1.48</Price>
       </Order>
   </PurchaseLineItems>
</xyz:PurchaseOrder>

4.4.2.1 PartiallyTransmitted Arrays

SOAP provides support for partially transmitted arrays, known as "varying" arrays in some contexts[5]. A partially transmitted array indicates in an enc:offset attribute the zero-origin offset of the first element transmitted. If omitted, the offset is taken as zero.

The following is an example of an array of size five that transmits only the third and fourth element counting from zero:

Example: Array of size five that transmits only the third and fourth element

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           enc:arrayType="xs:string[6]"
           enc:offset="[3]" >
  <item>The fourth element</item>
  <item>The fifth element</item>
</enc:Array>

4.4.2.2 SparseArrays

SOAP provides support for sparse arrays. Each element representing a member value contains a enc:position attribute that indicates its position within the array. The following is an example of a sparse array of two-dimensional arrays of strings. The size is 4 but only position 2 is used:

Example: Sparse array

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           enc:arrayType="xs:string[,][4]" >
   <enc:Array href="#array-1" enc:position="[2]" />
</enc:Array>
<enc:Array id="array-1"
           enc:arrayType="xs:string[10,10]" >
   <item enc:position="[2,2]">Third row, third col</item>
   <item enc:position="[7,2]">Eighth row, third col</item>
</enc:Array>

If the only reference to "array-1" occurs in the enclosing array, this example could also have been encoded as follows:

Example: Alternative serialisation

<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           enc:arrayType="xs:string[,][4]" >
  <enc:Array enc:position="[2]" enc:arrayType="xs:string[10,10]" >    <item enc:position="[2,2]">Third row, third col</item>
    <item enc:position="[7,2]">Eighth row, third col</item>
  </enc:Array>
</enc:Array>

4.4.3 Generic Compound Types

The encoding rules just cited are not limited to those cases where the accessor names are known in advance. If accessor names are known only by inspection of the immediate values to be encoded, the same rules apply, namely that the accessor is encoded as an element whose name matches the name of the accessor, and the accessor either contains or references its value. Accessors containing values whose types cannot be determined in advance MUST always contain an appropriate xsi:type attribute giving the type of the value.

Similarly, the rules cited are sufficient to allow serialization of compound types having a mixture of accessors distinguished by name and accessors distinguished by both name and ordinal position. (That is, having some accessors repeated.) This does not require that any schema actually contain such types, but rather says that if a type-model schema does have such types, a corresponding XML syntactic schema and instance may be generated.

Example: Generic compound types

<xyz:PurchaseOrder xmlns:xyz="http://example.org/2001/06/Orders" >
  <CustomerName>Henry Ford</CustomerName>
  <ShipTo>
    <Street>5th Ave</Street>
    <City>New York</City>
    <State>NY</State>
    <Zip>10010</Zip>
  </ShipTo>
  <PurchaseLineItems>
    <Order>
      <Product>Apple</Product>
      <Price>1.56</Price>
    </Order>
    <Order>
      <Product>Peach</Product>
      <Price>1.48</Price>
    </Order>
  </PurchaseLineItems>
</xyz:PurchaseOrder>

Similarly, it is valid to serialize a compound value that structurally resembles an array but is not of type (or subtype) enc:Array. For example:

Example: Compound value

<PurchaseLineItems>
    <Order>
        <Product>Apple</Product>
        <Price>1.56</Price>
    </Order>
    <Order>
        <Product>Peach</Product>
        <Price>1.48</Price>
    </Order>
</PurchaseLineItems>

4.5 Default Values

An omitted accessor element implies either a default value or that no value is known. The specifics depend on the accessor, method, and its context. For example, an omitted accessor typically implies a Null value for polymorphic accessors (with the exact meaning of Null accessor-dependent). Likewise, an omitted Boolean accessor typically implies either a False value or that no value is known, and an omitted numeric accessor typically implies either that the value is zero or that no value is known.

4.6 SOAP root Attribute

The SOAP root attribute can be used to label serialization roots that are not true roots of an object graph so that the object graph can be deserialized. The attribute can have one of two values, either "true" or "false". True roots of an object graph have the implied attribute value of "true". Serialization roots that are not true roots can be labeled as serialization roots with an attribute value of "true". An element can explicitly be labeled as not being a serialization root with a value of "false".

The SOAP root attribute MAY appear on any subelement within the SOAP Header and SOAP Body elements. The attribute does not have a default value.

The SOAP root attribute information item is of type boolean from the namespace "http://www.w3.org/2001/XMLSchema".

5 Using SOAP for RPC

Editorial note: JJM	20010920
The Working Group is aware that the following section does not use the XML Infoset terminology used elsewhere in this specification, and most notably in Part 1. The WG expects to rewrite this section using the XML Infoset terminalogy at a later date.

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 invocations and responses.

Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in 4 SOAP Encoding, other representations are possible. The SOAP encodingStyle attribute (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.

Using SOAP for RPC is orthogonal to the SOAP protocol binding (see 8 Default HTTP 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, using SOAP for RPC is not limited to the HTTP protocol binding.

To invoke an RPC, the following information is needed:

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

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

5.1 RPC and SOAP Body

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

An RPC invocation is modeled as a struct.
The invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the procedure or method name (see A Mapping Application Defined Name to XML Name).
Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter (see A Mapping Application Defined Name to XML Name). These appear in the same order as in the procedure or method signature.
An RPC response is modeled as a struct.
The response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The return value accessor SHOULD be first, followed by the accessors for the parameters which SHOULD be in the same order as they appear in the procedure or method signature.
Each parameter accessor has a name corresponding to the name of the parameter (see A Mapping Application Defined Name to XML Name) and type corresponding to the type of the parameter. The name of the return value accessor is "result" and it is namespace-qualified with the namespace identifier "http://www.w3.org/2001/12/soap-rpc" The return value accessor MUST be present if the return value of the procedure is non-void. The return value accessor MUST NOT be present if the return value of the procedure is void.
Invocation faults are handled according to the rules in 5.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 4 SOAP Encoding, or other encodings can be specified using the encodingStyle attribute (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.

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

An example of the use of a header block is the passing of a transaction ID along with a message. Since the transaction ID is not part of the signature and is typically held in an infrastructure component rather than application code, there is no direct way to pass the necessary information with the invocation. By adding a header block with a fixed name, the transaction manager on the receiving side can extract the transaction ID and use it without affecting the coding of remote procedure calls.

5.3 RPC Faults

The RPC representation introduces additional SOAP fault codes to those described in [1]Fault Codes. The namespace identifier for these SOAP faultcode element information item 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.

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

A soap-env:Server fault SHOULD be generated when the server cannot handle the message because of some temporary condition, e.g. when it is out of memory.
A soap-env:DataEncodingUnknown fault SHOULD be generated when the arguments are encoded in a data encoding unknown to the server.
An rpc:ProcedureNotPresent fault MUST be generated when the server cannot find the procedure specified.
An rpc:BadArguments fault MUST be generated when the server cannot parse the arguments or when there is a mismatch between what the server expects and what the client has sent.
Other faults arising in an extension or from the application SHOULD be generated as described in [1](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.

6 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 Transport Binding Framework). This convention is used to describe a Single-Request-Response MEP 7.1 Single-Request-Response TMEP and an HTTP Binding 8 Default 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.

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

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

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

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

7 Transport Message Exchange Patterns

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

In general the definition of a transport message exchange pattern:

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

Transport binding specifications may declare their support for one or more named transport message exchange patterns.

Transport message exchange patterns are named by URI.

A transport message exchange has a lifecycle governed by a transport 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 Transport Message Exchange Patterns. Other properties may also be involved in the specification for particular TMEPs, but these are generally applicable to all TMEPs.

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

7.1 Single-Request-Response TMEP

Editorial note: JJM/TBTF

20011205

The use of single here is to capture the notion that this there is to be no implied timing relationship between contemporaneous exchanges conforming to this transport exchange pattern, ie. nothing can be said about the relative temporal ordering of the transmission and reception of messages arising from distinct exchanges. Might rename Independent-Request-Response. Single could be misinterpreted as just 1 response or a unicast pattern (both of which happen to be the case but are not the motivation for the prefix).

7.1.1 Message Exchange Pattern Name

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

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

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

Standard Prefix Mappings
Prefix	Namespace
transport	http://www.example.org/2001/12/soap/bindingFramework/TransportExchangeContext/
mep	http://www.example.org/2001/12/soap/transport-mep/
fail	http://www.example.org/2001/12/soap/transport-mep/FailureReasons/
single	http://www.example.org/2001/12/soap/transport-mep/single-request-response/

7.1.2 Informal Description

The single-request-response transport 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.

7.1.3 Formal Description

Editorial note: JJM/TBTF	20011205
This is intended as a logical description of the operation of this MEP. It is not intended to describe a real implementation or to imply that a real implementation should be structured.

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

Instantiation of a Message Exchange Context for a Requesting SOAP Node
Property Name URI	Value
transport:ExchangePatternName	http://www.example.org/2001/12/soap/transport-mep/single-request-response/
single:Role	RequestingSOAPNode
single:State	Requesting
transport:FailureReason	None
transport:CurrentMessage	An abstraction of the Request Message
transport: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 transport message exchange are initialised in accordance with the relevant feature specification.

Once initialised control of the transport 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 transport message exchange context.

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

Editorial note: JJM/TBTF	20011205
The initial value for single:State feels a bit awkward. generally when a Message start to be received the transport-mep in operation may not be known in which case the intial receiving state cannot be scoped by mep name or node role with respect to the exchange.

Instantiation of Message Exchange Context for an inbound Request Message
Property Name	Value
transport:ExchangePatternName	"http://www.example.org/2001/12/soap/transport-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
transport:FailureReason	None
transport:CurrentMessage	NULL
transport:ImmediateSource	An identifier (URI) that denotes the Requesting SOAP Node (if available)

Editorial note: JJM/TBTF	20011205
Incomplete tables for illustrative purposes.

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

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

7.1.4 Fault Handling

During the operation of the single-request-response transport message exchange pattern, the participating SOAP Nodes may generate SOAP Faults.

If a SOAP Fault is generated during the processing of a Request Message then relaying of that message toward ultimate Responding SOAP Node should be terminated and the generated SOAP Fault should be propagated toward the initial Requesting SOAP Node in place of the Response Message.

Editorial note: JJM/SKW	20011205
The following paragraph may be overly prescriptive, but it seems like a good starting point. Extensions like SOAP-RP and ebXML may modify Fault Handling behaviour.

If a SOAP Fault is generated during the processing of a Response Message then the generated SOAP Fault should be propagated toward the initial Requesting SOAP Node in place of the Response Message.

7.1.5 Operation Through SOAP Intermediaries (Informal)

Editorial note: JJM/GD	20011205
Do we want this section in the current WD, or should we just note that it is an issue?

The single-request-response transport message exchange pattern can be extended over multiple transport binding hops to form an extended single-request-response transport message exchange with a SOAP message path that extends through multiple SOAP intermediaries.

By default, Response Message follow the same set of hops between SOAP Nodes as the Request Message, but in reverse order. Specific SOAP extensions (eg. SOAP-RP) may modify this default behaviour.

A Request Message received by a SOAP Intermediary may be processed and forwarded toward an ultimate Responding SOAP Node. By default, a Response Message SHOULD NOT be returned toward the initial Requesting SOAP Node until a Response Message has been received (and possibly processed) at the SOAP Intermediary.

A failure by a SOAP Intermediary to forward a Request Message or to receive a Response Message MAY result in the generation of a SOAP Fault at the SOAP Intermediary.

7.1.6 Operation Through SOAP Intermediaries (Formal)

Editorial note: JJM	20011206
Placeholder; the TBTF has not produced any text for this section.

8 Default HTTP Binding

8.1 Introduction

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

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
transport	http://www.example.org/2001/12/soap/bindingFramework/TransportExchangeContext/
mep	http://www.example.org/2001/12/soap/transport-mep/
fail	http://www.example.org/2001/12/soap/transport-mep/FailureReasons/
single	http://www.example.org/2001/12/soap/transport-mep/single-request-response/

Editorial note: MJG	20011023
The media type for SOAP 1.2 has been subject to much discussion. In this draft the media type has been changed from text/xml to application/soap. The XML Protocol Working Group solicits feedback on this choice, including examples of media type choice in other tecnologies/specifications. It would be useful if such feedback gave rational for ( or against ) the choice made by this specification.

HTTP applications MUST use the media type "application/soap" according to RFC 3023[11] when including SOAP messages in HTTP exchanges.

8.2 Binding Name

The binding described here is identified with the URI:

http://www.example.org/2001/12/soap/bindings/defaultHTTP/

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

8.3 Supported Transport Message Exchange Patterns

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

http://www.example.org/2001/12/soap/transport-mep/single-request-response/ (see 7.1 Single-Request-Response TMEP)

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.

8.4 Message Exchange Operation

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

8.4.1 Single Request-Response Exchanges

The "http://www.example.org/2001/12/soap/transport-mep/single-request-response/" transport message pattern is described in 7.1 Single-Request-Response TMEP.

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 7.1 Single-Request-Response TMEP), and are of type single:StateType (an enumeration over xsd:string).

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

8.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 7.1 Single-Request-Response TMEP.

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.

Editorial note: JJM/SKW	20011205
Preconditions for entering this first state should be part of the single request response mep description.

8.4.1.1.1 Requesting State

Requesting State
Statename	Requesting
Preconditons	See 7.1 Single-Request-Response TMEP
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
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 `transport:ImmediateDestination` property of the transport message exchange context.
Content-Type header	"application/soap" (see 8 Default HTTP Binding
Additional Headers	Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange eg. `SOAPAction` (see 8.5.1 SOAP Action).
HTTP entity body	XML 1.0 serialisation of the SOAP message XML Infoset carried in the transport:CurrentMessage property of the transport message exchange context.

Editorial note: JJM/SKW	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.

8.4.1.1.2 Waiting State

Waiting State
Statename	Waiting
Preconditons	None
Description	Wait for HTTP Response
Actions on Leaving State	Instantiate or replace the property `transport: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	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	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 transport message exchange is regarded as having completed successfully.		Success
		Instantiated or replaced Property QName	Property Value
		transport:CurrentMessage	Replace contents with a value that represents and empty SOAP Envelope.
		transport: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 transport: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 transport message exchange is regarded has having completed unsuccessfully.		Fail
		Instantiated or replaced Property QName	Property Value
		`transport:FailureReason`	`fail:BadRequest`
401	Unauthorized	Indicates that the HTTP Request requires authorization. If available this engages the Simple Authentication feature specified in 8.5.2 Simple Authentication Feature		Requesting
		Instantiated or replaced Property QName	Property Value
		`transport:FailureReason`	`fail:AuthenticationFailure`
		If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the transport message exchange is regarded as having completed unsuccessfully.		Fail
		Instantiated or replaced Property QName	Property Value
		`transport: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 transport message exchange is regarded has having completed unsuccessfully.		Fail
		Instantiated or replaced Property QName	Property Value
		`transport: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 transport message exchange is regarded has having completed unsuccessfully.		Fail
		Instantiated or replaced Property QName	Property Value
		`transport: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 transport message exchange is regarded has having completed unsuccessfully. In requesting SOAP nodes that support the OPTIONAL SOAPAction feature, the behaviour described in 8.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
		transport:FaultHint	true

8.4.1.1.3 Receiving State

Receiving State
Statename	Receiving
Preconditons
Description	Receive HTTP response entity body, which is assumed to be a SOAP envelope serialized according the XML 1.0 + Namespaces spec.
Actions on Leaving State	On transitions to Success, instantiate or replace the property transport: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, eg malformed XML, invalid SOAP Envelope	Fail	`fail:BadResponseMessage`

8.4.1.1.4 Success and Fail

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

8.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 7.1 Single-Request-Response TMEP.

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 transport message exchange context into existence for the inbound message instantiates it in a generic receiving state..

8.4.1.2.1 Receiving

Receiving State
Statename	Receiving
Preconditons	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 transport:ImmediateSender with a URI value that denotes the sender of the HTTP request (if known) Instantiate or replace the property transport: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 (eg SOAPAction) are processed in accordance with the relevant feature specification. This change of state represents a transfer of control of the inbound transport 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 transport 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

Editorial note: JJM/SKW	20011205
This is intended to be aligned with Chris Ferris proposal on Issue #12. There is a long and interesting thread that may influence how this is presented.

8.4.1.2.2 Processing

Processing State
Statename	Processing
Preconditons
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 transport:CurrentMessage with a Response Message. The Response Message may contain a SOAP Fault.
	Underlying Connection Failure	Fail	`fail:TransmissionFailure`

8.4.1.2.3 Responding

Responding State
Statename	Responding
Preconditons	transport:CurrentMessage contains a value that represents the Response Message (which may contain a 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 transport: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" according to RFC 3023[11]
Additional Headers	Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange eg. SOAPAction (see 8.5.1 SOAP Action).
HTTP entity body	XML 1.0 serialisation of the SOAP message XML Infoset carried in the transport:CurrentMessage property of the transport message exchange context.

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:Client	??
env:Server	??
env:rpc	??
Other Faults	??

8.4.1.2.4 Success and Fail

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

8.4.1.3 Operation Through SOAP Intermediaries

Editorial note: JJM/TBTF	20011205
I (currently) think that operation of a given MEP through an intermediary is something that needs to be part of the MEP description, rather than part of a binding description.

8.5 Features Expressed External to the Message Envelope

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

http://www.example.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.

8.5.1 SOAP Action

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

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

In the text to follow, the prefix "action" is mapped to the URI "http://www.example.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 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 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 transport 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 transport 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 transport 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 transport 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

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

Required SOAP Action HTTP Header

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

8.5.2 Simple Authentication Feature

Editorial note: JJM	20011206
Placeholder section. The "Simple Authentication" feature is referenced in section 8.4.1, table "HTTP status code dependent transitions upon reception of an HTTP status line and response headers", but is not actually defined anywhere.

8.6 SOAP HTTP Examples

Example: SOAP HTTP Request Using POST

POST /StockQuote HTTP/1.1
Content-Type: application/soap; 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 HTTP Response to preceding request

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

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

9 References

9.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, 2 10 2001 (See http://www.w3.org/TR/2001/WD-soap12-part1-20011217/.)
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.)

9.2 Informative References

12: XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)
13: XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)
14: XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)
15: 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.)
16: 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

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

Rules for mapping application defined name to XML Name

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

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

B SOAP Envelope Examples (Non-Normative)

B.1 Sample Encoding of Call Requests

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; 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="1" >
               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; 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>

B.2 Sample Encoding of Response

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

HTTP/1.1 200 OK
Content-Type: application/soap; 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="1" >
           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; 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; 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>env:MustUnderstand</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; 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>env:Server</faultcode>
      <faultstring>Server Error</faultstring>
      <detail>
        <e:myfaultdetails xmlns:e="http://example.org/2001/06/faults" >
          <message>My application didn't work</message>
          <errorcode>1001</errorcode>
        </e:myfaultdetails>
      </detail>
    </env:Fault>
 </env:Body>
</env:Envelope>

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

D Part 2 Change Log (Non-Normative)

D.1 SOAP Specification Changes

Date	Author	Description
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.

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