Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
SOAP version 1.2 is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is based on XML and defines an envelope and framework for describing message contents and processing rules. It also describes a transport binding framework which may be used to exchange messages using an underlying transport protocol. Adjuncts to the envelope and binding framework include a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls and responses. Part 2 (this document) describes the RPC convention and encoding rules along with a concrete HTTP binding specification; the SOAP envelope and transport binding framework are described in Part 1[1].
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is the third W3C Working Draft of the SOAP Version 1.2 specification for review by W3C members and other interested parties. It has been produced by the XML Protocol Working Group (WG), which is part of the XML Protocol Activity.
The specification has been split into two documents: SOAP Version 1.2 Part 1: Messaging Framework which describes the SOAP envelope and the SOAP transport binding framework, and SOAP Version 1.2 Part 2: Adjuncts, which describes the SOAP encoding rules the SOAP RPC convention and a concrete HTTP binding specification.
For a detailed list of changes since the last publication of this document, refer to appendix D Part 2 Change Log. A list of open issues against this document can be found at http://www.w3.org/2000/xp/Group/xmlp-issues.
Comments on this document should be sent to xmlp-comments@w3.org (public archive[13]). It is inappropriate to send discussion emails to this address.
Discussion of this document takes place on the public xml-dist-app@w3.org mailing list[14] under the email communication rules in the XML Protocol Working Group Charter[15].
This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
1 Introduction
1.1 Notational Conventions
1.2 Examples of SOAP Messages
1.3 SOAP Terminology
1.3.1 Data Encoding Concepts
2 The SOAP Data Model
3 SOAP Encoding
3.1 Rules for Encoding Types in XML
3.1.1 id Attribute Information Item
3.1.2 ref Attribute Information Item
3.1.3 itemType Attribute Information Item
3.2 Decoding Faults
3.3 Simple Types
3.3.1 Multi-reference Simple Types
3.3.2 Strings
3.3.3 Enumerations
3.3.4 Array of Bytes
3.4 Polymorphic Accessor
3.5 Compound Types
3.5.1 Compound Values and References to Values
3.5.2 Arrays
3.5.2.1 arraySize Attribute Information Item
3.5.2.2 Array Examples
3.5.3 Generic Compound Types
3.6 Default Values
3.7 root Attribute Information Item
4 Using SOAP for RPC
4.1 RPC and SOAP Body
4.2 RPC and SOAP Header
4.3 RPC Faults
5 A Convention for Describing Features and Bindings
5.1 Model and Properties
5.1.1 Properties
5.1.2 Property Scope
5.1.3 Properties and Features
6 Transport Message Exchange Patterns
6.1 Single-Request-Response TMEP
6.1.1 Message Exchange Pattern Name
6.1.2 Informal Description
6.1.3 Formal Description
6.1.4 Fault Handling
6.1.5 Operation Through SOAP Intermediaries (Informal)
6.1.6 Operation Through SOAP Intermediaries (Formal)
7 Default HTTP Binding
7.1 Introduction
7.2 Binding Name
7.3 Supported Transport Message Exchange Patterns
7.4 Message Exchange Operation
7.4.1 Single Request-Response Exchanges
7.4.1.1 Behaviour of Requesting SOAP Node
7.4.1.1.1 Requesting State
7.4.1.1.2 Waiting State
7.4.1.1.3 Receiving State
7.4.1.1.4 Success and Fail
7.4.1.2 Behaviour of Responding SOAP Node
7.4.1.2.1 Receiving
7.4.1.2.2 Processing
7.4.1.2.3 Responding
7.4.1.2.4 Success and Fail
7.4.1.3 Operation Through SOAP Intermediaries
7.5 Features Expressed External to the Message Envelope
7.5.1 SOAP Action
7.5.2 Simple Authentication Feature
7.6 SOAP HTTP Examples
8 References
8.1 Normative References
8.2 Informative References
A Mapping Application Defined Name to XML Name
A.1 Rules for mapping application defined name to XML Name
A.2 Examples
B SOAP Envelope Examples (Non-Normative)
B.1 Sample Encoding of Call Requests
B.2 Sample Encoding of Response
C Acknowledgements (Non-Normative)
D Part 2 Change Log (Non-Normative)
D.1 SOAP Specification Changes
D.2 XML Schema Changes
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 programming model or implementation specific senamtics. It does however define a simple mechanism for expressing application semantics through a modular packaging model and 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 (2 The SOAP Data Model) defines the data model underlying the SOAP encoding and SOAP RPC representation.
The SOAP encoding rules (3 SOAP Encoding) define a serialization mechanism that can be used to exchange instances of application-defined datatypes.
The SOAP RPC representation (4 Using SOAP for RPC) defines a convention that can be used to represent remote procedure calls and responses.
The SOAP HTTP binding (7 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 message exchange model (SOAP Envelope).
The SOAP relationship to XML (SOAP Envelope).
The SOAP envelope (SOAP Envelope).
The SOAP binding framework (SOAP Transport Binding Framework).
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.
A schema document for the "http://www.w3.org/2001/12/soap-encoding" namespace can be found at http://www.w3.org/2001/12/soap-encoding
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 Extended Backus-Naur Form (EBNF) as described in [8].
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 (7 Default HTTP Binding).
The following example shows a sample SOAP request message. The
SOAP message 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.
<?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.
<?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.
A set of abstract constructs that can be used to describe common data types and link relationships in data in a SOAP message.
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.
Editorial note: JJM | 20020110 |
This section retains the reference to "multistructs" pending resolution of this issue. |
The SOAP data model represents information as a graph of typed nodes. The type system used in the SOAP data model is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. A type is either a simple (scalar) type or is a compound type constructed as a composite of several other typed parts. Examples of simple types are "string," "integer," enumeration, etc. Compound types are described as follows:
Within a compound type, each part is potentially distinguished by a name, ordinal or both. This is called its "accessor". It is possible to have compound types with several accessors each named the same, as for example, RDF does.
An "array" is a compound type in which ordinal position serves as the only distinction between member parts.
A "struct" is a compound type in which accessor name is the only distinction among member parts, and no accessor has the same name as any other.
In some cases it may be necessary for more than one accessor to reference the same instance of part of a compound type. If only one accessor references it, an instance is considered "single-reference". If referenced by more than one it is "multi-reference."
Editorial note: MJG | 20020215 |
With the exception of Subsection 3.5.2.2 this Section has been rewritten from an XML Infoset perspective. Subsection 3.5.2.2 has not been rewritten as its future existence is in question. |
SOAP encoding describes how to serialise instances of data that conform to the data model described in 2 The SOAP Data Model for inclusion in SOAP messages.
The rules presented below operate 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 prose and encoding examples shown in this section assume the following namespace bindings are in-scope;
Prefix | URI |
---|---|
enc | http://www.w3.org/2001/12/soap-encoding |
xs | http://www.w3.org/2001/XMLSchema |
xsi | http://www.w3.org/2001/XMLSchema-instance |
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).
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 4 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 an instance of a simple type as described in 2 The SOAP Data Model.
A "compound value" is an instance of a compound type as described in 2 The SOAP Data Model. Examples of Compound Values are particular purchase orders, stock reports, street addresses, etc.
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."
The unique identifier of an accessor encoded as an
element information item MUST be an id
attribute information item as described below, see
3.1.1 id Attribute Information Item.
A reference to another element information item
(identified by an id
attribute information
item, see 3.1.1 id Attribute Information Item ) MUST be via a
ref
attribute information item as
described below, see 3.1.2 ref Attribute Information Item
The serialization rules of SOAP permit the use of
an xsi:type
attribute information
item ( see Section 2.6.1 of "XML Schema Part 1:
Structures" [4] ) to represent
the type of an element information item,
and hence also the type of the corresponding graph node.
Although SOAP does not mandate the
use of any particular schema notation, all SOAP processors MUST
recognize xsi:type
attribute information
items if present and MUST
associate the corresponding type with the deserialized nodes.
The use of an xsi:type
attribute
information item on a referencing accessor
(i.e. one that has a ref
attribute
information item in its attributes property)
is subtle and it is recommended they be used with caution.
Note that, per the rules of the "XML Schema Part 1: Structures"
[4], the existence of
xsi:type
attribute information items on referencing accessors does NOT
indicate the type of the referred element, and hence does NOT affect
the type of the corresponding node.
The rules for serialization are as follows:
All values are represented using character information item children of element information items.
For each element information item containing a value, the type of the value MUST be represented by at least one of the following conditions:
the containing element information item has an
xsi:type
attribute information item in its
attributes property,
the containing element information item is itself
in the children property of an element information item
which has an itemType
attribute information item, as described
below, see 3.1.3 itemType Attribute Information Item in its
attributes property, or
the localname and namespace name properties of the element information item bear a definite relation to the type, that type then determinable from a schema.
A simple value is represented as a sequence of character information items without any sibling element information items. 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 3.3 Simple Types).
A Compound Value is encoded as a sequence of element information items, each accessor represented by an embedded element information item whose local name property corresponds to the name of the accessor (see A Mapping Application Defined Name to XML Name). For accessors whose names are local to their containing types the corresponding element information item will have a namespace name property which is empty. For all other accessors the corresponding element information item will have a namespace name property which is not empty. (see also 3.5 Compound Types).
A multi-reference simple or compound
value is encoded as an element information item
which has in its attributes property an id
attribute
information item, see 3.1.1 id Attribute Information Item. A referencing
accessor to this value is encoded as an empty element
information item which has in its attribute property
a ref
attribute information item,
see 3.1.2 ref Attribute Information Item with the value of the
corresponding id
attribute information
item.
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. SOAP arrays are defined as having a type of Array in the "http://www.w3.org/2001/12/soap-encoding" namespace or a type derived from that type. See 3.5.2 Arrays for specific rules on array serialization
A NULL value or a default value MAY be
represented by omission of the accessor element
information item. A NULL
value MAY also be indicated by an accessor element
information item which hasin its attributes
property an xsi:nil
attribute information item ( see Section 2.6.2 of "XML Schema Part 1:
Structures" [4] ) with a value of
"true" . A NULL value MAY also be indicated by other
application-dependent
attributes and values.
Note that rule 2 allows element information items to have local name properties which are not identical to the type of the contained value.
The id
attribute information item has
the following Infoset properties:
A local name of id
;
A namespace name which is empty
A specified property with a value of true.
The type of the id
attribute
information item is ID in the
namespace http://www.w3.org/2001/XMLSchema.
The value of the id
attribute
information item is a unique identifier that can be
refered to by a ref
attribute information
item, see 3.1.2 ref Attribute Information Item
The ref
attribute information item has
the following Infoset properties:
A local name of ref
;
A namespace name which is empty
A specified property with a value of true.
The type of the ref
attribute
information item is IDREF in the
namespace http://www.w3.org/2001/XMLSchema.
The value of the ref
attribute
information item is a reference to a unique
identifier defined by an id
attribute information
item, see 3.1.1 id Attribute Information Item
Editorial note: MJG | 20020214 |
This editor is not convinced that the following paragraph is necessary/desirable as the constraint described is either a) not achievable since the XML Spec and the XML Schema Spec have a different view on IDREF or b) redundant as the constraint forms part of the definition of the IDREF type. |
The value of the ref
attribute information
item MUST conform to the XML Specification[8] and the
XML Schema Specification[4],[5].
The itemType
attribute information item has
the following Infoset properties:
A local name of itemType
;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A specified property with a value of true.
The type of the itemType
attribute
information item is QName in the
namespace http://www.w3.org/2001/XMLSchema.
The value of the itemType
attribute
information item specifies the base type of members
of an array, see 3.5.2 Arrays. The default value of
the itemType
attribute
information item is the anyType in the
http://www.w3.org/2001/XMLSchema namespace.
During deserialization a SOAP receiver:
SHOULD generate an env:Sender
SOAP
fault with a subcode of enc:MissingID
if a referencing accessor to a non-existent
multi-reference value is found;
MAY generate an env:Sender
SOAP
fault with a subcode of enc:UntypedValue
if
unable to determine the type of a value (e.g. a schema
being unavailable when required to determine the
type).
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.
Editorial note: MJG | 20020214 |
I think we could remove the example below all the way up to the paragraph that begins 'All simple values MUST be encoded' |
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:
<?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="xs: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:
<age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>Blue</color>
Editorial note: MJG | 20020214 |
I think we could remove the following paragraph as it is a duplicate of serialization rule 3 above. |
All simple values MUST be encoded as the character information item children of element information items 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 in an element information item whose local name property does not have to contain a particular value (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 encoding schema provides element declarations for every simple datatype apart from NOTATION. These MAY be used.
<enc:int xmlns:enc="http://www.w3.org/2001/12/soap-encoding" id="int1">45</enc:int>
A simple value MAY be encoded as a single-reference or a multi-reference value.
The element information item that the simple
value appears in MAY have an
id
attribute information item in its
attributes property. Additional accessor element
information items MAY have
ref
attribute information items in
their attributes properties whose value matches that of the
id
attribute information item.
For example, two accessors to the same value could appear, as follows:
<greeting id="String-0">Hello</greeting> <salutation ref="String-0"/>
However, if the fact that both accessors reference the same instance of the value is immaterial, they may be encoded as two single-reference values as follows:
<greeting>Hello</greeting> <salutation>Hello</salutation>
Schema fragments for these examples could appear similar to the following:
<?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>
Note:
In this example, the type of the element
information item, enc:string, is used as a
convenient way to declare an element
whose base datatype is "xs:string" and which also allows id
and ref
attribute information
items. See the SOAP Encoding schema for the
exact definition. Schemas MAY use these declarations from
the SOAP Encoding schema but are not required to.
The datatype "xs: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 "xs:string".)
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 "xs:string" type. The values ("1", "3", "5") are a possible enumeration based on the "xs:integer" type, and so on. "XML Schema Part 2: Datatypes"[5] supports enumerations for all of the simple types except for "xs: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 "xs:string". In the following schema example "EyeColor" is defined as a type based on "xs:string" with the possible values of "Green", "Blue", or "Brown" enumerated, and instance data is shown accordingly.
<?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>
<p:EyeColor xmlns:p="http://example.org/2001/06/samples" >Brown</p:EyeColor>
The recommended representation of an opaque array of bytes is the "xs:base6Binary" type defined in XML Schemas[4][5], which uses the base64 encoding algorithm defined in MIME[16]. 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.
<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>
Many languages allow accessors that can polymorphically
access values of several types, each type being available at
run time. A polymorphic accessor element information
item MUST have an xsi:type
attribute information item in its attributes
property. The value of the attribute information
item describes the type of the
actual value.
For example, a polymorphic accessor named "cost" with a value of type "xs:float" would be encoded as follows:
<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 type is invariant, as follows:
<cost>29.95</cost>
Editorial note: JJM/JBI | 20020109 |
This section contains copious examples. Aren't we missing the target audience here. The section on Arrays in particular looks far more like a Primer than a specification document. Is it possible to replace this section with a much shorter specification of Compound Types, then use the Primer to supply the examples ? |
SOAP defines types corresponding to the following structural patterns often found in programming languages:
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.
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.
Editorial note: MJG | 20020215 |
This paragraph seems to be a duplicate of serialization rule 4 above, why does it appear twice? |
The members of a Compound Value are encoded as accessor elements information items. When accessors are distinguished by their local name (as for example in a "struct"), the accessor name is used as the value of the local name property of the element information item. For accessors whose names are local to their containing types the corresponding element information item will have a namespace name property which is empty. For all other accessors the corresponding element information item will have a namespace name property which is not empty.
The following is an example of a struct of type "Book":
<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:
<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:
<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@example.com</email> <web>http://www.example.com/henryford</web> </address> </author> </e:Book>
If there were two books with the same author then this could be encoded as follows:
<e:Books xmlns:e="http://example.org/2001/06/books" > <e:Book> <title>My Life and Work</title> <author id="henryford" > <name>Henry Ford</name> <address> <email>mailto:henryford@example.com</email> <web>http://www.example.com/henryford</web> </address> </author> </e:Book> <e:Book> <title>Today and Tomorrow</title> <author ref="henryford" /> </e:Book> </e:Books>
SOAP Encoding arrays have one or more dimensions. An array value is represented as a sequence of element information items reflecting the array. Access to array member values is positional and the local name and namespace name properties of the element information items are not significant. In particular, the local name and namespace name properties of the element information items need not all have the same values. (see also 3.1 Rules for Encoding Types in XML rule #2). Array members appear in ascending ordinal sequence; for multi-dimensional arrays the dimension on the right side varies most rapidly.
Array types derived from "enc:Array" MUST be restrictions of the "enc:Array" type and can be used to represent, for example, arrays limited to integers or arrays of a fixed size.
SOAP Encoding arrays and items within an array can be
single-reference or multi-reference
values. As with compound types generally, if the value
is single-reference, the
element information item contains its value as
character information item children. Otherwise,
the element information item either
contains its value or references its
value via a ref
attribute information
item. The element information items which
make up the array can themselves can be of any type, including
nested arrays.
A SOAP Encoding array MAY contain an arraySize
attribute information item, as described below
( see 3.5.2.1 arraySize Attribute Information Item ) whose value specifies the dimensions of the array
A SOAP Encoding array MAY contain an itemType
attribute information item as descibed
previously ( see 3.1.3 itemType Attribute Information Item ).
This attribute information item specifies the base type for the type of
every member of the array. The default value of this attribute is
"xs:anyType". Each member's type SHOULD be a subtype of the
type specified by the itemType
attribute
information item or
it must be the type specified by the
itemType
attribute information item. If a member does not specify
its type it is assumed to be of the type specified by the
itemType
attribute information item
Note:
The support provided in SOAP 1.1 for partially transmitted arrays and sparse arrays is not available in SOAP 1.2. Partial, sparse and other incomplete arrays can be conveyed as higher level application structures encoded as structs and complete arrays.
The arraySize
attribute information item has
the following Infoset properties:
A local name of arraySize
;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A default value of "*"
The type of the arraySize
attribute
information item is arraySize in the
namespace http://www.w3.org/2001/12/soap-encoding.
enc:arraySize
[1] | arraySizeValue | ::= | ("*" | concreteSize) nextConcreteSize* |
[2] | nextConcreteSize | ::= | " " concreteSize |
[3] | concreteSize | ::= | positive integer |
For example, enc:arraySize
="3 5"
signifies a
two-dimensional array with three rows and five columns.
enc:arraySize
="* 5" signifies
a two-dimensional array with an
unspecified number of rows and five columns. The asterisk, if
present, MUST only be in the first position in the list.
The following example is a schema fragment and an array containing integer array members:
<?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>
<myFavoriteNumbers xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://www.w3.org/2001/12/soap-encoding" enc:itemType="xs:int" enc:arraySize="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:itemType
attribute. The enc:Array type may
contain child elements with both unqualified names and
qualified names from any namespace. Types derived from
enc:Array may declare local child elements with type
information.
As previously noted, the SOAP Encoding 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:
enc:Array
element<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding" xmlns:xs="http://www.w3.org/2001/XMLSchema" enc:itemType="xs:int" enc:arraySize="2"> <enc:int>3</enc:int> <enc:int>4</enc:int> </enc:Array>
Arrays can contain instances of any subtype of the
specified itemType
. That is, the members may be of any
type that can be substituted for the type specified in the
itemType
attribute, according to whatever
substitution 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 itemType
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:
<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:itemType="xs:anyType" enc:arraySize="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 taste 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>
<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://www.w3.org/2001/12/soap-encoding" enc:itemType="xs:anyType" enc:arraySize="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 taste 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 :
<enc:Array xmlns:enc="http://www.w3.org/2001/12/soap-encoding" xmlns:xyz="http://example.org/2001/06/Orders" enc:itemType="xyz:Order" enc:arraySize="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.
<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://www.w3.org/2001/12/soap-encoding" enc:itemType="enc:Array" enc:arraySize="2"> <item ref="array-1"/> <item ref="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:itemType="xs:string" enc:arraySize="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:itemType="xs:string" enc:arraySize="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:
<?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>
<abc:ArrayOfPhoneNumbers xmlns:abc="http://example.org/2001/06/numbers" xmlns:enc="http://www.w3.org/2001/12/soap-encoding" enc:itemType="abc:phoneNumberType" enc:arraySize="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
arraySize
attribute:
<enc:Array xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://www.w3.org/2001/12/soap-encoding" enc:itemType="xs:string" enc:arraySize="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":
<?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>
<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:itemType="def:phoneNumber" enc:arraySize="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:
<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:itemType="xyz:Order" enc:arraySize="2"> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </PurchaseLineItems> </xyz:PurchaseOrder>
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 information
item whose local name property 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 information
item 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.
<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:
<PurchaseLineItems> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </PurchaseLineItems>
An omitted accessor element information item 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.
The root
attribute information item has
the following Infoset properties:
A local name of root
;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
The type of the root
attribute
information item is boolean in the
namespace http://www.w3.org/2001/XMLSchema.
The root
attribute information
item can be used to label
serialization roots that are not true roots of an object graph
so that the object graph can be deserialized. True roots of
an object graph have the implied value of
"true" for this attribute information
item. Element information items that are not
true roots can be labeled as such with a root
attribute information item with a value of
"true". An element information
item can explicitly be labeled as not being a
serialization root with a root
attribute
information item with a value of
"false".
The SOAP root
attribute information item MAY appear on any
descendant element information item of the SOAP Header
or SOAP
Body
element information items. The attribute does not have a default
value.
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 terminology 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 requests and responses.
Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in 3 SOAP Encoding, other representations are possible. The SOAP encodingStyle attribute information item (see [1]SOAP Encoding Attribute) can be used to indicate the encoding style of the RPC invocation and/or the response using the representation described in this section.
Using SOAP for RPC is orthogonal to the SOAP protocol binding (see 7 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).
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 4.3 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.
As noted above, RPC invocation and response structs can be
encoded according to the rules in 3 SOAP Encoding, or
other encodings can be specified using the encodingStyle
attribute information item (see [1]Encoding
Attribute).
Applications MAY process invocations with missing parameters but also MAY return a fault.
Because a result indicates success and a fault indicates failure, it is an error for an RPC response to contain both a result and a fault.
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.
The RPC representation introduces additional SOAP fault
subcodes to the fault codes described in [1]Fault Codes. The
namespace identifier for these SOAP fault subcode values is
"http://www.w3.org/2001/12/soap-rpc" and the
namespace prefix rpc:
is used in this section to
indicate association with this namespace. A schema document
for this namespace can be found at http://www.w3.org/2001/12/soap-rpc
Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):
An env:Receiver
fault SHOULD be
generated when the receiver cannot handle the message because
of some temporary condition, e.g. when it is out of
memory.
An env:DataEncodingUnknown
fault
SHOULD be generated when the arguments are encoded in a
data encoding unknown to the receiver.
An env:Sender
fault with a subcode
value of rpc:ProcedureNotPresent
fault MUST be
generated when the receiver cannot find the procedure
specified.
An env:Sender
fault with a subcode
value of rpc:BadArguments
fault MUST be
generated when the receiver cannot parse the arguments or
when there is a mismatch between what the receiver expects
and what the sender has sent.
Other faults arising in an extension or from the application SHOULD be generated as described in [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.
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 6.1 Single-Request-Response TMEP and an HTTP Binding 7 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.
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.
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
.
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 Transport 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.
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.
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.
Editorial note: JJM/JBI | 20020109 |
The following table refers to PatternSpecificRole. This has not been defined previously. Should this be single:Role instead? |
Property Name | Property Decription |
---|---|
transport:ExchangePatternName | A URI that names the transport message exchange pattern in operation. |
single:Role | A URI that names the pattern specific role of the local SOAP Node with respect to the transport message exchange denoted by the enclosing property container. |
single:State | A relative URI relative with a Base value carried in the PatternSpecificRole property which denotes the current state of the transport message exchange denoted by the enclosing property container. this value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange. |
transport:FailureReason | A URI value that denotes a pattern specific, binding independent reason for the failure of a message exchange. Transport binding specifications may define properties to convey more binding specific details of the failure. |
transport:CurrentMessage | An abstract structure that represents the current message in a message exchange. this abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope due to the action of the message exchange. Depending on pattern dependent state this may be an inbound or outbound message. |
transport:ImmediateDestination | A URI denoting the immediate destination of an outbound message. |
transport:ImmediateSender | A URI denoting the immediate sender of an inbound message. |
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). |
This message exchange pattern is named by the URI "http://www.w3.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:
Prefix | Namespace |
---|---|
transport | http://www.w3.org/2001/12/soap/bindingFramework/TransportExchangeContext/ |
mep | http://www.w3.org/2001/12/soap/transport-mep/ |
fail | http://www.w3.org/2001/12/soap/transport-mep/FailureReasons/ |
single | http://www.w3.org/2001/12/soap/transport-mep/single-request-response/ |
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.
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:
Property Name URI | Value |
---|---|
transport:ExchangePatternName | http://www.w3.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. |
Property Name | Value |
---|---|
transport:ExchangePatternName | "http://www.w3.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. We are assuming the TBTF will provide adequate material. |
CurrentState | Input | NextState | Action |
---|---|---|---|
Requesting | Fail | Set "transport:FailureReason" to "transmissionFailure" | |
Waiting | |||
Waiting | Fail | Set "transport:FailureReason" to "NoResponse" | |
Receiving | |||
Receiving | Fail | Set "transport:FailureReason" to "ReceptionFailure" | |
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 |
CurrentState | Input | NextState | Action |
---|---|---|---|
Receiving | Fail | Set "transport:FailureReason" to "ReceptionFailure" | |
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"; | |
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" | |
Success |
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.
Editorial note: JJM/GD | 20011205 |
Do we want this section in the WD? JBI further notes that, in its current form, this section does not add anything. |
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.
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:
Prefix | Namespace |
---|---|
transport | http://www.w3.org/2001/12/soap/bindingFramework/TransportExchangeContext/ |
mep | http://www.w3.org/2001/12/soap/transport-mep/ |
fail | http://www.w3.org/2001/12/soap/transport-mep/FailureReasons/ |
single | http://www.w3.org/2001/12/soap/transport-mep/single-request-response/ |
HTTP applications MUST use the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges. Please see [12] for parameters defined by this mecia type and their recommended use.
The binding described here is identified with the URI:
http://www.w3.org/2001/12/soap/bindings/defaultHTTP/
The binding described here is provided as a default binding when using HTTP as the underlying protocol.
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.w3.org/2001/12/soap/transport-mep/single-request-response/ (see 6.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. |
The Transport Binding Framework (see SOAP Transport Binding Framework), Transport Message Exchange Pattern Specifications (see 6 Transport Message Exchange Patterns) and Feature Specifications (see 5 A Convention for Describing Features and Bindings) each describe the properties they expect to be present in a transport message exchange context when control of that context passes between the local SOAP Node and a binding instance and vice versa.
The "http://www.w3.org/2001/12/soap/transport-mep/single-request-response/" transport message pattern is described in 6.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 6.1 Single-Request-Response TMEP), and are of type single:StateType
(an enumeration over xs: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.
The overall flow of the behaviour of a Requesting SOAP Node follows the outline state machine description contained in 6.1 Single-Request-Response TMEP.
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. |
Statename | Requesting | ||
Preconditons | See 6.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 | Value |
HTTP Method | POST (the use of other HTTP methods is currently undefined in this binding). |
Request URI | The value of the URI carried in the
transport:ImmediateDestination property of the
transport message exchange context. |
Content-Type header | "application/soap+xml" (see 7.1 Introduction) |
Additional Headers | Generated in accordance with the rules for the binding
specific expression of any optional features in use for this message
exchange eg. SOAPAction (see 7.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. |
Statename | Waiting | ||
Preconditons | None | ||
Description | Wait for HTTP Response | ||
Actions on Leaving State |
| ||
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 | 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 7.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 7.5.1 SOAP Action is applied. |
Fail | |
5xx | Server Error | |||
500 | Internal Server Error |
Indicates that the Response Message contained in the following HTTP response entity body may contain an SOAP Fault. Other internal server errors may be the cause of this status code. The local binding instance continues to receive the incoming message. |
Receiving | |
Instantiated or replaced Property QName | Property Value | |||
transport:FaultHint | true |
Note:
There may be elements in the HTTP infrastructure configured to modify HTTP response entity bodies for 4xx and 5xx status code responses; for example, some existing HTTP origin servers have such a feature as a configuration option. This behavior may interfere with the use of 4xx and 5xx status code responses carrying SOAP fault messages in HTTP. It is recommended that such behavior is disabled for resources accepting SOAP/HTTP requests. If the rewriting behavior cannot be disabled, SOAP/HTTP cannot be used in such configurations.
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 |
The overall flow of the behaviour of a Requesting SOAP Node follows the outline state machine description contained in 6.1 Single-Request-Response TMEP.
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.. |
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 |
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. |
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. |
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 |
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. |
HTTP Response Field | |
HTTP status line | Set according to the following table |
Content-Type header | "application/soap+xml (" see 7.1 Introduction) |
Additional Headers | Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange eg. SOAPAction (see 7.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. |
SOAP Fault | HTTP status code | HTTP reason phrase (informative) |
Non-Fault Response Message | 200 | OK |
env:VersionMismatch | ?? | |
env:MustUnderstand | ?? | |
env:DataEncodingUnknown | ?? | |
env:Sender | ?? | |
env:Receiver | ?? | |
env:rpc | ?? | |
Other Faults | ?? |
This transport binding specification defines a binding specific expression for the following features:
http://www.w3.org/2001/12/soap/bindings/defaultHTTP/SOAPAction/
Other features that are compatible with the message exchange patterns listed above are supported using their generic in-envelope expression defined in the relevant feature specification.
This sub-section defines a binding specific optional feature named:
http://www.w3.org/2001/12/soap/binding/defaultHTTP/SOAPAction/
In the text to follow, the prefix "action" is mapped to the URI "http://www.w3.org/2001/12/soap/binding/defaultHTTP/SOAPAction/"
Some SOAP Receivers using this binding might need certain information to be readily available outside the message envelope. This binding uses an externalised expression of the SOAP Action feature to supply this information.
Use of the SOAP Action feature is OPTIONAL. SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD NOT require its presence in order to operate. Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receivers specifies its use).
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.
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. |
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:
[4] | soapaction | ::= | "SOAPAction" ":" <"> URI-reference <"> |
[5] | URI-reference | ::= | <as defined in RFC2396> |
[6] | req-soapaction | ::= | "required-SOAPAction" ":" <"> URI-reference <"> |
POST /StockQuote HTTP/1.1 Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.example.org/abc#MyMessage" <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > . . . </env:Envelope>
HTTP/1.1 200 OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > . . . </env:Envelope>
[7] | hexDigit | ::= | [0-9A-F] |
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 T1, T2, ... , TN 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 Mi be
M
(Ti).
For each i between 1 (one) and N, let Xi be the Unicode character string defined by the following rules.
Case:
If Ti has no mapping to
Unicode (i.e. M
(Ti) is
undefined), then Xi is
implementation-defined
If i<=N-1, Ti is "_" (underscore), and Ti+1 is "x" (lowercase letter x), then let Xi be "_x005F_".
If i=1, N>=3, T1 is either "x" (lowercase letter x) or "X" (uppercase letter X), T2 is either "m" (lowercase letter m) or "M" (uppercase letter M), and T3 is either "l" (lowercase letter l) or "L" (uppercase letter L), then let Xi be "_xFFFF_" T1
If Ti is not a valid XML NCName character or if i=1 (one) and T1 is not a valid first character of an XML NCName, then:
Let U1, U2, ... , U8 be the eight hex digits [PROD: 7] such that Ti is "U+" U1 U2 ... U8 in the UCS-4 encoding.
Case:
If U1=0, U2=0, U3=0, and U4=0, then let Xi="_x" U5 U6 U7 U8 "_".
This case implies that Ti has a UCS-2 encoding, which is U+U5U6U7U8.
Otherwise, let Xi be "_x" U1 U2 U3 U4 U5 U6 U7 U8 "_".
Otherwise, let Xi be Mi. 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 X1, X2, ... , XN in order from left to right.
Let XML Name be the QName per Namespaces in XML[7]
Editorial note: JJM/JI | 20020109 |
The following examples actually show SOAP over HTTP messages, not SOAP messages. John suggest that we remove the HTTP wrapper, since we primarily want to illustrate the SOAP Envelope. |
POST /StockQuote HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://example.org/2001/06/quotes" <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Header> <t:Transaction xmlns:t="http://example.org/2001/06/tx" env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" env:mustUnderstand="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>
POST /StockQuote HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://example.org/2001/06/quotes" <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Body> <m:GetLastTradePriceDetailed env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <Symbol>DEF</Symbol> <Company>DEF Corp</Company> <Price>34.1</Price> </m:GetLastTradePriceDetailed> </env:Body> </env:Envelope>
HTTP/1.1 200 OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Header> <t:Transaction xmlns:t="http://example.org/2001/06/tx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:int" env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" env:mustUnderstand="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>
HTTP/1.1 200 OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Body> <m:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <PriceAndVolume> <LastTradePrice>34.5</LastTradePrice> <DayVolume>10000</DayVolume> </PriceAndVolume> </m:GetLastTradePriceResponse> </env:Body> </env:Envelope>
HTTP/1.1 500 Internal Server Error Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <env:Fault> <faultcode><value>env:MustUnderstand</value></faultcode> <faultstring>SOAP Must Understand Error</faultstring> </env:Fault> </env:Body> </env:Envelope>
HTTP/1.1 500 Internal Server Error Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Body> <env:Fault xmlns:e="http://example.org/2001/06/faults" > <faultcode> <value>env:Server</value> <subcode> <value>e:OutOfMemory</value> </subcode> </faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails> <message>My application didn't work</message> </e:myfaultdetails> </detail> </env:Fault> </env:Body> </env:Envelope>
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.
Date | Author | Description |
---|---|---|
20020215 | MJG | Removed old array attributes from encoding schema |
20020215 | MJG | Added new array attributes to encoding schema |
20020215 | MJG | Rewrote Section 3 from XML Infoset perspective |
20020214 | MJG | Removed NOTATION type and element decl from encoding schema |
20020214 | MJG | Rolled back Infoset rewrite of RPC section |
20020214 | MJG | Changed relevant occurences of Client and Server to Sender and Receiver for consistency with Part 1. |
20020213 | MJH | Removed (possibly defaulted) from encoding rule 2. |
20020213 | MJH | Changed encoding examples to better show inline multirefs and removed corresponding ednote. |
20020208 | MJG | Added examples to Appendix A |
20020208 | MJG | Changed Section 4.1 ednote |
20020208 | MJG | Rewrote Section 4.1 from Infoset perspective |
20020201 | MJH | Editorial fix to encoding array example narrative. |
20020131 | MJH | Added new "Decoding faults" subsection as resolution for issues 168 and 170. |
20020129 | MJH | Pulled out the single/multi ref descriptions in Simple Types/Strings and Simple Types/Array of Bytes into a new separate subsection of the Simple Types section. |
20020129 | MJH | Misc editorial fixes. |
20020129 | MJH | Fixed EBNF reference to use XML Recommendation notation. |
20020129 | MJH | Fixed reference to SOAP media type draft, removed duplicated information, renumbered following references. |
20020125 | HFN | In section on SOAP data model, changed "The SOAP data model represents information as a graph of typed objects" to "The SOAP data model represents information as a graph of typed nodes" |
20020125 | HFN | Removed ednote in section 7.1 regarding SOAP media type and added reference to the soap media type internet draft for details about use of media type parameters. I have not changed the use of SOAPAction during this. |
20020121 | MJH | Changed encoding references from anyURI to IDREF (Issue 170). |
20020118 | MJH | Changed rpc error text to use new SOAP fault subcodes (Issue 173). |
20020117 | MJH | Fixed indentation on more examples. |
20020117 | MJH | Removed sparse and partially transmitted arrays. Modified encoding section to use arraySize and itemTpe attributes. Resolves issues 117, 144 and 161. |
20020117 | JJM | Added text for resolution of issue 12. |
20020114 | MJH | Fixed indentation in 3 of the examples in SOAP encoding section. |
20020114 | MJH | Removed duplicate text for section 2 (SOAP Data Model) from section 3 (SOAP Encoding). |
20020109 | JJM | Incoporated comments from John Ibbotson. |
20011220 | JJM | Added resolution for 171 in section 4.1 "Rules for Encoding Types in XML". |
20011219 | JJM | Fixed abstract. |
20011214 | JJM | Fixed incorrect reference to XML Protocol Charter. |
20011214 | JJM | Fixed incorrect combination of olist, item and p in "A Mapping Application Defined Name to XML Name" section |
20011214 | JJM | Fixed incorrect reference to XLink. |
20011213 | JJM | Changed the namespace to http://www.w3.org/2001/12/. |
20011211 | JJM | In the new TBTF sections, use the passive voice instead of "we". |
20011211 | JJM | Replace application/soap+xml by application/soap in "HTTP Request Fields" table. |
20011211 | JJM | Replace text/xml by application/soap in "Responding State" table. |
20011211 | JJM | Fixed typo in section 6 noticed by Mario. |
20011210 | JJM | Incorporated David's editorial changes to section 6. |
20011206 | JJM | Fixes to occurrences of texting refering to blocks (instead of body elements). |
20011206 | JJM | Converted all the tables in sections 7 and 8 into proper XML. |
20011206 | JJM | Moved HTTP examples from old binding section to new binding section. |
20011206 | JJM | Replaced SOAPAction production rules in new binding section with that from old binding section (they were identical, but formatting was better). |
20011206 | JJM | Removed old binding section. |
20011206 | JJM | Updated references to XLink and XML Infoset (now recommandations). |
20011206 | JJM | Moved text about application/soap from old binding to new binding section. |
20011206 | JJM | Transformed references into proper hyperlinks. |
20011206 | JJM | Changed image format to GIF. |
20011206 | JJM | Reduced image size. |
20011205 | JJM | Incorporated TBTF Part 2 (Features). |
20011205 | JJM | Incorporated TBTF Part 3 (MEPs). |
20011205 | JJM | Incorporated TBTF Part 4 (HTTP Binding). There are still some HTML-icisms. Hopefully, they will go away after todays conference call. |
20011204 | MJH | Changes to encoding section - issue 18. |
20011204 | MJH | Updated DTD and appendix A to preserve subscripts in variable elements. |
20011204 | MJH | Updated reference to RFC2376 to RFC3023. |
20011204 | JJM | Updated the ednote for SOAPAction as an optional feature, now that this is defined in section 5.. |
20011204 | JJM | Added quotes around "Required-SOAPAction". |
20011129 | MJG | Fixed ednote related to change from text/xml to application/soap |
20011122 | MJH | Removed placeholder and ednote for HTTP extension framework. The actual text of the section was removed prior to the previous draft and replaced with an ednote requesting feedback on the removal. As none was received the subsection has now been completely removed along with the corresponding bibliography entry. |
20011121 | MJH | Added appendix for mapping application names to XML element names. Added cross references to encoding and RPC sections to point readers to the new appendix. (Issue 1) |
20011029 | MJH | Added text to state that SOAP is no longer an acronym ( Issue 125 ) |
20011029 | MJH | Amended introductory text (Issue 148) |
20011029 | MJH | Amended introductory text (Issue 147) |
20011029 | MJH | Amended abstract (Issue 147) |
20011026 | MJG | Amended BNF for arrayTypeValue to use form from XML 1.0 Rec ( Issue 162 ) |
20011026 | MJG | Amended prose related to DTDs and PIs ( Issue 4 ) |
20011026 | MJG | Updated schema change table to list change from ur-type to anyType |
20011026 | MJG | Added xml declaration to all XML examples with a root of env:Envelope or xs:schema |
20011024 | MJG | Changed media type from text/xml to application/soap and added associated ednote |
20010926 | MJG | Updated member list |
20010926 | MJG | Updated ednote in section 6.4 |
20010926 | MJG | Changed rpc namespace to http://www.w3.org/2001/09/soap-rpc |
20010921 | MJG | Added rpc namespace to list in Section 2 |
20010921 | MJG | Added new schema for rpc result element as described in section 5.1 |
20010921 | MJG | Amended section 5.1 to incorporate description of rpc result element |
20010921 | MJG | Changed targetNamespace attribute of encoding schema to http://www.w3.org/2001/09/soap-encoding |
20010921 | JJM | Used text proposed by Noah for ednote on SOAPAction. |
20010920 | JJM | Make the wording clarification regarding issue 45 (descreasing order of precedence). |
20010920 | JJM | Removed current security section; added new security subsection to HTTP binding section, with a temporary ednote until we get text from Henrik and Chris). |
20010920 | JJM | Change the namespace of the envelope to http://www.w3.org/2001/09/... |
20010920 | JJM | Add an editorial note about why some sections are not written in terms of infoset. |
20010920 | JJM | Add ednote from Jacek regarding SOAPAction. |
20010918 | JJM | Added ednote to the "SOAPAction" section indicating that a HTTP status code needs to be obtained from IANA. |
20010918 | JJM | Removed last electrocommerce.org URL from examples. |
20010914 | JJM | Added text from Henrik to beef-up the "Data Model" section placeholder text. |
20010914 | JJM | Back to "Adjuncts" again. |
20010914 | JJM | Fixed issues 124, 126, 127, 128 and 132. |
20010914 | JJM | Fixed typos and indentation. |
20010914 | JJM | Reference the XML InfoSet Proposed Recommandation instead of the Candidate Recommandation. |
20010911 | JJM | Changed XML Information Set into a normative reference. Changed XML Protocol Comments Archive, Discussion Archive and Charter into non-normative references. Added a reference to RFC2396 in section 4, 3rd paragraph. |
20010905 | MJH | Wordsmithed abstract and introduction to better reflect split into parts 1 and 2. Rationalised list of references so only cited works appear. Removed envelope schema changes. Added bibref entries for cross references to Part 1, fixed links so they target the HTML instead of XML version of the doc. |
20010831 | JJM | Added a close paragraph tag before starting a new olist or ulist. |
20010831 | JJM | Properly declared the language for the spec, so that we can generate valid HTML. |
20010831 | JJM | Added text from Hugo to emphasize the fact that the SOAP root attribute is of type XMLSchema boolean. |
20010830 | MJG | Copied "Relation to XML" section from part 1. |
20010830 | MJG | Removed Design Goals section (design goals listed relevant to Part 1 not Part 2) |
20010830 | JJM | Removed terminology not relevant to part2. |
20010830 | JJM | Added SOAP examples from part 1, introductory sections. |
20010830 | JJM | Added SOAP example appendix from part1. |
20010830 | JJM | Added a paragraph to section 1 pointing to part2 for encoding, rpc and http binding. |
20010830 | JJM | Added a paragraph at the beginning of section 3 to cover serializations containing references to data outside the serialization, as per 20010829 teleconference. |
20010830 | JJM | Remove 2nd sentence, bullet 5, RPC faults section, as per 20010829 teleconference. |
20010830 | JJM | Remove 2nd sentence, bullet 1, RPC faults section, as per 20010822 teleconference. |
20010829 | JJM | Added a placehoder for the forthcoming Data Model section. |
20010829 | JJM | Removed the Envelope Example section, already present in part1. |
20010829 | JJM | Updated the specs title. |
20010829 | JJM | Replaced specref with xspecref for references to Part1 items. |
20010829 | JJM | Added bibliography entry for SOAP 1.2 Part 1. |
20010829 | JJM | Removed former sections 1, 2, 3 and 4, and the SOAP versioning appendix. Moved the RPC section before the HTTP binding section, as per the 20010815 teleconference call. |
20010829 | JJM | Did split the spec into two parts. |
20010829 | JJM | Refered to the proper DTD and stylesheet. |
20010829 | JJM | Updated the list of WG members: one person per line in the XML file, for easier updating. |
20010816 | MJH | Replaced a mustUnderstand="1" with mustUnderstand="true". Slight rewording in mu description. |
20010810 | MJH | Merged in RPC fault rules text from Jacek. Added new DataEncodingUnknown fault code to SOAP Fault Codes section. Added editorial notes about introduction of new fault code namespace for RPC. |
20010809 | MJH | Merged in "mustHappen" descriptive text from Glen and Noah. |
20010809 | MJH | Fixed language around "default" values of attributes. |
20010809 | MJH | Removed HTTP extension framework, added editorial note to describe why. |
20010808 | MJH | Added Infoset "specified" property text from Chris. |
20010808 | MJH | Removed assumption 4 from version transition appendix. |
20010808 | MJH | Added reference to SOAP 1.1 specification to references section, removed SOAP 1.1 author list from acknowledgments section. |
20010807 | MJH | Converted specification from HTML to XML conforming to W3C XMLSpec DTD. Numerous resulting formatting changes. |
20010720 | MJG | Applied Infoset terminology to sections 1, 2, 3 and 4. |
20010629 | MJG | Amended description of routing and intermediaries in Section 2.1 |
20010629 | JJM | Changed "latest version" URI to end with soap12 |
20010629 | JJM | Remove "previous version" URI |
20010629 | JJM | Removed "Editor copy" in <title> |
20010629 | JJM | Removed "Editor copy" in the title. |
20010629 | JJM | Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft. |
20010629 | JJM | Pre-filed publication URIs. |
20010629 | JJM | Incorporated Davids suggested changes for the examples in section 4.1.1 to 4.4.2 |
20010629 | JJM | Fixed some remaining typos. |
20010629 | MJH | Fixed a couple of typos. |
20010628 | MJG | Made various formatting, spelling and grammatical fixes. |
20010628 | MJG | Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50 |
20010628 | MJG | Changed text in Section 2.1 from "it is both a SOAP sender or a SOAP receiver" to "it is both a SOAP sender and a SOAP receiver" |
20010628 | MJG | Fixed caption on Example 24 |
20010628 | MJH | Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence. |
20010628 | MJH | Updated figure 1, removed ednote to do so. |
20010622 | HFN | Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model. |
20010622 | HFN | Moved the definition of block to encapsulation section in terminology |
20010622 | HFN | Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and does not belong in a terminology section |
20010622 | HFN | Removed reference to "Web Characterization Terminology & Definitions Sheet" in terminology section as this is not an active WD |
20010622 | HFN | Added revised glossary |
20010622 | HFN | Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding |
20010622 | MJG | Added http://example.com/... to list of application/context specific URIs in section 1.2 |
20010622 | MJG | Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes |
20010622 | MJG | Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1 |
20010622 | MJG | In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match. |
20010622 | MJG | Moved MisunderstoodHeader from envelope schema into seperate faults schema. Removed entry in envelope schema change table in Appendix D.2 that refered to additon of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2 |
20010622 | MJH | Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions. |
20010622 | MJG | Made BNF in section 6.1.1 into a table. |
20010622 | MJG | Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet |
20010622 | MJG | Amended text regarding namespace prefix mappings in section 1.2 |
20010622 | MJG | Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote. |
20010622 | MJG | Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document |
20010622 | MJG | Reordered entries in schema change classification table in Appendix D.2 |
20010622 | MJG | Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly |
20010622 | JJM | Manually numbered all the examples (53 in total!) |
20010622 | JJM | Added caption text to all the examples |
20010622 | JJM | Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>) |
20010621 | HFN | Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2 |
20010621 | HFN | Added version transition appendix C |
20010621 | HFN | Applied new styles to examples |
20010621 | HFN | Changed term "transport" to "underlying protocol" |
20010621 | HFN | Changed example URNs to URLs of the style http://example.org/... |
20010621 | MJH | Updated the Acknowledgements section. |
20010621 | JJM | Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2. |
20010621 | JJM | Incorporated David Fallsides comments on section Status and Intro sections. |
20010620 | HFN | Changed the status section |
20010620 | HFN | Changed title to SOAP Version 1.2 and used that first time in abstract and in body |
20010620 | HFN | Removed question from section 2.4 as this is an issue and is to be listed in the issues list |
20010620 | HFN | Moved change log to appendix |
20010615 | JJM | Renamed default actor to anonymous actor for now (to be consistent) |
20010615 | JJM | Fixed typos in section 2 |
20010614 | JJM | Updated section 2 to adopt the terminology used elsewhere in the spec. |
20010613 | MJH | Updated mustUnderstand fault text with additions from Martin Gudgin. |
20010613 | MJH | Added schema changes appendix from Martin Gudgin. |
20010613 | MJH | Added mustUnderstand fault text from Glen Daniels. |
20010612 | MJH | Fixed document <title>. |
20010612 | MJH | Moved terminology subsection from message exchange model section to introduction section. |
20010612 | MJH | Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate. |
20010612 | MJH | Removed trailing "/" from encoding namespace URI. |
20010612 | MJH | Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org. |
20010612 | MJH | Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places. |
20010611 | MJH | Incorporated new text for section 2. |
20010611 | JJM | Changed remaining namespaces, in particular next. |
20010609 | JJM | Changed the spec name from XMLP/SOAP to SOAP. |
20010609 | JJM | Changed the version number from 1.1 to 1.2. |
20010609 | JJM | Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-. |
20010609 | JJM | Replaced the remaining XS and XE prefixes to env and enc, respectively. |
20010601 | MJH | Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation. |
20010601 | JJM | Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation. |
20010531 | HFN | Removed appendices C and D and added links to live issues list and separate schema files. |
20010531 | MJH | Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation. |
The encoding schema has been updated to be compliant with the XML Schema Recomendation[4][5]. The table below shows the categories of change.
Class | Meaning |
---|---|
Addition | New constructs have been added to the schema |
Clarification | The meaning of the schema has been changed to more accurately match the specification |
Change | The schema has been changed due to a change in the specification |
Deletion | Constructs have been removed from the schema |
Name | The schema has been changed due to a datatype name change in the XML Schema specification |
Namespace | A namespace name has been changed |
Semantic | The meaning of the schema has been changed |
Style | Style changes have been made to the schema |
Syntax | The syntax of the schema has been updated due to changes in the XML Schema specification |
The table below lists the changes to the encoding schema.
Class | Description |
---|---|
Namespace | Updated to use the http://www.w3.org/2001/XMLSchema namespace |
Namespace | Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-encoding |
Semantic | Changed type of the root attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed. |
Addition | Added processContents="lax" to all element and attribute wildcards |
Syntax | Changed base64 simple type to be a vacuous restriction of the base64Binary type in the http://www.w3.org/2001/XMLSchema namespace |
Syntax | Updated all complex type definitions with simple base types to new syntax |
Syntax | Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type |
Syntax | Added <xs:sequence> to all named model group definitions |
Deletion | Removed the timeDuration datatype |
Addition | Added duration datatype derived by extension from the duration datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Deletion | Removed the timeInstant datatype |
Addition | Added dateTime datatype derived by extension from the dateTime datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added gYearMonth datatype derived by extension from the gYearMonth datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added gYear datatype derived by extension from the gYear datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added gMonthDay datatype derived by extension from the gMonthDay datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Deletion | Removed the binary datatype |
Addition | Added hexBinary datatype derived by extension from the hexBinary datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added base64Binary datatype derived by extension from the base64Binary datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Deletion | Removed the uriReference datatype |
Addition | Added anyURI datatype derived by extension from the anyURI datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added normalizedString datatype derived by extension from the normalizedString datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Addition | Added token datatype derived by extension from the token datatype in the http://www.w3.org/2001/XMLSchema namespace. |
Clarification | Added explicit namespace="##any" to all element and attribute wildcards which did not previously have an explicit namespace attribute |
Style | Where possible comments have been changed into annotations |
Addition | Added element declaration for anyType |
Deletion | Removed the ur-type element declaration and complexType definition |
Deletion | Removed the NOTATION element declaration and complexType definition |
Deletion | Removed global attribute declarations for attributes associated with sparse arrays. |
Addition | Added arraySize global attribute decl and associated type definitions |
Addition | Added itemType global attribute decl |
Change | Amended arrayAttribute attribute group removing sparse array attributes and adding arraySize and itemType attributes. |