Copyright © 2002 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 intended for exchanging structured information in a decentralized, distributed environment. SOAP Version 1.2 Part 2: Adjuncts defines a set of adjuncts that may be used with SOAP Version 1.2 Part1: Messaging Framework. This specification depends on SOAP Version 1.2 Part 1: Messaging Framework [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 fourth W3C Working Draft of the SOAP Version 1.2 specification for review by W3C members and other interested parties. It has been produced by the XML Protocol Working Group (WG), which is part of the XML Protocol Activity.
Refer to appendix E. Part 2 Change Log for a detailed list of changes since the last publication of this document. 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 [14]). It is inappropriate to send discussion email to this address.
Discussion of this document takes place on the public xml-dist-app@w3.org mailing list [15] under the email communication rules in the XML Protocol Working Group Charter [16].
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
2. SOAP Data Model
3. SOAP Encoding
4. SOAP RPC Representation
5. A Convention for Describing Features and Bindings
6. SOAP-Supplied Message Exchange Patterns and Features
7. SOAP HTTP Binding
8. References
A. Mapping Application Defined Names to XML Names
B. Using W3C XML Schema with SOAP Encoding (Non-Normative)
C. RPC and SOAP HTTP Binding Examples (Non-Normative)
D. Acknowledgements (Non-Normative)
E. Part 2 Change Log (Non-Normative)
1. Introduction
1.1 Notational Conventions
2. SOAP Data Model
2.1 Graph Edges
2.1.1 Edge labels
2.2 Graph Nodes
2.2.1 Single and Multi reference nodes
2.3 Values
3. SOAP Encoding
3.1 Rules for Encoding Graphs in XML
3.1.1 Encoding graph edges and nodes
3.1.2 Encoding simple values
3.1.3 Encoding compound values
3.1.4 Computing the Type Name property
3.1.4.1 itemType Attribute Information Item
3.1.5 Unique identifiers
3.1.5.1 id Attribute Information Item
3.1.5.2 ref Attribute Information Item
3.1.5.3 Constraints on id and ref attribute information
items
3.1.6 arraySize Attribute Information Item
3.2 Decoding Faults
4. SOAP RPC Representation
4.1 Use of RPC on the World Wide Web
4.1.1 Identification of RPC Resources
4.1.2 Distinguishing Resource Retrievals from other RPCs
4.2 RPC and SOAP Body
4.2.1 RPC Invocation
4.2.2 RPC Response
4.2.3 SOAP Encoding Restriction
4.3 RPC and SOAP Header
4.4 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. SOAP-Supplied Message Exchange Patterns and Features
6.1 Property Conventions for Message Exchange Patterns
6.2 Request-Response Message Exchange Pattern
6.2.1 SOAP Feature Name
6.2.2 Description
6.2.3 State Machine Description
6.2.4 Fault Handling
6.3 SOAP Response Message Exchange Pattern
6.3.1 SOAP Feature Name
6.3.2 Description
6.3.3 State Machine Description
6.3.4 Fault Handling
6.4 Web Method Specification Feature
6.4.1 SOAP Feature Name
6.4.2 Description
6.4.3 Web Method Feature State Machine
7. SOAP HTTP Binding
7.1 Introduction
7.2 Binding Name
7.3 Supported Message Exchange Patterns
7.4 Supported Features
7.5 MEP Operation
7.5.1 Behavior of Requesting SOAP Node
7.5.1.1 Init
7.5.1.2 Requesting
7.5.1.3 Sending+Receiving
7.5.1.4 Success and Fail
7.5.2 Behavior of Responding SOAP Node
7.5.2.1 Init
7.5.2.2 Receiving
7.5.2.3 Receiving+Sending
7.5.2.4 Success and Fail
7.6 Security Considerations
8. References
8.1 Normative References
8.2 Informative References
A. Mapping Application Defined Names to XML Names
A.1 Rules for mapping application defined names to XML Names
A.2 Examples
B. Using W3C XML Schema with SOAP Encoding (Non-Normative)
B.1 Validating using the minimum schema
B.2 Validating using the SOAP Encoding schema
B.3 Validating using more specific schemas
C. RPC and SOAP HTTP Binding Examples (Non-Normative)
C.1 Sample Encoding of Call Requests
C.2 Sample Encoding of Response
D. Acknowledgements (Non-Normative)
E. Part 2 Change Log (Non-Normative)
E.1 SOAP Specification Changes
E.2 XML Schema Changes
SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. The SOAP specification consists of three parts. Part 2 (this document) defines a set of adjuncts that MAY be used with the SOAP messaging framework:
The SOAP Data Model represents application-defined data structures and values as a directed, edge-labeled graph of nodes (see 2. SOAP Data Model).
The SOAP Encoding defines a set of rules for encoding instances of data that conform to the SOAP Data Model for inclusion in SOAP messages (see 3. SOAP Encoding).
The SOAP RPC Representation defines a convention for how to use the SOAP Data Model for representing RPC calls and responses (see 4. SOAP RPC Representation).
A convention for describing features and bindings (see 5. A Convention for Describing Features and Bindings).
A request response message exchange pattern definition and a message exchange pattern supporting non-SOAP requests for SOAP responses, (see 6. SOAP-Supplied Message Exchange Patterns and Features).
A feature for control of methods used on the World Wide Web (see 6.4 Web Method Specification Feature).
The SOAP HTTP Binding defines a binding of SOAP to HTTP [2] following the rules of the SOAP Protocol Binding Framework [1] (see 7. SOAP HTTP Binding).
Part 0 [13] is a non-normative document intended to provide an easily understandable tutorial on the features of the SOAP Version 1.2 specifications.
Part 1 [1] defines the SOAP messaging framework.
Note:
In previous versions of this specification the SOAP name was an acronym. This is no longer the case.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [3].
This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [10]).
Prefix | Namespace | Notes |
---|---|---|
env | "http://www.w3.org/2001/12/soap-envelope" | Defined by Part 1 [1]. |
enc | "http://www.w3.org/2001/12/soap-encoding" | A normative XML Schema [4], [5] document for the "http://www.w3.org/2001/12/soap-encoding" namespace can be found at http://www.w3.org/2001/12/soap- encoding. |
xs | "http://www.w3.org/2001/XMLSchema" | Defined in the W3C XML Schema specification [4], [5]. |
xsi | "http://www.w3.org/2001/XMLSchema-instance" | Defined in the W3C XML Schema specification [4], [5]. |
context | "http://www.w3.org/2001/12/soap/bindingFramework/ExchangeContext/" | See 6.2 Request-Response Message Exchange Pattern. |
mep | "http://www.w3.org/2001/12/soap/mep/" | See 6.2 Request-Response Message Exchange Pattern. |
fail | "http://www.w3.org/2001/12/soap/mep/FailureReasons/" | See 6.2 Request-Response Message Exchange Pattern. |
reqres | "http://www.w3.org/2001/12/soap/mep/request-response/" | See 6.2 Request-Response Message Exchange Pattern. |
webmeth | "http://www.w3.org/2001/12/soap/features/web-method/" | See 6.4 Web Method Specification Feature. |
Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [6].
This specification uses the Extended Backus-Naur Form (EBNF) as described in [8].
With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.
The SOAP Data Model represents application-defined data structures and values as a directed edge-labeled graph of nodes. Components of this graph are described in the following sections.
The purpose of the SOAP Data Model is to provide a mapping of non-XML based data to some wire representation. It is important to note that use of the SOAP Data Model, the accompanying SOAP Encoding (see 3. SOAP Encoding), and/or the SOAP RPC Representation (see 4. SOAP RPC Representation) is OPTIONAL. Applications which already model data in XML, for example using W3C XML Schema [4],[5], may not need to use the SOAP Data Model. Due to their optionality, it is NOT a requirement to implement the SOAP Data Model, the SOAP Encoding and/or the SOAP RPC Representation as part of a SOAP node.
Edges in the graph are said to originate at a graph node and terminate at a graph node. An edge that originates at a graph node is known as an outbound edge with respect to that graph node. An edge that terminates at a graph node is known as an inbound edge with respect to that graph node. An edge MAY originate and terminate at the same graph node.
The outbound edges of a given graph node MAY be distinguished by label or by position, or both. Position is a total order on such edges; thus any outbound edge MAY be identified by position.
An edge label is an XML Schema Qualified Name (see XML Schema Part 2: Datatypes [5]). Two edge labels are equal if and only if both of the following are true:
Their local name values are the same.
Either of the following is true:
Their namespace name values are missing.
Their namespace name values are present and the same.
See 2.3 Values for uses of edge labels and position to distinguish the members of encoded values, and XML Schema Part 2: Datatypes [5] for more information about comparing XML qualified names.
A graph node is either a terminal graph node or a non-terminal graph node. A non-terminal graph node has one or more outbound edges. A terminal graph node has no outbound edges and an optional lexical value. Both types of graph node have an optional unique identifier of type ID in the namespace named "http://www.w3.org/2001/XMLSchema", (see XML Schema Part2: DataTypes [5]) and an optional type name of type QName in the namespace named "http://www.w3.org/2001/XMLSchema" (see XML Schema Part2: DataTypes [5]).
A simple value is represented as a terminal graph node.
A compound value is represented as a non-terminal graph node as follows:
If the labels of a non-terminal graph node's outbound edges are not unique (i.e. they can be duplicated), the non-terminal graph node is known as a "generic". Outbound edges of a generic MAY be distinguished by label and/or position, according to the needs of the application.
A non-terminal graph node whose outbound edges are distinguished solely by their labels is known as a "struct". The outbound edges of a struct MUST be labeled with distinct names (see 2.1.1 Edge labels).
A non-terminal graph node whose outbound edges are distinguished solely by position is known as an "array". The outbound edges of an array MUST NOT be labelled.
Editorial note | |
The Working Group solicits feedback from implementors regarding the usefulness or otherwise of 'generics'. |
SOAP Encoding describes how to encode instances of data that conform to the data model described in 2. SOAP Data Model. This encoding MAY be used to transmit data in SOAP header blocks and/or SOAP bodies. Other data models, alternate encodings of the SOAP Data Model as well as unencoded data MAY also be used in SOAP messages (see [1] SOAP encodingStyle Attribute for specification of alternative encoding styles and see 4. SOAP RPC Representation for restrictions on data models and encodings used to represent SOAP Remote Procedure Calls).
The serialization rules defined in this section are
identified by the URI
"http://www.w3.org/2001/12/soap-encoding". SOAP
messages using this particular serialization SHOULD indicate
that fact by using the SOAP encodingStyle
attribute
information item (see [1] SOAP
encodingStyle Attribute).
XML allows very flexible encoding of data. SOAP Encoding defines a narrower set of rules for encoding the graphs described in 2. SOAP Data Model. This section defines the encoding at a high level, and the subsequent sub-sections describe the encoding rules in more detail. The encodings described in this section can be used in conjunction with the mapping of RPC calls and responses specified in 4. SOAP RPC Representation.
The encodings are described below from the perspective of a de-serializer. In each case, the presence of an XML serialization is presumed, and the mapping to a corresponding graph is described.
More than one encoding is typically possible for a given graph. When serializing a graph for transmission inside a SOAP message any representation that deserializes to the identical graph MAY be used; when receiving an encoded SOAP message, all representations MUST be accepted.
Each graph edge is encoded as an element information item and each element information item represents a graph edge. 3.1.3 Encoding compound values describes the relationship between edge labels and the local name and namespace name properties of such element information items.
The graph node at which an edge terminates is determined by examination of the serialized XML as follows:
If the element information item representing
the edge does not have a ref
attribute
information item (see 3.1.5.2 ref Attribute Information Item)
among its attributes then that element information
item is said to represent a node in
the graph and the edge terminates at that node.
If the element information item representing
the edge does have a ref
attribute
information item (see 3.1.5.2 ref Attribute Information Item) among its attributes,
then the value of that attribute information
item MUST be identical to the value of exactly one
id
attribute information item (
see 3.1.5.1 id Attribute Information Item) in the same envelope.
In this case the edge terminates at the graph node
represented by the element information item
on which the id
attribute information
item appears. That element information
item MUST be in the scope of an
encodingStyle
attribute with a value of
"http://www.w3.org/2001/12/soap-encoding".
All nodes in the graph are encoded as described in 1 above. Additional inbound edges for multi reference graph nodes are encoded as described in 2 above.
The lexical value of a terminal graph node (simple value) is the sequence of Unicode characters identified by the character information item children of the element information item representing that node.
An outbound edge of a graph node is encoded as an element information item child of the element information item that represents the node (see 3.1.1 Encoding graph edges and nodes). Particular rules apply depending on what kind of compound value the graph node represents. These rules are as follows:
For a graph edge which is distinguished by label ("struct" or "generic"), the namespace name and local name properties of the element information item together determine the value of the edge label.
For a graph edge which is distinguished by position ("array" or "generic"):
The ordinal position of the graph edge corresponds to the position of the element information item relative to its siblings
If outbound edges are distinguished only by position ("array") then the local name and namespace name properties of the element information item are not significant.
The following rules apply to the encoding of a graph node that represents an "array":
The element information item
representing an array node MAY have among its
attributes an itemType
attribute
information item (see 3.1.4.1 itemType Attribute Information Item).
The element information item
representing an array node MAY have among its
attributes an arraySize
attribute
information item (see 3.1.6 arraySize Attribute Information Item).
If a graph edge does not terminate in a graph node then it can either be omitted from the serialization or it can be encoded as an element information item with an xsi:nil attribute information item whose value is "true".
The type name property of a graph node is a {namespace name, local name} pair computed as follows:
If the element information item representing the
graph node has an xsi:type
attribute
information item
among its attributes then the type name property of the
graph node is the value of the xsi:type
attribute
information item.
Note:
This attribute is of type QName in the namespace named "http://www.w3.org/2001/XMLSchema" (see XML Schema Part 2: Datatypes [5]); its value consists of the pair {namespace name, local name}. Neither the prefix used to construct the QName nor any information relating to any definition of the type is considered to be part of the value. The SOAP graph carries only the qualified name of the type.
Otherwise if the parent element information item of the
element information item representing the graph
node has a soap:itemType
attribute
information item (see 3.1.4.1 itemType Attribute Information Item)
among its attributes then the type
name property of the graph node is the value of the
soap:itemType
attribute information item
Otherwise the value of the type name property of the graph node is unspecified.
Note:
These rules define how the type name property of a graph node in a graph is computed from a serialized encoding. This specification does not mandate validation using any particular schema language or type system. Nor does it include built in types or provide any standardized faults to reflect value/type name conflicts.
However, nothing prohibits development of additional specifications to describe the use of SOAP with particular schema languages or type systems. Such additional specifications MAY mandate validation using particular schema language, and MAY specify faults to be generated if validation fails. Such additional specifications MAY specify augmentations to the deserialized graph based on information determined from such a validation. The use by SOAP of xsi:type is intended to facilitate integration with the W3C XML Schema language (see B. Using W3C XML Schema with SOAP Encoding). Other XML based schema languages, data schemas and programmatic type systems MAY be used but only to the extent that they are compatible with the serialization described in this specification.
The itemType
attribute information item has
the following Infoset properties:
A local name of itemType
;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A specified property with a value of true.
The type of the itemType
attribute
information item is QName in the
namespace named "http://www.w3.org/2001/XMLSchema".
The value of the itemType
attribute
information item is used to compute the type name
property (see 3.1.4 Computing the Type Name property) of members of
an array.
The id
attribute information item has
the following Infoset properties:
A local name of id
;
A namespace name which is empty
A specified property with a value of "true".
The type of the id
attribute
information item is ID in the namespace named
"http://www.w3.org/2001/XMLSchema".
The value of the id
attribute information
item is a unique identifier that can be referred to by
a ref
attribute information item
(see 3.1.5.2 ref Attribute Information Item).
The ref
attribute information item has
the following Infoset properties:
A local name of ref
;
A namespace name which is empty
A specified property with a value of true.
The type of the ref
attribute information
item is IDREF in the namespace named "http://www.w3.org/2001/XMLSchema".
The value of the ref
attribute information
item is a reference to a unique identifier defined
by an id
attribute information item
(see 3.1.5.1 id Attribute Information Item).
The value of a ref
attribute information item MUST also be
the value of exactly one id
attribute information item.
A ref
attribute information item and
an id
attribute information item
MUST NOT appear on the same element information item.
The arraySize
attribute information item has
the following Infoset properties:
A local name of arraySize
;
A namespace name of "http://www.w3.org/2001/12/soap-encoding".
A default value of "*"
The type of the arraySize
attribute
information item is arraySize in the
namespace named "http://www.w3.org/2001/12/soap-encoding".
The value of the arraySize
attribute information item MUST conform to the following EBNF grammer
[1] | arraySizeValue | ::= | ("*" | concreteSize) nextConcreteSize* |
[2] | nextConcreteSize | ::= | " " concreteSize |
[3] | concreteSize | ::= | [0-9]+ |
The array's dimensions are represented by each item in the list of sizes (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list.
During deserialization a SOAP receiver:
SHOULD generate an env:Sender
SOAP
fault with a subcode of enc:MissingID
if the message violates the constraints on id
and ref
attribute information
items (see 3.1.5.3 Constraints on id and ref attribute information
items).
MAY generate an env:Sender
SOAP fault with a
subcode of enc:UntypedValue
if the type name
property of an encoded graph node is unspecified.
One of the design goals of SOAP is to facilitate the exchange of messages that map conveniently to definitions and invocations of method and procedure calls in commonly used programming languages. For that purpose, this section defines a uniform representation of RPC requests and responses. It does not define actual mappings to any particular programming language. The representation is entirely platform independent and considerable effort has been made to encourage usage that is consistent with the Web in general.
As mentioned in section 2. SOAP Data Model, use and implementation of the SOAP RPC Representation is OPTIONAL.
The SOAP encodingStyle attribute information item (see [1] SOAP encodingStyle Attribute) is used to indicate the encoding style of the RPC representation. The encoding thus specified needs to support "struct" and "array" compound value constructs defined in 2.3 Values. The encoding style defined in 3. SOAP Encoding supports such constructs and is therefore suitable for use with the SOAP RPC Representation.
This SOAP RPC Representation is not predicated on any SOAP protocol binding. When SOAP is bound to HTTP, an RPC invocation maps naturally to an HTTP request and an RPC response maps to an HTTP response. (see 7. SOAP HTTP Binding). However, the SOAP RPC Representation is not limited only to the SOAP HTTP Binding.
To invoke an RPC, the following information is needed:
The binding-specific address of the target SOAP node
A procedure or method name
The identities and values of any arguments to be passed to the procedure or method. Arguments used to identify Web resources SHOULD be distinguished from those representing data or control information (see 4.1.1 Identification of RPC Resources.)
The Web method and the MEP to be used (4.1.2 Distinguishing Resource Retrievals from other RPCs and 6.4 Web Method Specification Feature.)
Optional header data
SOAP relies on a SOAP feature (see SOAP Protocol Binding Framework) to provide a mechanism for carrying the URI of the target SOAP node. For HTTP the request URI indicates the resource against which the invocation is being made. Other than requiring it to be a valid URI, SOAP places no restriction on the form of an identifier (see RFC2396 [6] for more information on URIs). The section 4.1.1 Identification of RPC Resources further discusses the use of URI's for identifying RPC resources.
The SOAP RPC Representation employs the 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern. Use of the SOAP RPC Representation with other MEPs MAY be possible, but is beyond the scope of this specification.
The following guidelines SHOULD be followed when deploying SOAP RPC applications on the World Wide Web:
The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to
procedures, or in the names of those procedures. For example, the call:
"updateQuantityInStock(PartNumber="123", NewQuantity="200")
suggests that the resource to be
updated is the QuantityInStock for PartNumber "123".
Accordingly, when mapping to
or from a programming language method or procedure call, any arguments that serve to identify resources
(such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed.
When mapping to or from a programming language method or procedure call, the name of which
identifies or qualifies the identification of a resource (such as QuantityInStock above), such naming or
qualification should when practical be represented in the URI to which the SOAP message is addressed.
No standard means of representation of arguments or method names is provided by this specification.
Note:
Conventions for specific URI encodings of procedure names and arguments, as well as for controlling the inclusion of such arguments in the SOAP RPC body could be established in conjunction with the development of Web Service interface description languages, could be developed when SOAP is bound to particular programming languages, or could be established on an application or procedure-specific basis.
The World Wide Web depends on mechanisms that optimize commonly performed information retrieval tasks. Specifically, protocols such as HTTP [2] provide a GET method which is used to perform safe retrievals, I.e. to perform retrievals that are idempotent, free of side effects, and for which security considerations do not preclude the use of cached results or URI-based resource identification.
Certain procedure or method calls represent requests for information retrieval. For example, the call:
"getQuantityInStock(PartNumber="123")
might be used to retrieve the quantity established in
the example above. The following conventions can be employed to implement SOAP retrievals and other
RPC's on the Web:
The conventions described in 4.1.1 Identification of RPC Resources are used to identify the resource with a URI.
In cases where all the arguments have been represented in the URI, no SOAP header blocks are to be transmitted, and the operation is a safe retrieval, the 6.4 Web Method Specification Feature feature and the 6.3 SOAP Response Message Exchange Pattern MEP is used. Accordingly, no SOAP envelope is transmitted for the request, and the "webmeth:Method" property is set to GET. The results of the retrieval are a SOAP RPC response as described in 4.2.2 RPC Response
In cases where the operation to be performed is not a retrieval, when SOAP headers are to be transmitted (a digital signature, for example), or when a retrieval is not safe, the 6.4 Web Method Specification Feature feature and the 6.2 Request-Response Message Exchange Pattern MEP is used. The request envelope is encoded as described in 4.2.1 RPC Invocation, and the results are as described in 4.2.2 RPC Response. The "webmeth:Method" property is set to POST.
The SOAP RPC Representation does not define any other value for the "webmeth:Method".
RPC invocations (except for safe retrievals: see 4.1.2 Distinguishing Resource Retrievals from other RPCs) 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 where parameter access is by name or as an array where parameter access is by position.
The invocation is represented by a single struct or array containing an outbound edge for each [in] or [in/out] parameter. The struct or array is named identically to the procedure or method name (see A. Mapping Application Defined Names to XML Names).
Each outbound edge either has a label corresponding to the name of the parameter (see A. Mapping Application Defined Names to XML Names) or a position corresponding to the position of the parameter.
Applications MAY process invocations with missing parameters but also MAY fail to process the invocation and return a fault.
An RPC response is modeled as a struct where parameter access is by name or as an array where parameter access is by position.
The response is represented by a single struct or array containing an outbound edge for the return value and each [out] or [in/out] parameter.
If the response is represented by a
struct, then each parameter is represented by an outbound edge
with a label corresponding to the name of the parameter (see
A. Mapping Application Defined Names to XML Names). A non-void return value is
represented in the struct by an outbound edge that may be
given any unique label. The QName of the label of the edge
representing the return value is given by a separate outbound
edge with a local name of result
and the namespace
name "http://www.w3.org/2001/12/soap-rpc". This
result outbound edge MUST be present and hold the qname of the
edge containing the return value within any struct response if
the return value of the procedure is non-void. This result
outbound edge MUST NOT be present if the return value of the
procedure is void.
If the response is represented by an array, each outbound edge has a label corresponding to the position of the parameter. A return value MUST be present if the return value of the procedure is non-void. If present, the return value MUST be represented as the first edge of the array with parameters following. If no return value is present, then parameters begin with the first outbound edge of the array.
Invocation faults are handled according to the rules in 4.4 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.
An RPC response MUST NOT contain both a result and a fault, because a result indicates success and a fault indicates failure.
When using SOAP encoding (see 3. SOAP Encoding) in
conjunction with the RPC convention described here, the SOAP
Body
MUST contain only a single child element
information item, that child being the serialized RPC
invocation or response struct or array. I.e. when using the
SOAP encoding for serializing
RPC invocations and responses, the encoding is constrained
to produce a single tree of element information
items.
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in a SOAP envelope carrying an RPC invocation or response. Such additional information MUST be expressed as SOAP header blocks.
The SOAP RPC Representation introduces additional SOAP fault
subcode values to be used in conjunction with the fault codes
described in [1] SOAP Fault Codes. The
namespace name for these SOAP fault subcode values is
"http://www.w3.org/2001/12/soap-rpc" and the
namespace prefix rpc:
is used in this section to
indicate association with this namespace. A schema document for
this namespace can be found at http://www.w3.org/2001/12/soap-rpc
.
Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):
A fault with a Value
of
"env:Receiver" for Code
SHOULD
be generated when the receiver cannot handle the message
because of some temporary condition, e.g. when it is out of
memory.
A fault with a Value
of
"env:DataEncodingUnknown" for
Code
SHOULD be generated when the arguments
are encoded in a data encoding unknown to the
receiver.
A fault with a Value
of
"env:Sender" for Code
and a
Value
of "rpc:ProcedureNotPresent"
for Subcode
MAY be generated when the receiver
does not support the procedure or method specified.
A fault with a Value
of
"env:Sender" for Code
and a
Value
of "rpc:BadArguments" for
Subcode
MUST be generated when the receiver
cannot parse the arguments or when there is a mismatch
between what the receiver expects and what the sender has
sent.
Other faults arising in an extension or from the application SHOULD be generated as described in [1] SOAP Fault Codes.
In all cases the values of the Detail
and
Reason
element information items
are implementation defined. Details of their use MAY be specified by an
external document.
Note:
Senders might receive different faults from those listed above in response to an RPC invocation if the receiver does support the (optional) RPC convention described here.
This section describes a convention describing Features (including MEPs) and Bindings in terms of properties and property values. The convention is sufficient to describe the distributed states of Feature and Binding specifications as mandated by the Binding Framework (see [1] SOAP Protocol Binding Framework) and it is used to describe a Request-Response MEP 6.2 Request-Response Message Exchange Pattern and the SOAP HTTP Binding 7. SOAP HTTP Binding elsewhere in this document. Along with the convention itself, an informal model is defined that describes how properties propagate through a SOAP system. Note that this model is intended to be illustrative only, and is not meant to imply any constraints on the structure or layering of any particular SOAP implementation.
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. As shown in the figure below, we make the distinction between per message-exchange and more widely scoped properties by assigning them to different containers called Message Exchange Context and Environment respectively. All properties, regardless of their scope, are shared by SOAP and a particular Binding.
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.
A feature may be expressed through multiple properties and a single property may enable more than one feature. For example, the properties called User ID and Password may be used to enable a feature called Authentication. As a second example, a single property called Message ID could be used to enable one feature called Transaction and a second feature called Message Correlation.
Table 2 describes the properties (in accordance with the property naming conventions defined in this document) that support the description of message exchange patterns (MEPs). Other properties may be involved in the specification of particular MEPs, but the properties in this table are generally applicable to all MEPs.
Property Name | Property Description |
---|---|
context:ExchangePatternName |
A URI that names the MEP in operation. |
context:FailureReason |
A URI value that denotes a pattern specific, binding independent reason for the failure of a message exchange. Underlying protocol binding specifications may define properties to convey more binding specific details of the failure. |
This section defines the message exchange pattern (MEP) called "Request-Response". The description is an abstract presentation of the operation of this MEP. It is not intended to describe a real implementation or to suggest how a real implementation should be structured.
This message exchange pattern is identified by the URI:
"http://www.w3.org/2001/12/soap/mep/request-response/"
Protocol binding specifications may use this URI to declare their support for the MEP and its associated semantics.
The Request-Response MEP 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.
In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is first transferred from the requesting SOAP node to the responding SOAP node. Following the successful processing of the request message by the responding SOAP node, a response message is transferred from the responding SOAP node to the requesting SOAP node.
Abnormal operation during a Request-Response message exchange may be caused by 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 might be silent at either or both of the requesting and responding SOAP nodes involved. Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.
The scope of a Request-Response MEP is limited to the exchange of a request message and a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.
The Request-Response MEP defines a set of properties described in Table 3.
Property Name | Property Description |
---|---|
reqres:Role |
A URI denoting the pattern specific role of the local SOAP node participating in the message exchange. |
reqres:State |
A URI denoting the current state of the message exchange. This value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange. |
reqres:OutboundMessage |
An abstract structure that represents the current outbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope. |
reqres:InboundMessage |
An abstract structure that represents the current inbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope. |
reqres:ImmediateDestination |
A URI denoting the immediate destination of an outbound message. |
reqres:ImmediateSender |
A URI denoting the immediate sender of an inbound message. |
To initiate a message exchange conforming to the Request-Response MEP, the requesting SOAP node instantiates a local message exchange context. Table 4 describes how the context is initialized.
Property Name | Property Value |
---|---|
context:ExchangePatternName |
"http://www.w3.org/2001/12/soap/mep/request-response/" |
context:FailureReason |
None |
reqres:Role |
RequestingSOAPNode |
reqres:State |
Init |
reqres:OutboundMessage |
An abstraction of the request message |
reqres:ImmediateDestination |
An identifier (URI) that denotes the responding SOAP node |
There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.
Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.
The diagram below shows the logical state transitions at
the requesting and responding SOAP nodes during the lifetime
of the message exchange. At each SOAP node, the local binding
instance updates (logically) the value of the
reqres:State
property to
reflect the current state of the message exchange. The state names
are relative URIs, relative to a Base URI value carried in
the reqres:Role
property of the local
message exchange context.
When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. Table 5 describes the properties that the binding initializes as part of the context's instantiation.
Property Name | Property Value |
---|---|
context:ExchangePatternName |
"http://www.w3.org/2001/12/soap/mep/request-response/" Initialized as early as possible during the life cycle of the message exchange. |
context:FailureReason |
None |
reqres:Role |
RespondingSOAPNode Initialized as early as possible during the life cycle the message exchange. |
reqres:State |
Init |
When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. Table 6 and Table 7 describe these updates for the requesting and the responding SOAP nodes, respectively.
CurrentState | Transition Condition | NextState | Action |
---|---|---|---|
Init | Unconditional | Requesting | Initiate transmission of request message
abstracted in
reqres:OutboundMessage . |
Requesting | Message transmission failure | Fail | Set
context:FailureReason to
"transmissionFailure" |
Start receiving response message | Sending+Receiving | Set
reqres:ImmediateSender to denote the sender of the response message (may differ from the values in reqres:ImmediateDestination ).
Start making an abstraction of the response message available in reqres:InboundMessgae . |
|
Sending+Receiving | Message exchange failure | Fail | Set
context:FailureReason to
"exchangeFailure" |
Completed sending request message. Completed receiving response message. | Success |
CurrentState | Transition Condition | NextState | Action |
---|---|---|---|
Init | Start receiving request message | Receiving | Set
reqres:ImmediateSender to denote the sender of the request message (if determinable).
Start making an abstraction of the request message available in reqres:InboundMessgae .
Pass control of message exchange context to SOAP processor. |
Receiving | Message reception failure | Fail | Set
context:FailureReason to
"receptionFailure". |
Start of response message available in reqres:OutboundMessage |
Receiving+Sending | Initiate transmission of response message abstracted in reqres:OutboundMessage . |
|
Receiving+Sending | Message exchange failure | Fail | Set context:FailureReason to
"exchangeFailure". |
Completed receiving request message. Completed sending response message. | Success |
Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:
All the rules in [1] Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.
When using streaming SOAP bindings, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted.
Note:
Depending on the implementation used and the size of the messages involved, this rule MAY require that SOAP applications stream application-level response processing in parallel with request generation.
A requesting SOAP node MAY enter the Fail
state,
and thus abort transmission of the outbound SOAP request,
based on information contained in an incoming streamed SOAP
response.
During the operation of the Request-Response MEP, the participating SOAP nodes may generate SOAP faults.
If a SOAP fault is generated by the responding SOAP node
while it is in the Receiving state, the SOAP
fault is made available in reqres:OutboundMessage
and the
state machine transitions to the Receiving+Sending
state.
This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see Table 6).
This section defines the message exchange pattern (MEP) called "SOAP Response". The description is an abstract presentation of the operation of this MEP. It is not intended to describe a real implementation or to suggest how a real implementation should be structured.
This message exchange pattern is identified by the URI:
"http://www.w3.org/2001/12/soap/mep/soap-response/"
Protocol binding specifications may use this URI to declare their support for the MEP and its associated semantics.
The SOAP Response MEP defines a pattern for the exchange of a non-SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of errors or faults, this message exchange pattern consists of two messages, only one of which is a SOAP envelope:
A request transmitted in a binding-specific manner that does not include a SOAP envelope and hence does not involve any SOAP processing by the receiving SOAP node.
A response message which contains a SOAP envelope. The MEP is completed by the processing of the SOAP envelope following the rules of the SOAP processing model (see [ref. to chapter 2]).
Abnormal operation during a SOAP Response message exchange may be caused by a failure to transfer the request message or the response message. Such failures MAY be silent at either or both of the requesting and responding SOAP nodes involved. Also, during abnormal operation each SOAP node involved in the message exchange MAY differ in its determination of the successful completion of the message exchange (see also section 6.3.4 Fault Handling).
The scope of a SOAP Response MEP is limited to the request for an exchange of a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.
Note:
This MEP cannot be used in conjunction with features expressed as SOAP header blocks in the request because there is no SOAP envelope in which to carry them.
The SOAP Response MEP defines a set of properties described in Table 8.
Property Name | Property Description | ||||
---|---|---|---|---|---|
reqres:Role
|
A URI denoting the pattern specific role of the local SOAP node participating in the message exchange. | ||||
reqres:State
|
A URI denoting the current state of the message exchange. This value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange. | ||||
reqres:OutboundMessage
|
An abstract structure that represents the current outbound message in the message exchange. This abstracts both SOAP Envelope Infoset (which MAY be null) and any other information structures that are transferred along with the envelope. | ||||
reqres:InboundMessage
|
An abstract structure that represents the current
inbound message in the message exchange. This
abstracts both SOAP Envelope Infoset (which MAY be null) and any other
information structures that are transferred along
with the envelope.
|
||||
reqres:ImmediateDestination
|
A URI denoting the immediate destination of an outbound message. | ||||
reqres:ImmediateSender
|
A URI denoting the immediate sender of an inbound message. |
To initiate a message exchange conforming to the SOAP Response MEP, the requesting SOAP node instantiates a local message exchange context. Table 9 describes how the context is initialized.
Property Name | Property Value |
---|---|
context:ExchangePatternName
|
"http://www.w3.org/2001/12/soap/mep/soap-response/" |
context:FailureReason
|
None |
reqres:Role
|
RequestingSOAPNode |
reqres:State
|
Init |
reqres:OutboundMessage
|
An abstraction of the request message that does not include a SOAP envelope infoset. |
reqres:ImmediateDestination
|
An identifier (URI) that denotes the responding SOAP node |
There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.
Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.
The diagram below shows the logical state transitions at
the requesting and responding SOAP nodes during the lifetime
of the message exchange. At each SOAP node, the local binding
instance updates (logically) the value of the
reqres:State
property to
reflect the current state of the message exchange. The state names
are relative URIs, relative to a Base URI value carried in
the reqres:Role
property of the local
message exchange context.
When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. Table 10 describes the properties that the binding initializes as part of the context's instantiation.
Property Name | Property Value |
---|---|
context:ExchangePatternName
|
"http://www.w3.org/2001/12/soap/mep/soap-response/" Initialized as early as possible during the life cycle of the message exchange. |
context:FailureReason
|
None |
reqres:Role
|
RespondingSOAPNode Initialized as early as possible during the life cycle the message exchange. |
reqres:State
|
Init |
When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. Table 11 and Table 12 describe these updates for the requesting and the responding SOAP nodes, respectively.
CurrentState | Transition Condition | NextState | Action |
---|---|---|---|
Init | Unconditional | Requesting | ??? |
Requesting | Message transmission failure | Fail | Set
context:FailureReason to
"transmissionFailure"
|
Start receiving response message | Sending+Receiving | Set
reqres:ImmediateSender to denote the sender of the response message (may differ from the values in reqres:ImmediateDestination ).
Start making an abstraction of the response message available in reqres:InboundMessgae . |
|
Sending+Receiving | Message exchange failure | Fail | Set
context:FailureReason to
"exchangeFailure"
|
Completed receiving response message. | Success |
CurrentState | Transition Condition | NextState | Action |
---|---|---|---|
Init | Start receiving request message | Receiving | Set
reqres:ImmediateSender to denote the sender of the request message (if determinable).
making an abstraction of the request message available in reqres:InboundMessgae .
Pass control of message exchange context to SOAP processor. |
Receiving | Message reception failure | Fail | Set
context:FailureReason to
"receptionFailure". |
Start of response message available in reqres:OutboundMessage
|
Receiving+Sending | Initiate transmission of response message abstracted in reqres:OutboundMessage . |
|
Receiving+Sending | Message exchange failure | Fail | Set context:FailureReason to
"exchangeFailure". |
Completed sending response message. | Success |
Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:
All the rules in [1] Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.
When using streaming SOAP bindings, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted.
Note:
Depending on the implementation used and the size of the messages involved, this rule MAY require that SOAP applications stream application-level response processing in parallel with request generation.
A requesting SOAP node MAY enter the Fail
state,
and thus abort transmission of the outbound SOAP request,
based on information contained in an incoming streamed SOAP
response.
During the operation of the SOAP Response MEP, the participating SOAP nodes may generate SOAP faults.
This MEP makes no claims about the disposition of SOAP faults generated by the responding SOAP node.
A responding SOAP node MAY express fault information as a result of processing the request in the form of a SOAP fault. This can for example be used to express information that might be useful to a receiving SOAP node. If a SOAP fault is generated by the responding SOAP node
while it is in the Receiving state, the SOAP
fault is made available in reqres:OutboundMessage
and the
state machine transitions to the Receiving+Sending
state.
This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see Table 11).
This section defines the "Web Method Specification Feature".
This Web Method Specification Feature is identified by the URI:
"http://www.w3.org/2001/12/soap/features/web-method/"
Protocol binding specifications may use this URI to declare their support for the this feature and its associated semantics.
Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE. These methods are formally defined in the HTTP specification [2], but other underlying protocols also support them. Bindings to HTTP or such other protocols SHOULD use the Web Method Specification Feature to give applications control over the Web methods to be used when sending a SOAP message.
Bindings supporting this feature SHOULD use the appropriate embodiment of that method as provided by the underlying protocol; for example, the HTTP binding provided with this specification represents the GET Web method as an HTTP GET request, and the POST method as an HTTP POST request (see 7. SOAP HTTP Binding). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.
The SOAP Web Method Specification Feature MAY be implemented by bindings to underlying transports that have no preferred embodiment of particular Web methods (E.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature.
The Web Method Feature defines a single property, which is described in Table 13.
Property Name | Property Description |
---|---|
webmeth:Method
|
One of GET, POST, PUT, DELETE (or others which may subsequently be added to the repertoire of Web methods.) |
This specification provides for the use of the Web Method Feature in conjunction with the 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern message exchange patterns. This feature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.
A node sending a request message MUST provide a value for the webmeth:Method property. A protocol binding supporting this feature SHOULD set the value of the webmeth:Method property at the receiving node to match that provided by the sender; the means of transmission for the method property is binding-specific. A responding node SHOULD respond in a manner consistent with the Method requested (e.g. a GET should result in retrieval of a representation of the identified resource) or SHOULD fault in an application-specific manner if the Web method cannot be supported.
Editorial note | |
Should this feature define a standard fault to be used in this case? If so, we can map it to the appropriate HTTP status code, I would think. [NRM 6/4/2002] |
Applications SHOULD use GET as the value of webmeth:Method
in conjunction with the 6.3 SOAP Response Message Exchange Pattern to support information retrievals which are safe, and for
which no parameters other than a URI are required; I.e.
when performing retrievals which are idempotent, known to be free of side effects, for which no SOAP
request headers are required, and for which
security considerations do not conflict with the possibility that cached results would be used. Except
in unusual circumstances, other operations SHOULD be performed using POST in conjunction with the 6.2 Request-Response Message Exchange Pattern. Other methods SHOULD not
in general be used. For example, use of PUT
would suggest storing the SOAP envelope Infoset as the created resource, as opposed to processing
in the manner required by the SOAP
processing model.
The SOAP HTTP Binding provides a binding of SOAP to HTTP. The binding conforms to the SOAP Protocol Binding Framework (see [1] SOAP Protocol Binding Framework). It uses abstract binding properties as a descriptive tool for defining the functionality of certain features.
Certain optional features provided by this binding depend on capabilities provided by HTTP Version 1.1, for example content negotiation. Implementations SHOULD thus use HTTP 1.1 [2] (or later compatible versions that share the same major version number). Implementations MAY also be deployed using HTTP Version 1.0, although in this case certain optional binding features may not be provided.
Note:
SOAP HTTP Binding implementations need to account for the fact that HTTP 1.0 intermediaries may alter the representation of SOAP messages, even in situations where both the initial SOAP sender and ultimate SOAP receiver use HTTP 1.1.
The SOAP Protocol Binding Framework (see [1] SOAP Protocol Binding Framework), the Message Exchange Pattern Specifications (see [1] SOAP Message Exchange Patterns) and Feature Specifications (see 5. A Convention for Describing Features and Bindings) each describe the properties they expect to be present in a message exchange context when control of that context passes between a local SOAP node and a binding instance.
Properties are named with XML qualified names. Property values are determined by the Schema type of the property, as defined in the specification which introduces the property.
Conforming implementations of this binding:
MUST be capable of sending and receiving messages serialized using media type "application/soap+xml" whose proper use and parameters are described in [12].
MAY send requests and responses using other media types providing that such media types provide for at least the transfer of SOAP XML Infoset.
MAY, when sending requests, provide an HTTP Accept header. This header:
SHOULD indicate an ability to accept at minimum "application/soap+xml".
MAY additionally indicate willingness to accept other media types that satisfy 2 above.
Note:
The SOAP HTTP Binding is optional and SOAP nodes are NOT required to implement it. The SOAP version 1.2 specification does not preclude specifications of other bindings to HTTP or bindings to other protocols. A SOAP node that correctly and completely implements the SOAP HTTP Binding may to be said to "conform to the SOAP 1.2 HTTP Binding."
Note:
Particularly when used with the 6.3 SOAP Response Message Exchange Pattern, the HTTP messages may be indistinguishable from those produced by non-SOAP implementations performing similar operations. Accordingly, some degree of interoperation may be possible between SOAP nodes and other HTTP implementations when using this binding. For example, a conventional Web server (I.e. one not written specifically to conform to this specification) may be used to respond to SOAP-initiated HTTP GET's with representations of content-type application/soap+xml. Such interoperation is not a normative feature of this recommendation.
The binding is identified with the URI:
"http://www.w3.org/2001/12/soap/bindings/HTTP/"
An implementation of the SOAP HTTP Binding MUST support the following message exchange patterns (MEPs):
"http://www.w3.org/2001/12/soap/mep/request-response/" (see 6.2 Request-Response Message Exchange Pattern)
"http://www.w3.org/2001/12/soap/mep/soap-response/" (see 6.3 SOAP Response Message Exchange Pattern)
An implementation of the SOAP HTTP Binding MUST support the following feature:
"http://www.w3.org/2001/12/soap/features/web-method/" (see 6.4 Web Method Specification Feature)
For binding instances conforming to this specification:
A SOAP node instantiated at an HTTP client may assume the role (i.e. the
property reqres:Role
) of
"RequestingSOAPNode".
A SOAP node instantiated at an HTTP server may assume the role (ie.
the property reqres:Role
) of
"RespondingSOAPNode".
The remainder of this section describes the MEP state machine
and its relation to the HTTP protocol. In the state tables below,
the states are defined as values of the property reqres:State
(see 6.2 Request-Response Message Exchange Pattern), and are of type reqres:StateType
(an enumeration over xs:string
).
Failure reasons that are specified in the tables represent values of the property
context:FailureReason
and their values are XML qualified names.
If an implementation enters the "Fail" state,
the context:FailureReason
property will contain the value specified for the particular transition.
The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with both 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern (differences are indicated as necessary.) This binding supports streaming and, as a result, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted (see 6.2.3 State Machine Description). The following subsections describe each state in detail.
Table 14 and Table 15 describe the requesting SOAP node's Init state and the values of the HTTP request fields.
Statename | Init | ||
---|---|---|---|
Description | Formulate and start sending HTTP request (see next table) | ||
Preconditions | See 6.2.3 State Machine Description and 6.4.3 Web Method Feature State Machine | ||
Postconditions | None | ||
Transitions | Event/Condition | NextState | Failure Reason |
Unconditional | Requesting | N/A |
Field | Value |
---|---|
HTTP Method | According to the webmeth:Method property (typically POST or GET). |
Request URI | The value of the URI carried in the
reqres:ImmediateDestination property of the
message exchange context. |
Content-Type header | The media type of the request entity body (if present) otherwise, omitted (see 7.1 Introduction for a description of permissible media types). If the SOAP envelope infoset in the reqres:OutboundMessage property is null, then the Content-Type header field MAY be omitted. |
Accept header (optional) | List of media types that are acceptable in response to the request message. |
Additional Headers | Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. |
HTTP entity body | SOAP message serialized according to the rules for carrying SOAP messages in the media type given by the Content-Type header. Rules for carrying SOAP messages in media type "application/soap+xml" are given in [12]. If the SOAP envelope infoset in the reqres:OutboundMessage property is null, then no serialization of the SOAP message is required and the entity body MAY be omitted. |
Table 16 describes the requesting SOAP node's Requesting state.
Statename | Requesting | ||
---|---|---|---|
Description | Sending request message and waiting for start of response message. | ||
Preconditions | None | ||
Postconditions |
| ||
Transitions | Event/Condition | NextState | Failure Reason |
HTTP Response Status Line and HTTP Headers received | (see status code table below) | (see status code table below) | |
Message exchange failure | Fail | "fail:transmissionFailure" |
Table 17 details the transitions that take place when a requesting SOAP node reveives an HTTP status line and response headers.
Status Code | Reason phrase | Significance/Action | NextState | |
---|---|---|---|---|
2xx | Successful | |||
200 | OK |
The response message follows in HTTP response entity body.
Start making an abstraction of the response message available in
|
Sending+Receiving | |
202 | Accepted | The request message has
been received and processed. The entity body of the HTTP response MAY
contain a response message. Start making an abstraction of the response message available in |
Sending+Receiving | |
204 | No Content |
The request message has been received and processed. The HTTP response MUST NOT contain an entity body. The message exchange is regarded as having completed successfully. |
Sending+Receiving | |
Instantiated Property | Value | |||
reqres:InboundMessage |
"Empty" SOAP Envelope. | |||
3xx | Redirection | The requested resource has
moved and the HTTP request SHOULD be retried using the URI carried in the
associated Location header as the new value for the
|
Init | |
4xx | Client Error | |||
400 | Bad Request |
Indicates a problem with the received HTTP request message. The problem may bea malformed XML in the request message envelope. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded as having completed unsuccessfully. |
Fail | |
Instantiated Property | Value | |||
context:FailureReason |
"fail:BadRequest" | |||
401 | Unauthorized | Indicates that the HTTP request requires authorization. |
Requesting | |
Instantiated Property | Value | |||
context:FailureReason |
"fail:AuthenticationFailure" | |||
If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the message exchange is regarded as having completed unsuccessfully. |
Fail | |||
Instantiated Property | Value | |||
context:FailureReason |
"fail:AuthenticationFailure" | |||
405 | Method not allowed |
Indicates that the peer HTTP server does not support the requested HTTP method at the given request URI. The message exchange is regarded as having completed unsuccessfully. |
Fail | |
Instantiated Property | Value | |||
context:FailureReason |
"fail:BindingMismatch" | |||
415 | Unsupported Media Type |
Indicates that the peer HTTP server does not support Content-type used to encode the request message. The message exchange is regarded as having completed unsuccessfully. |
Fail | |
Instantiated Property | Value | |||
context:FailureReason |
"fail:BindingMismatch" | |||
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. |
Sending+Receiving | |
Instantiated Property | Value | |||
context:FailureReason |
fail:ServerFault |
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 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 and 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.
Table 18 describes the requesting SOAP node's Sending+Receiving state.
Statename | Sending+Receiving | ||
---|---|---|---|
Description | Completing the transmission of a request message and the reception of a response message. The response message is assumed to be a SOAP envelope serialized according the rules for carrying SOAP messages in the media type given in the Content-Type header. | ||
Preconditions | None | ||
Postconditions | On transitions to
Success, the property
reqres:InboundMessage is instantiated with the Infoset representation
of the serialized envelope in the response body. |
||
Transitions | Event/Condition | NextState | Failure Reason |
Request message transmission and response message reception completed and a well formed response message received | Success | N/A | |
Reception Failure (broken connections etc.) | Fail | "fail:ReceptionFailure" | |
Packaging Failure (including mismatched Content-Type) | Fail | "fail:PackagingFailure" | |
Malformed response message, e.g. malformed XML, message contains a DTD, invalid SOAP Envelope | Fail | "fail:BadResponseMessage" |
The response MAY be of content type other
than application/soap+xml.
Such a result is particularly likely when a SOAP request sent with a webmeth:Method
of GET
is directed (intentionally or otherwise) to a non-SOAP HTTP server.
Such usage is considered non-normative, and accordingly is not modeled in the state machine above.
Interpretation of such responses is at the discretion of the receiver.
The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with both 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern (differences are indicated as necessary). The following subsections describe each state in detail.
Table 19 and Table 20 describe the responding SOAP node's Init state and the faults it generates respectively.
Statename | Init | ||
---|---|---|---|
Description | Waiting for the start of an inbound request message | ||
Preconditions | Reception of an HTTP request at
an HTTP endpoint bound to the local SOAP node, see 6.2.3 State Machine Description. Additionally,
the webmeth:Method property is set to match the HTTP Method of the received request. | ||
Postconditions | See below | ||
Transitions | Event/Condition | NextState | Action |
Receive the beginning of an HTTP POST request containing well formed request message. | Receiving |
This change of state represents a transfer of control of the inbound message exchange context to the local SOAP node. | |
Receive HTTP POST request containing malformed request message | Fail | The message is considered to have been intended for the local SOAP node. It is considered to be malformed becuase it is not well formed XML, contains a serialized DTD, and/or contains an invalid SOAP envelope. The local SOAP node generates a SOAP fault message in accordance with the following table and sends it in the corresponding HTTP response message, accompanied by a status code value appropriate to the particular fault. The message exchange context may be destroyed or considered not to have been created. | |
Receive HTTP GET request containing well formed request message | Receiving |
This change of state represents a transfer of control of the inbound message exchange context to the local SOAP node. |
Problem with Message | HTTP Status Code | HTTP Reason Phrase (informative) | SOAP Fault |
---|---|---|---|
Malformed Request Message | 400 | Bad request | None |
HTTP Method is neither POST nor GET | 405 | Method Not Allowed | None |
Unsupported message encapsulation method | 415 | Unsupported Media | None |
Table 21 describes the responding SOAP node's Receiving state.
Statename | Receiving | ||
---|---|---|---|
Description | Continue receiving the request message and wait for the start of a response message to be available in the message exchange context. | ||
Preconditions | None | ||
Postconditions | See below | ||
Transitions | Event/Condition | NextState | Action or Failure Reason |
The start of an abstraction of a response message
becomes available in reqres:OutboundMessage indicating
that the local SOAP processor has generating a response
message. |
Receiving+Sending | Formulate and start sending the response message, reqres:OutboundMessage may contain a SOAP fault. | |
Message reception failure | Fail | "fail:receptionFailure" |
Table 22 and Table 23 describe the HTTP response headers generated by the responding SOAP node.
Header | Value |
---|---|
Status line | Set according to the next table |
Content-Type header | The media type of the response body, see 7.1 Introduction for a description of permissible media types. |
Additional Headers | Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. |
HTTP Entity Body | SOAP message serialized according to the rules for carrying SOAP
messages in the media type given by the Content-Type header. Rules
for carrying SOAP messages in application/soap+xml are
given in [12]. |
SOAP Fault | HTTP Status Code | HTTP Reason Phrase (informative) |
---|---|---|
env:VersionMismatch | 500 | Internal server error |
env:MustUnderstand | 500 | Internal server error |
env:Sender | 400 | Bad request |
env:Receiver | 500 | Internal server error |
Table 24 describes the responding SOAP node's Responding state.
Statename | Receiving+Sending | ||
---|---|---|---|
Description | Completing request message reception and response message transmission. | ||
Preconditions | None | ||
Postconditions | See below | ||
Transitions | Event/Condition | NextState | Action or Failure Reason |
Response message reception and request message transmission complete. | Success | ||
Message exchange failure | Fail | "fail:exchangeFailure". |
The SOAP HTTP Binding (see 7. SOAP HTTP Binding) can be considered as an extension of the HTTP application protocol. As such, all of the security considerations identified and described in section 15 of the HTTP specification[2] apply to the SOAP HTTP Binding in addition to those described in [1] "Security Considerations". Implementors of the SOAP HTTP Binding should carefully review this material.
[4] | 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: 4] 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]
As noted in 3.1.4 Computing the Type Name property SOAP graph nodes are labeled with type names, but validation of encoded SOAP messages MUST NOT be required by conforming processors. These sections describe techniques that can be used when validation with W3C XML schemas is desired for use by SOAP applications. Any errors or faults resulting from such validation are beyond those covered by the normative recommendation; from the perspective of SOAP, such faults are considered to be application-level failures.
Although W3C XML schemas are conventionally exchanged in the form of schema documents (see [4]), the schema recommendation is build on an abstract definition of schemas, to which all processors need to conform. The schema recommendation provides that all such schemas include definitions for a core set of built in types, such as integers, dates, and so on (see [4], Built-in Simple Type Definition). Thus, it is possible to discuss validation of a SOAP message against such a minimal schema, which is the one that would result from providing no additional definitions or declarations (i.e. no schema document) to a schema processor.
The minimal schema provides that any well formed XML document will validate, except that where an xsi:type is provided, the type named must be built in, and the corresponding element must be valid per that type. Thus, validation of a SOAP 1.2 message using a minimal schema approximates the behavior of the built-in types of SOAP 1.1.
Validation against the minimal schema (see B.1 Validating using the minimum schema) will not succed where encoded graph nodes have multiple inbound edges. The SOAP Encoding of such graphs MAY be validated against the SOAP Encoding schema. In order for the encoding to validate, edge labels, and hence element namespace names and local names, need to match those defined in the SOAP Encoding schema. Validation of the encoded graph against the SOAP Encoding schema would result in the type name property of the nodes in the graph being assigned the relevant type name.
POST /StockQuote HTTP/1.1 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>
POST /StockQuote HTTP/1.1 Host: www.example.org 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: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 <?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: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" xmlns:rpc="http://www.w3.org/2001/12/soap-rpc"> <rpc:result>Price</rpc:result> <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:GetLastTradePriceDetailedResponse env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" xmlns:rpc="http://www.w3.org/2001/12/soap-rpc" > <rpc:result>Price</rpc:result> <Price>34.5</Price> <DayVolume>10000</DayVolume> </m:GetLastTradePriceDetailedResponse> </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" > <env:Code> <env:Value>env:Server</env:Value> <env:Subcode> <env:Value>e:OutOfMemory</env:Value> </env:Subcode> </env:Code> <env:Reason>Server Error</env:Reason> <env:Detail> <e:myfaultdetails> <message>My application didn't work</message> </e:myfaultdetails> </env: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.), Colleen Evans (Progress Software), 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 |
---|---|---|
20020605 | HFN | Added comments on GETF resolution from JJM, MJH, CF, and HFN. |
20020605 | HFN | Incorporated resolution from GETF. |
20020527 | MJH | Removed quotes around lexical value. |
20020527 | MJH | Removed a couple of instances of lower case should and must. |
20020527 | MJH | Added reference to SOAP part 0. |
20020517 | JJM | Fixed some typos. |
20020517 | JJM | HTTP versioning wordsmithing. |
20020516 | MJH | Worked on examples to show rpc:result usage. |
20020516 | MJH | Added issue 195 resolution. |
20020516 | MJH | Added ProcedureNotPresent resolution. |
20020516 | MJH | Added HTTP versioning resolution. |
20020515 | MJH | Readability update to description of data model. |
20020509 | MJH | Added RPC root resolution. |
20020509 | MJH | Added bib refs to spec cross refs. Fixed some xspecrefs that were empty and so didn't show up in the html. Removed pt1 section numbers from cross references since these are not autogenerated and would be a maintenance headache. |
20020506 | JJM | Removed double-spaces. |
20020506 | JJM | Divided the long list in "SOAP RPC and Body" into two separate lists. |
20020506 | JJM | Fixed a few typos. |
20020503 | HFN | Changed "faulthint" to "faultreason". |
20020503 | HFN | Made the order of properties listed in ReqRes MEP tables and removed "local abort" as per "http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002May/0005.html". Also fixed the prefix given that some properties have moved from context to reqres. |
20020503 | HFN | Removed the sentence "This URI is often abbreviated to the term "request-response" throughout this specification." as we have already said that the MEP is called "Request-Response". Also, have casing consistent in using the name (was often "request-response"). |
20020503 | HFN | Removed the notion that MEP properties are relative URIs - they are just URIs. |
20020503 | MJH | Added table cross-references. |
20020503 | MJH | Added streaming edits to state tables in MEP and HTTP binding. |
20020503 | JJM | Added a couple of missing "SOAP" to streaming stuff. |
20020503 | JJM | Added back streaming stuff (with proper XML formatting), after CVS hick-up. |
20020502 | JJM | Added missing <att> |
20020502 | MJG | Clarified arraySize BNF |
20020502 | MJH | Incorporated readability changes into abstract. |
20020502 | MJH | Incorporated readability changes into section 7. |
20020502 | MJH | Decapitalised requesting, responding, request, response, message, node and path. |
20020502 | MJH | Incorporated readability changes into sections 5 and 6. |
20020502 | MJH | Incorporated readability changes into Section 1. |
20020501 | HFN | Change SOAP Node to SOAP node |
20020501 | HFN | Incorporated changes referring first ednote in mail thread in http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002May/0005.html |
20020501 | HFN | Changed "Message Exchange" and other permutations to "MEP" |
20020501 | MJH | Fixed dangling xref. |
20020430 | MJG | Incorporated readability changes into Section 4. |
20020430 | MJG | Incorporated readability changes into Section 3. |
20020430 | MJG | Incorporated readability changes into Section 2. |
20020426 | JJM | Updated member list. |
20020426 | MJH | Removed SOAPAction section - moved to application/soap+xml ID. |
20020425 | MJG | Removed notion of local/global scoping from SOAP Encoding per http://lists.w3.org/Archives/Public/xmlp-comments/2002Apr/0024.html |
20020425 | MJG | Updated on Appendix B1 |
20020425 | MJG | Started on Appendices B2 and B3 |
20020425 | MJH | Completed HTTP status code mapping table (#196). |
20020425 | MJH | Added resolution for issue #192. |
20020425 | JJM | Started incorporating resolution for issue #196. |
20020424 | MJH | Added issue 197 resolution. |
20020411 | MJH | Fixed responding table in HTTP section. |
20020411 | MJH | Removed pt1 TOC from intro and cleaned up abstract. |
20020410 | MJG | Added an id to a div |
20020410 | MJH | Incorporated Noah's minor comments on intro. |
20020410 | MJG | Incorporated Noah's minor comments on Sections 2 and 3 |
20020410 | MJG | Amended beginning of type name computation section 3.1.4 |
20020410 | MJG | Amended prose at start of section 3 |
20020410 | MJG | Swapped sections 3.1.4 and 3.1.5 |
20020410 | MJG | Amended description of how to distinguish outbound edges in section 2.1.1 |
20020410 | MJG | Added prose to description of ref/id specifying that ref target must be encoded using soap encoding. |
20020410 | MJG | Amended description of "struct" in Section 2 |
20020410 | JJM | Added Noah's minor comments on section 4. |
20020410 | JJM | Added Noah's moderate comments on section 4. |
20020410 | JJM | Added Noah's most significant comments on section 4. |
20020409 | MJG | Amended description of "generic" in Section 2 |
20020409 | MJG | Amended the abstract to mention data model, features, MEPs, HTTP binding |
20020408 | MJG | Clarified that 'node' means 'graph node' in Sections 2 and 3 |
20020408 | MJG | Added bullet about Section 5 and 6 to intro |
20020408 | MJG | Fixed typos in Section 3 |
20020404 | JJM | Moved the beginning of section "6.0 MEPs" to part1 as "3.2 MEPs". The remaining text (table) from that section is now section "6.1 Property Conventions for MEPs", as suggested by Noah and Henrik. |
20020403 | MJH | removed duplicate para in section 6.1.3. |
20020403 | MJH | Updated HTTP binding in line with response to question from TBTF. |
20020403 | JJM | Amended ednote in 6.1.3, since Stuart has provided text, but not the TBTF. |
20020403 | MJG | Changed http://www.w3.org/2001/12/soap/bindings/defaultHTTP to http://www.w3.org/2001/12/soap/bindings/HTTP |
20020403 | JJM | Incorporated the resolution for issue 191, including Henrik's friendly amendments. |
20020328 | MJH | Worked through HTTP binding. Main changes around formatting of tables, table headings and improving consistency in language. |
20020327 | JJM | Removed extra spaces around parenthesis, dot, semi-colon and comma. |
20020327 | JJM | Fixed typo discovered by Herve. |
20020322 | HFN | Changed mU='1' with mu='true' in examples. |
20020322 | MJH | replaced transport with context/underlying protocol. |
20020322 | MJG | Made consistent usage of section names; SOAP Data Model, SOAP Encoding, SOAP RPC Representation, SOAP HTTP Binding |
20020322 | MJG | Added priority feedback request regarding 'generics' to section 2.3 |
20020322 | MJH | changed all namespace identifiers, URIs to names. |
20020322 | MJH | removed links in NS URIs. |
20020314 | MJG | Added appendix B (not yet complete) |
20020314 | MJG | Rewrote Section 2 |
20020314 | MJG | Rewrote Section 3 |
20020314 | MJG | Amended Section 4 to match new Section 2 and 3 |
20020321 | HFN | Added text to 7. SOAP HTTP Binding to clarify that HTTP binding is optional and one of many possible bindings |
20020321 | HFN | Made abstract and introduction consistent with Part 1 |
20020321 | MJH | Issue 174 changes. |
20020321 | MJH | Made URI styling consistent throughout and consistent with part 1. |
20020321 | MJH | Made references to fault code values consistent throughout and consistent with part 1. |
20020320 | JJM | Incorporated resolution for issue #180. |
20020320 | JJM | Updated cross-references from saying "bibref" "xspecref" to "bibref" section "xspecref". Otherwise the generated HTML looked funny (the links were back to back) [Ednote issue #33] |
20020320 | JJM | More generally, made all "bibrefs" more uniform. |
20020320 | JJM | Added resolution text for issue 184. |
20020319 | JJM | Incorporated Chris Ferris' proposed resolution to 6.1.4 Fault Handling in anticipation of its acceptance by the WG |
20020318 | JJM | Incorporated resolution to ednote part 2 sec 6.1.3 |
20020316 | HFN | Updated section 6.2 Request-Response Message Exchange Pattern |
20020316 | HFN | Updated section 6.2.4 Fault Handling |
20020316 | HFN | Deleted section 6.1.5, 6.1.6, and 7.4.1.3 |
20020312 | MJH | Incorporated issue 16 resolution. |
20020312 | MJH | Incorporated issue 113 resolution. |
20020312 | MJH | Incorporated issue 48 resolution. |
20020312 | MJH | Fixed up content list of part 1 in introduction. |
20020305 | MJG | Removed section 1.3 ( Terminology) |
20020305 | MJG | Removed section 1.2 ( Examples) |
20020304 | HFN | Updated rule 8 as per resolution to issue 177. Section on default values seemed already to have been removed. |
20020304 | HFN | Removed last two paragraphs in section "RPC and SOAP Header" talking about non-normative example text |
20020228 | HFN | Updated abstract slightly |
20020228 | HFN | Add security considerations text. |
20020228 | HFN | Added second part of resolution of issue 59: Say that we mandate support for UTF-8 and UTF-16 |
20020228 | HFN | Move the HTTP specific examples in Appendix B1 to Appendix C. |
20020227 | MJG | Changed all refs to transport message exchange to message exchange |
20020227 | MJG | Moved ednote from 6.1.3 to be text in 6 |
20020225 | MJG | Removed reference to 'Simple Authentication Feature' in HTTP binding |
20020225 | MJG | added id attrs to all div elements |
20020225 | MJG | Removed section 7.5.2 |
20020225 | MJG | Removed redundant text from 3.1.2 |
20020221 | MJG | Edited examples so that no line is longer than 66 characters |
20020220 | MJG | Moved SOAP HTTP Examples to an appendix marked as non-normative |
20020220 | MJG | Added text stating the paragraph on transaction ids in Section 4.2 is non-normative |
20020219 | MJG | Changed BNF for arraySize to say non negative integer instead of positive integer |
20020219 | MJG | Changed arraySize to use nonNegativeInteger instead of positiveInteger |
20020215 | MJG | Removed old array attributes from encoding schema |
20020215 | MJG | Added new array attributes to encoding schema |
20020215 | MJG | Rewrote Section 3 from XML Infoset perspective |
20020214 | MJG | Removed NOTATION type and element decl from encoding schema |
20020214 | MJG | Rolled back Infoset rewrite of RPC section |
20020214 | MJG | Changed relevant occurrences 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 itemType 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 | Incorporated 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 referring 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 recommendations). |
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 today's 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 (decreasing 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 Recommendation instead of the Candidate Recommendation. |
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 XML Schema 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 placeholder 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 | Referred 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 separate faults schema. Removed entry in envelope schema change table in Appendix D.2 that referred to addition 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. |
Change | Changed arraySize type to allow nonNegativeIntegers instead of positiveIntegers |