Copyright © W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document draws a list of assertions found in the SOAP Version 1.2 specifications, and provides a set of tests in order to show whether the assertion is implemented in a SOAP processor.
The goal of this document is to get a list of features whose implementation can be tested in order to satisfy the entrance criteria of the Proposed Recommendation stage.
It is incorrect to claim to be compliant with the SOAP Version 1.2 specifications by passing successfully all the tests provided in this test suite. It is also incorrect to claim to be non-complaint with the SOAP Version 1.2 specifications by failing any test provided in this test suite. A SOAP 1.2 implementation that passes all of the tests specified in this document may claim to conform to the SOAP 1.2 Test Suite $Date: 2002/06/12 15:13:35 $.
This document is an editors' copy that has no official standing.
This document has been produced by the W3C XML Protocol Working Group. All information in this document is to be considered as work in progress.
This version is based on the May 31 2002 snapshot of the SOAP Version 1.2 Part 1 and Part 2 specifications. Please refer to the latest SOAP Version 1.2 Working Draft for any current normative information.
References to the May 31 2002 snapshot document will gradually go away, and the document will be updated with the text and assertions from the latest version of the draft.
Please send comments on this document to w3c-xml-protocol-wg@w3.org (member archive), especially if something is missing from this list of assertions.
This document draws a list of testable assertions found in the SOAP Version 1.2 specifications, and provides a set of tests in order to show whether the assertion is implemented in a SOAP processor. The primary goal of this document is to foster interoperability between different SOAP 1.2 implementations. The document is intended to help implementors to write SOAP processors that comply with SOAP 1.2 specification, and interoperate with other SOAP processors that comply with SOAP 1.2 specification.
A SOAP 1.2 implementation that passes all of the tests specified in this document may claim to conform to the SOAP 1.2 Test Suite $Date 2002/06/11 $.
Even though the purpose of the SOAP 1.2 Test Suite is to facilitate the creation of interoperable implementations, conformance to the SOAP 1.2 Test Suite does not imply conformance to the SOAP 1.2 specifications; there are mandatory requirements of the specifications that are not tested by the suite (as a simple example, SOAP 1.2 requires that every legal value of a role name is accepted, and all illegal ones rejected). An implementation may be said to be SOAP 1.2 conformant if and only if it it satisfies the conformance requirements specified in SOAP 1.2 specifications. The W3C does not at this time provide for any comprehensive means of testing for such conformance.
Similarly, an implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. SOAP 1.2 specifications admits special purpose implementations, such as those in dedicated controllers, which may send and receive only a very limited suite of messages; the requirement is that whatever is done be done correctly. An implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. The test suite defines higher level application semantics to enable testing and facilitate interoperable implementations. It is not necessary for a SOAP processor to support these higher level semantics to be SOAP 1.2 compliant.
Assertions for SOAP Version 1.2 Part 1 and Part 2 are numbered sequentially (1..n). "Location of the assertion" points the source of the assertion (section or subsection number) in Part 1 or Part 2. Hyperlinks are used to cross-reference to the original specification section/subsection.
Some of the tests in this document use SOAPBuilders interoperability tests as a started point, but have been modified to conform to the SOAP 1.2 specifications.
In particular, this document defines the following namespace names:Normative XML Schema [4], [5] documents for these namespace names can be found by dereferencing the namespace names above.
- The SOAP envelope has the namespace name "http://www.w3.org/2001/12/soap-envelope" (see 5. SOAP Message Construct).
- The SOAP Misunderstood element information item has the namespace name "http://www.w3.org/2001/12/soap-faults" (see 5.4.8 SOAP mustUnderstand Faults).
- The SOAP Upgrade element information item has the namespace name "http://www.w3.org/2001/12/soap-upgrade" (see 5.4.7 VersionMismatch Faults).
This assertion will not be tested.
SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by this specification. The values associated with element and attribute information items defined in this specification MUST be carried explicitly in the transmitted SOAP message except where stated otherwise (see 5. SOAP Message Construct).
This assertion will not be tested.
SOAP attribute information items have types described by XML Schema: Datatypes [5]. Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing.
This assertion will not be tested.
An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message (see 2. SOAP Processing Model).
This assertion will not be tested.
A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model as described in this section and in the remainder of this specification.
This assertion is tested by the entire test collection.
A SOAP node MUST be identified by a URI.
This assertion will not be tested
The roles assumed by a node MUST be invariant during the processing of an individual SOAP message.
This assertion cannot be fully tested, as a SOAP node is allowed to process and remove SOAP headers, reinsert them and send them upstream.
"http://www.w3.org/2001/12/soap-envelope/role/next"
Each SOAP intermediary and ultimate SOAP receiver MUST act in this role and MAY additionally assume zero or more other SOAP roles.
"http://www.w3.org/2001/12/soap-envelope/role/none"
SOAP nodes MUST NOT act in this role.
"http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver"
To establish itself as an ultimate SOAP receiver a SOAP node MUST act in this role. SOAP intermediaries MUST NOT act in this role.
While the purpose of a SOAP role name is to identify a SOAP node, there are no routing or message exchange semantics associated with the SOAP role name.
A SOAP header block MAY carry a role attribute information item (see 5.2.2 SOAP role Attribute) that is used to target the header block at SOAP nodes operating in the specified role. This specification refers to the value of the SOAP role attribute as the SOAP role for the corresponding SOAP header block.
All tests in the test collection that use the role attribute test this assertion.
A SOAP header block is said to be targeted to a SOAP node if the SOAP role for the header block is the name of a role played by the SOAP node.
All tests in the test collection that use the role attribute test this assertion.
Header blocks targeted to the special role "http://www.w3.org/2001/12/soap-envelope/role/none" are carried with the message to the ultimate SOAP receiver(s), but are never formally processed. Such blocks MAY carry data that is required for processing of other blocks.
A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that header block.
All tests in the test collection that uses headers test this assertion.
SOAP header blocks MAY carry mustUnderstand attribute information items (see 5.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory.
Mandatory SOAP header blocks are presumed to somehow modify the semantics of other headers or body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).
This specification therefore does not require any fault to be generated based on the presence or value of the mustUnderstand attribute information item on a SOAP header block not targeted at the current processing node. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver.
An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body).
All tests in the test collection that have body block(s) and do not generate a fault test this assertion.
Unless otherwise stated, processing MUST be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification prevents the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all generated SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below.
- Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any header blocks and the body, MAY be inspected in making such determination.
- Identify all header blocks targeted at the node that are mandatory.
- If one or more of the header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with the Value of Code set to "env:MustUnderstand" (see 5.4.8 SOAP mustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the body MUST NOT be generated in this step.
- Process all header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the application level processing specified by non-mandatory SOAP header blocks targeted at it.
- In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks.
In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP block and MUST do such processing in a manner fully conformant with the specification for that block.
All tests in the test collection that process a soap header without generating a fault, test this assertion.
An ultimate SOAP receiver MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.
Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message processing MAY result in the generation of at-most one fault.
Header-related faults other than those related to understanding header blocks (see 2.4 Understanding SOAP Headers) MUST conform to the specification for the corresponding SOAP header block.
Forwarding intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the message all SOAP header blocks targeted to them, prior to forwarding, regardless of whether these blocks were processed or ignored.
All tests in the test collection that use Node B.
In addition, forwarding intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed.
This assertion will not be tested.
A SOAP node must determine whether it supports the version of a SOAP message on a per message basis.
This assertion will not be tested.
A SOAP node MAY support multiple envelope versions. However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.
If a SOAP node receives a message whose version is not supported it MUST generate a fault (see 5.4 SOAP Fault) with a Value of Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".
The specification of a feature MUST include the following:
- The information (state) required at each node to implement the feature.
- The processing required at each node in order to fulfill the obligations of the feature including any handling of communication failures that might occur in the underlying protocol (see also 4.2 Binding Framework).
- The information to be transmitted from node to node.
- In the case of MEPs: Any requirements to generate additional messages (such as responses to requests in a request/response MEP). Rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP.
This assertion will not be tested. HTTP binding in SOAP 1.2 part 2 is a test for this assertion.
A module specification follows the following rules. It:
- MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation.
- MUST clearly and completely specify the content and semantics of the header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model.
- MAY utilize the property conventions defined in Part 2 [1], section A Convention for Describing Features and Bindings, in describing the functionality that the module provides. If these conventions are followed, the module specification MUST clearly describe the relationship between the abstract properties and their representations in the SOAP envelope. Note that it is possible to write a feature specification purely in terms of abstract properties, and then write a separate module specification which implements that feature, mapping the properties defined in the feature specification to SOAP header blocks in the module.
- MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules).
This assertion will not be tested.
A binding does not provide a separate processing model and does not constitute a SOAP node by itself.
This assertion will not be tested.
A binding specification MUST enable one or more MEP.
HTTP binding specified in SOAP 1.2 part 2 enables an MEP. This assertion will not be tested.
In cases where multiple features are supported by a binding specification the specifications for those features MUST provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.
HTTP binding specified in SOAP 1.2 part 2 enables an MEP. This assertion will not be tested.
As described in 5. SOAP Message Construct, each SOAP message is modeled as an XML Infoset that consists of a document information item with exactly one child: the envelope element information item.
All tests in the test collection test this assertion.
Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP XML Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol.
This assertion will not be tested.
The binding framework does NOT require that every binding use the XML 1.0 [8] serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate.
This assertion will not be tested.
Section 5. SOAP Message Construct provides that the XML Infoset of a SOAP message MUST NOT include a DTD. Accordingly, a binding that uses the XML 1.0 serialization MUST NOT transmit a DTD; a binding that accepts XML 1.0 serializations MUST fault in a binding specific manner if an XML 1.0 serialization corresponding to a DTD for the SOAP message is received.
Although streaming SOAP receivers will acquire such Infosets incrementally, SOAP processing MUST yield results identical to those that would have been achieved if the entire SOAP envelope were available prior to the start of processing.
This assertion will not be tested.
A SOAP message is specified as an XML Infoset that consists of a document information item with exactly one member in its [children] property, which MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope). This element information item is also the value of the [document element] property.
All tests in the test collection test this assertion.
The [notations] and [unparsed entities] properties are both empty. The [base URI], [character encoding scheme] and [version] properties may have any legal value. The [standalone] property either has a value of "true" or has no value.
The XML infoset of a SOAP message MUST NOT contain a document type declaration information item.
A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages that it receives.
Element information items defined by this specification may have zero or more character information item children whose character code is amongst the whitespace characters as defined by [8]. Unless otherwise indicated, such character information items are considered insignificant. A SOAP receiver MUST ignore such insignificant character information items.
The Envelope element information item has:
- A [local name] of Envelope .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
- Zero or more namespace qualified attribute information items amongst its [attributes] property.
- One or two element information items in its [children] property in order as follows:
- An optional Header element information item (see 5.2 SOAP Header).
- A mandatory Body element information item (see 5.3 SOAP Body).
All the tests in the test collection test this assertion.
The encodingStyle attribute information item has:
- A [local name] of encodingStyle .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
All tests in the test collection that use encodingSytle attribute test this assertion.
The encodingStyle attribute information item MAY only appear on:
- A SOAP header block (see 5.2.1 SOAP header block).
- A child element information item of the SOAP Body element information item (see 5.3.1 SOAP Body child Element).
- A child element information item of the SOAP Detail element information item (see 5.4.5.1 SOAP detail entry).
- Any descendent of 1, 2, and 3 above.
All tests in the test collection that use encodingSytle attribute test this assertion.
The scope of the encodingStyle attribute information item is that of its owner element information item and that element information item's descendants, unless a descendant itself carries such an attribute information item.
If no encodingStyle attribute information item is in scope for a particular element information item or the value of such an attribute information item is the zero-length URI ("") then no claims are made regarding the encoding style of that element infomation item and its descendants.
The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema.
The Header element information item has:
- A local name of Header
- A namespace name of http://www.w3.org/2001/12/soap-envelope
- Zero or more namespace qualified attribute information item children.
- Zero or more namespace qualified element information item children.
Each SOAP header block element information item:
- MUST have a [namespace name] property which has a value, that is, MUST be namespace qualified.
- MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [8] are considered significant.
- MAY have an encodingStyle attribute information item in its [attributes] property.
- MAY have an role attribute information item in its [attributes] property.
- MAY have a mustUnderstand attribute information item in its [attributes] property.
The SOAP header block attribute information items defined later in 5.2.2 SOAP role Attribute and 5.2.3 SOAP mustUnderstand Attribute affect the processing of SOAP messages by SOAP receivers (see 2. SOAP Processing Model). A SOAP sender generating a SOAP message SHOULD use these attributes only on SOAP header block. A SOAP receiver MUST ignore these attribute information items if they appear on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).
The role attribute information item has the following Infoset properties:
The type of the role attribute information item is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the role attribute information item is a URI that names a role that a SOAP node may assume.
- A [local name] of role .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
- A [specified] property with a value of "true".
All tests in the test collection that use roles, will test this assertion.
Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver".
An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the block at an ultimate SOAP receiver.
SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP role attribute information item with a value of "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver" (see 1.2.2 Robustness Principle).
The mustUnderstand attribute information item has the following Infoset properties:
The type of the mustUnderstand attribute information item is boolean in the namespace "http://www.w3.org/2001/XMLSchema".
- A [local name] of mustUnderstand .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
- A [specified] property with a value of "true".
All tests in the test collection that use mustUnderstand attribute, test this assertion.
Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false" or "0".
SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP mustUnderstand attribute information item with a value of "false" or "0" (see section 1.2.2 Robustness Principle).
A SOAP receiver MUST accept any valid lexical representation of the attribute value.
The Body element information item has:
- A [local name] of Body .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
- Zero or more namespace qualified attribute information items in its [attributes] property.
- Zero or more namespace qualified element information items in its [children] property.
All child element information items of the SOAP Body element information item:
- MUST have a [namespace name] property which has a value, that is, be namespace qualified.
- MAY have an encodingStyle attribute information item in their [attributes] property.
The Fault element information item has:
- A [local name] of Fault .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
- Two or more child element information items in its [children] property in order as follows:
- A mandatory Code element information item (see 5.4.1 SOAP Code Element).
- A mandatory Reason element information item (see 5.4.2 SOAP Reason Element).
- An optional Node element information item (see 5.4.3 SOAP Node Element).
- An optional Role element information item (see 5.4.4 SOAP Role Element).
- An optional Detail element information item (see 5.4.5 SOAP Detail Element).
All tests in the test collection that generate fault, test this assertion.
To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child of the SOAP Body .
When generating a fault, SOAP senders MUST NOT include additional element information items in the SOAP Body. A message whose Body contains a Fault plus additional element information items has no SOAP-defined semantics.
The Code element information item has:
- A [local name] of Code .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
- One or two child element information items in its [children] property, in order, as follows:
- A mandatory Value element information item as described below (see 5.4.1.1 SOAP Value element (with Code parent))
- An optional Subcode element information item as described below (see 5.4.1.2 SOAP Subcode element).
All tests in the test collection that generate fault, test this assertion.
The Value element information item has;
The type of the Value element information item is faultCodeEnum in the "http://www.w3.org/2001/12/soap-envelope" namespace.
- A [local name] of Value .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
All tests in the test collection that generate fault, test this assertion.
The Subcode element information item has:
- A [local name] of Subcode .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
- One or two child element information items in its [children] property, in order, as follows:
- A mandatory Value element information item as described below (see 5.4.1.3 SOAP Value element (with Subcode parent)).
- An optional Subcode element information item (see 5.4.1.2 SOAP Subcode element).
The Value element information item has:
The type of the Value element information item is QName in the "http://www.w3.org/2001/XMLSchema" namespace.
- A [local name] of Value .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
The Reason element information item has:
- A [local name] of Reason .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
- An optional attribute information item with a [local name] of lang and [namespace name] of "http://www.w3.org/XML/1998/namespace" (see [8], Language Identification).
The type of the Reason element information item is string in the "http://www.w3.org/2001/XMLSchema" namespace.
The Node element information item has:
- A [local name] of Node .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item.
The Role element information item has:
The type of the Role element information item is anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.
- A [local name] of Role .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
The Detail element information item has:
- A [local name] of Detail .
- A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
- Zero or more attribute information items in its [attributes] property.
- Zero or more child element information items in its [children] property.
The Detail element information item MUST be present when the contents of the SOAP Body could not be processed successfully. It MUST NOT be used to carry error information about any SOAP header blocks.
Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.
The values of the Value child element information item of the Code element information item are restricted to those in Table 2. Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item.
The Upgrade element information item has:
The envelope element information item has:
- A [local name] of Upgrade .
- A [namespace name] of "http://www.w3.org/2001/12/soap-upgrade".
- One or more envelope element information items in its [children] property as described below:
- A [local name] of envelope .
- A [namespace name] which has no value.
- An unqualified attribute information item with a local name of qname and a type of QName in the "http://www.w3.org/2001/XMLSchema" namespace.
A SOAP node MAY generate a SOAP fault for any one or more SOAP header blocks that were not understood in a SOAP message. It is NOT a requirement that the fault contain the qualified names of ALL such header blocks. Each such header block element information item has:
The qname attribute information item has the following Infoset properties:
- A [local name] of Misunderstood .
- A [namespace name] of "http://www.w3.org/2001/12/soap-faults".
- A qname attribute information item in its [attributes] property as described below.
The type of the qname attribute information item is QName in the "http://www.w3.org/2001/XMLSchema" namespace. Its value is the QName of a header block which the faulting node failed to understand.
- A [local name] of qname .
- A [namespace name] which has no value.
- A [specified] property with a value of "true".
SOAP does not define a base URI but relies on the mechanisms defined in XML Base[11] and RFC 2396[6] for establishing a base URI against which relative URIs can be made absolute.
The use of IP addresses in URIs SHOULD be avoided whenever possible (see RFC 1900 [18]. However, when used, the literal format for IPv6 addresses in URIs as described by RFC 2732 [12] SHOULD be supported.
SOAP does not place any a priori limit on the length of a URI. Any SOAP node MUST be able to handle the length of any URI that it publishes and both SOAP senders and SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length.
A SOAP/1.1 node receiving a SOAP Version 1.2 message will according to SOAP/1.1 generate a version mismatch SOAP fault based on a SOAP/1.1 message construct. That is, the envelope will have a local name of Envelope and a namespace name of "http://schemas.xmlsoap.org/soap/envelope/".
Since this assertion is about the behavior of SOAP 1.1 compliant SOAP node, the test collection does not test this assertion.
A SOAP Version 1.2 node receiving a SOAP/1.1 message either:
- MAY process the message as a SOAP/1.1 message (if supported), or
- MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics. The SOAP fault SHOULD include an Upgrade header block as defined in this specification (see 5.4.7 VersionMismatch Faults) indicating support for SOAP Version 1.2. This allows a receiving SOAP/1.1 node to correctly interpret the SOAP fault generated by the SOAP Version 1.2 node.
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.
All tests in the test collection that use soap encoding, will test this assertion.
The graph node at which an edge terminates is determined as follows:
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.
- 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) amongst 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".
The "lexical value" of a terminal graph node is the sequence of Unicode characters identified by the character information item children of the element information item representing that node.
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).
For a graph edge which is distinguised by label ( "struct" or "generic" ), the namespace name property of the element information item determines whether the edge label is globally or locally scoped:
The intepretation of the local name property of the element information item with respect to the edge label is as follows:
- If the namespace name is empty then the edge label is locally scoped.
- If the namespace name is not empty then the edge label is globally scoped. The namespace name is the URI part of the edge label.
- If the edge label is locally scoped, the edge label is the same as the local name. (see A. Mapping Application Defined Names to XML Names).
- If the edge label is globally scoped, the non-URI part of the edge label is the local name. (see A. Mapping Application Defined Names to XML Names).
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 amongst 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 amongst its attributes an arraySize attribute information item (see 3.1.6 arraySize Attribute Information Item).
All tests in the test collection that use arrays, will test this assertion
If a graph edge does not terminate in a graph node then it can either be omitted from the serialization or it can be encoded as an element information item with an xsi:nilattribute information item.
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 amongst its attributes then the type name property of the graph node is the value of the xsi:type attribute information item.
- 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) amongst 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.
All encoding tests in the test collection, test this assertion.
The itemType attribute information item has the following Infoset properties:
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.
- 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 id attribute information item has the following Infoset properties:
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 refered to by a ref attribute information item (see 3.1.5.2 ref Attribute Information Item).
- A local name of id ;
- A namespace name which is empty
- A specified property with a value of "true".
The ref attribute information item has the following Infoset properties:
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).
- A local name of ref ;
- A namespace name which is empty
- A specified property with a value of true.
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:
The type of the arraySize attribute information item is arraySize in the namespace named "http://www.w3.org/2001/12/soap-encoding". Value of enc:arraySize [1] arraySizeValue ::= ("*" | concreteSize) nextConcreteSize* [2] nextConcreteSize ::= " " concreteSize [3] concreteSize ::= non negative integer Each item in the list of sizes represents the size of each of the array's dimensions (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list.
- A local name of arraySize ;
- A namespace name of "http://www.w3.org/2001/12/soap-encoding".
- A default value of "*"
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.
Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in 3. SOAP Encoding, other representations are possible. The SOAP encodingStyle attribute information item (see [1]SOAP Encoding Attribute) can be used to indicate the encoding style of the RPC invocation and/or the response using the representation described in this section. The encoding specified must support the "struct" and/or "array compound" value constructions from the SOAP data model 2. The SOAP Data Model.
However, use of the SOAP RPC Representation is not limited to the SOAP HTTP Binding (see 7. SOAP HTTP Binding).
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 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 RPC response to contain both a result and 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.3 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.
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.
env:Receiver will not be tested by the test collection.
TODO: test for rpc:BadArguments
Properties are named with XML qualified names (QNames).
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.
Table 2: Property definitions supporting the description of MEPs
This message exchange pattern is identified by the URI:
- 'http://www.w3.org/2001/12/soap/mep/single-request-response/'
Table 4: Instantiation of a Message Exchange Context for a requesting SOAP node
Table 5: Instantiation of Message Exchange Context for an inbound request message
Table 6: Requesting SOAP Node State Transitions
Table 7: Responding SOAP Node State Transitions
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.
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].
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."
An implementation of the SOAP HTTP Binding MUST support the following message exchange pattern (MEP):
- "http://www.w3.org/2001/12/soap/mep/request-response/" (see 6.2 Request-Response Message Exchange Pattern)
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).
State Description: Requesting
Table 11: HTTP Status Codes Dependent Transitions
Table 15: State Description: Receiving
Appendix A lists rules to convert a application defined name to an XML name
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.
All the tests in this test collection follow the following rules:
Header blocks used by the test collection :
Unless otherwise specified the header blocks used by this test collection are in the namespace http://example.org/ts-tests. If a header block not listed below is targeted at a Node, that Node must generate a fault with the Value of the fault Code as env:mustUnderstand.Body blocks used by the test collection :
Unless otherwise specified the body blocks used by this test collection are in the namespace http://example.org/ts-tests. If a body block not listed below is targeted at a Node, that Node must generate a fault.RPC methods used by the test collection :
Unless otherwise specified the procedure/method names used by this test collection are in the namespace http://example.org/ts-tests. If a RPC procedure/method is not listed below is targeted at a Node, that Node must generate a fault. In addition to types defined in the namespace http://www.w3.org/2001/XMLSchema, the test collection uses the following schema types (defined below in the schema fragment):<complexType name="SOAPStruct"> <all> <element name="varString" type="string"/> <element name="varInt" type="int"/> <element name="varFloat" type="float"/> </all> </complexType> <complexType name="SOAPStructStruct"> <all> <element name="varString" type="string"/> <element name="varInt" type="int"/> <element name="varFloat" type="float"/> <element name="varStruct" type="tns:SOAPStruct"/> </all> </complexType>
Where tns refers to http://example.org/ts-tests and 'complexType', 'all', and 'element' have the usual meaning as defined by XML schema.
SOAPArrayStruct consists of a structure with four outbound edges each of types string, int, float and array of string in the namespace http://www.w3.org/2001/XMLSchema.
The encoding represented by the URI http://example.com/PoisonEncoding is an encoding that is not recognized by any of the SOAP nodes.
Some of the tests in this test collection test SOAP 1.2 HTTP binding. The request and response messages for these tests contain HTTP start-line (request-line or status-line), HTTP headers required by the bindings and the XML payload. Additional HTTP headers can be generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. In the tests, the value of the 'Content-Length' and 'Host' header should be replaced with an appropriate value.
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
This tests assumes the existence of a conventionally non-existant encoding to test a failure condition. It is the intention that no receiving SOAP 1.2 node will support this encoding and that on receiving this encoding style declaration in a SOAP message, will return the DataEncodingUnknown fault.
Node A sends a simple SOAP 1.2 message to Node C containing the poison encoding style declaration. Node C responds with a fault.
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
11 June 2002 - ASK
Added a list of headers, body blocks and RPCs used by the test collection along with a brief explanation of the associated semantics.
10 June 2002 - ASK
Cleaned/reformed tests (reused headers where possible)
fixed problems such as MU, role not being NS-qualified.
Removed test T1.2.16
Removed test rdm5.1.148 - I do not understand what it does
Added a list of headers, body blocks and RPCs used by the test
collection along with a brief explanation of the associated semantics.
9 June 2002 - ASK
Fixed test rdm5.4.5.76
Added http-415 test
Added echoStringArray-noItemType test
8 June 2002 - ASK
Removed test Mark84, Mark86 - they test SOAP 1.2
Removed T1.4.3 - dup of T1.4.2
Fixed T1.2.25 as per HFN's feedback
Fixed T1.3.1 as per HFN's feedback
Removed DTDNotSupported Exception as per HFN's feedback
Fixed T1.4.1 as per HFN's feedback
Fixed LRT102 as per HFN's feedback
Fixed LRT104 as per HFN's feedback
Fixed trailer-test, no-body-test, non-nsqualified-attr-test as per HFN's feedback
4 June 2002 - ASK
'dangling pronouns' are fixed by adding previous sentence from the spec, or combining two assertions, or adding an explanation in the comments section.
3 June 2002 - ASK
Synched up with May 31st version of SOAP 1.2 spec.
28 May 2002 - ASK
Added HTTP tests.
22 May 2002 - ASK
Change the subtitle from 'SOAP 1.2 Conformance Assertions' to 'SOAP 1.2
Assertions'
Fixed a few editorial issues and nits.
21 May 2002 - ASK
Updated to include Lynne's and Nick's comments.
Synched up with May 14, 2002 version of the spec.
21 May 2002 - ASK
Added Lynne's new tests.
18 May 2002 - ASK
Added 10 more tests
15 May 2002 - ASK
Included Lynne's test for SBR2
Misc. corrections.
14 May 2002 - ASK
Included Oisin's test for 111
13 May 2002 - ASK
Update the author's list to include Mark, Lynne and Richard.
Removed API tests.
12 May 2002 - ASK
Incorporated feedback from JohnI regarding diffs between the May 3rd
version of the spec and April 12th version of the spec.
Incorporated feedback from ChrisF regarding diffs between the May 3rd
version of the spec and April 12th version of the spec.
05 May 2002 - ASK
Synched up assertions from Part 2, section 4 and 7 to April 11 2002
version of the spec. Changes were sent by Lynne
New assertion numbering added.
04 May 2002 - ASK
Synched up tests generated by Richard for Part 1.
30 April 2002 - ASK
Synched up assertions from Part 2 Section 1-3, Appendex A-B to April 11
2002 version of the spec
Added Mark Jones' tests
Added Lynne's 3 new assertions from Part 1
Added Oisin's assertions from Part 2 section 5-6 along with the
apitests
Changes to the doc, so that the text description of the test will
correctly show up in the HTML version of the doc
25 April 2002 - ASK
Synched up assertion from Part 1 to April 11 2002 version of the spec
Added Introduction section as per discussion on dist-app wrt issue 36
'actor' has been replace with 'role' in all the assertions (part1
and part 2) as well as all the test message envelopes
Namespaces have be corrected to reflect the one in april 11th doc
Changed the test NS from http://www.w3.org/2000/xp/Group/1/09/ts
to http://www.w3.org/2000/xp/Group/1/12/ts
Title has been changed
Severl misc. changes
24 April 2002 - ASK
Synched up assertion #81-110 to March 23 2002 version of the spec
25 March 2002
Incorporated comments and editorial from Microsoft
15 March 2002
Updated assertions titles with section numbers Small changes in the style sheet
10 March 2002
All specification text is now in blockquote style
Changed color styles that affected hardcopy legibility
Editorial changes to remove some errors
Add Acknowledgments section
6 March 2002
Adopted tests styling from Microsoft tests contribution
Reordered document to separate tests and assertions for
effective re-use
4 March 2002
Stylesheet tuning to clean up html output
Removed specref elements with hard-coded spec references
Assertion number headers are now hyperlinked to specification
documents
Assertions are auto-counted in the stylesheet
Elided assertions that are not part of specification
Added entities to DTD to parameterize specification location
26 February 2002 - JM
First pass at incorporating new MS assertions.
Transform to xml tags used in main doc.
Note: possible inconsistent sections #s: new asssertions partially
written against editor doc, not Dec 17 WD
Start of transition to new testspec format.
Needs to be reviewed against editor doc for accuracy and missing assertions.
20 February 2002
Large re-edit to incorporate new assertions from the 17
December 2001 specification draft, work done at the face to face
meeting in Burlington and assertions generated from new material
around the transport binding framework.
Changed the style of grouping to parallel that of the
specification for the purposes of simplifying cross-referencing
of the assertions with the specification text.
24 September 2001
Finished conversion to XML.
Grouped tests in categories.
Rewrote the boilerplate and intro to reflect face-to-face
decision to develop this document.
Wrote some tests.
31 July 2001
Removed DA/A distinction.
Evaluation of the SB tests.
Added a references section
for the As.
25 July 2001
First version of the draft. Very rough.
This document is the work of the W3C XML Protocol Working Group. As such, all members of that group are acknowledged for their joint and several contributions to this work.
The editors would like to acknowledge Kirill Gavrylyuk (Microsoft) for the gladly-received contribution of test messages and assertions for SOAP 1.2 Part 1.
The editors would like to acknowledge John Ibbotson and Chris Ferris for generating the differences between various versions of the SOAP 1.2 specification.
The editors would like to acknowledge Nick Smilonich reviewing this document.
The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.