Copyright © W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document draws a list of testable assertions found in the SOAP Version 1.2 specification, 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 specification 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 specification 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/05/06 $.
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 April 11 2002 snapshot of the SOAP Version 1.2 Part 1 and Part 2 specification. Please refer to the latest SOAP Version 1.2 Working Draft for any current normative information.
References to the April 11 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.
Editorial Note:
The mailing list has been restricted on the basis of the fact that the specification documents referenced from here are the WG-private versions.
Introduction
SOAP 1.2 Conformance Assertions
Testing MEP Metadata
Pattern and Binding Assertions
SOAP 1.2 Tests Collection
Changelog
This document draws a list of testable assertions found in the SOAP Version 1.2 specification, 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 (insert version number).
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 specification; there are mandatory requirements of the specification 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 specification. 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 specification even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. SOAP 1.2 specification 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 specification 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 are numbered with the section and subsection numbers of their source in the specification, suffixed with a unique number
Editor's note:
These are currently out of sync, but the hyperlinks are correct
To improve the reviewing experience, assertions are cross-referenced to the original specification text using hyperlinks. Traversing an assertion hyperlink in a browser will navigate to the subsection of the specification that contains the original text of the assertion.
SOAPBuilders interoperability tests have been referenced in this document. They are numbered as follows: SBRng, meaning SOAPBuilders round n, group g. Some tests are listed as testing two assertions (e.g. arrays and structs). Obviously, structs and arrays can use simple types, but this is not listed as such to avoid making the document too complex.
It is important to note that the presence of references to the SOAPBuilders interoperability tests is intended to serve only as a guideline for the development of SOAP 1.2 tests. The SOAPBuilders tests are explicitly designed to test SOAP 1.1 and SOAP 1.1 features. The core functionality in such tests may have been superceded by the development of new specification text in the SOAP 1.2 working drafts.
All the tests follow the following rules:
Communication with the SOAP processor tested is done by HTTP, using the HTTP binding described in the Part 2, Section 8 of the specification draft.
Multiple nodes are identified by the names A, B and C. In the cases where tests need to have multiple nodes, this convention is used, for example, see
The node tested must act in the role http://www.w3.org/2000/xp/Group/1/12/ts-tests/test, unless specified otherwise in the particular test case.
Schema documents for these namespaces can be found by dereferencing the namespace identifiers. These schemas are normative.
the schema for the SOAP namespaces is the 'gold standard' against which all envelopes will be applied. It should be correct!
attempt to access the schema document
apply schema document to an envelope instance
SOAP does not require any XML schema processing (assessment or validation) in order to establish the values or correctness of element and attribute information items defined by this specification.
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.
The implementation of this assertion is tested by the entire test suite.
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 tested, as a SOAP node is allowed to process and remove SOAP headers, reinsert them and send them upstream. But a interop test can be created, consisting of two headers with different QNames but same role and MU=1.
"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.
Other header blocks with unrecognized values for the role attribute must be ignored.
SB tests do not cover the case of the URI of the node, they only cover the .../next URI case.
SBR2C tests: SBR2 echoMeStringRequest which uses mustUnderstand="0"; SBR2 echoMeStructRequest which uses mustUnderstand="1"; SBR2 unknown header entry which uses a combination of both.
"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.
Design a test that contains the above role and involves an intermediary.
Check the tests below if they still make sense
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.
SOAP header blocks carry optional role attribute information items (see 4.1.2.2 SOAP role Attribute) that are used to target them to the appropriate SOAP node(s). This specification refers to the (implicit or explicit) value of the SOAP role attribute as the SOAP role for the corresponding SOAP header block.
Ensure that the tests still make sense
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.
Ensure that the tests still make sense
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.
This assertion is similar to an assertion above. Create two headers, one header with role none and another targetted to the ultimate reciever. Have the header refer to data in another.
A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.
All tests that uses headers cover this.
SOAP header blocks carry optional 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 blocks MUST be 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 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).
Check how A4, A5 and A6 are related (in the spec, and for the tests).
Probably should be deleted in favor of next set of assertions - JM
This specification therefore does not require any fault to be generated based on the presence or value of this attribute on a SOAP header block not targeted at the current processing node, for example when it is suspected that such a block has survived erronously due to a routing or targeting error at a preceeding intermediairy. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted to a role other than the ones assumed by the ultimate SOAP receiver.
Ensure that the tests still make sense. Create a test where a MU header will survive till the Node C and Node C does not act in the role.
An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body).
All test that have a body and do not generate fault will test this.
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 a value of "env:MustUnderstand" for faultcode (see 5.4.8 Must Understand 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 processing implied 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.
All tests will follow the above rules
Send one mustUnderstand block.
Send several mustUnderstand blocks.
Send one not understandable mustUnderstand block.
Send several not understandable mustUnderstand block.
Check processing and the fault returned.
Have a node A send a msg with MU header to Node B that Node B does not understand. In addition, there should be a problem with the body. The fault should be MU fault.
Send a combination of blocks and check that the SOAP node does the right thing (needs details; see the example from the Dinard face-to-face).
SBR2C tests: SBR2 unknown header entry element unknown header sent with mustUnderstand="0"/"1" targetted to the/another SOAP node
SBR2C tests: SBR2 echoMeStructRequest sends an understandable header with mustUnderstand="1".
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 that process a soap header without generating a fault.
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 than those related to understanding header blocks (see 2.4 Understanding SOAP Headers) MUST conform to the specification for the corresponding SOAP header block.
Should we construct a test here? I suppose a test which generates a non-MU fault for a header would do the trick.
Forwarding intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages.
Any test that uses a forwarding intermediary.
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.
A test that has a header targeted to the intemediary.
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.
A test that uses intermediaries.
A SOAP node must determine whether it supports the version of a SOAP message on a per message basis.
However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.
Construct a test which uses SOAP 1.2 env and SOAP 1.1 MU for a header which is then ignored.
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 "env:VersionMismatch" for faultcode . Any other malformation of the message construct MUST result in the generation of a fault with a value of "env:Sender" for faultcode .
Construct a test which uses SOAP 1.1 env which is not supported (results in a fault). Construct a test which uses the correct env version, but does not have a body, this should generate a env:Sender faultcode.
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.
The use of HTTP binding is a good test.
A SOAP binding specification:
- Declares the features provided by a binding.
- Describes how the services of the underlying protocol are used to honor the contract formed by the declaration of features supported by that binding.
- Describes the handling of all potential failures that may be anticipated within the binding.
- Defines the requirements for building a conformant implementation of the binding being specified.
No test for this will be constucted.
A binding does not provide a separate processing model and does not constitute a SOAP node by itself.
No test for this will be constucted.
A binding specification MUST enable one or more message exchange pattern.
HTTP binding does that. No test for this will be constucted.
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 does that. No test for this will be constucted.
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.
Point to the tests for the corresponding assertion in section 5.
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.
HTTP binding does that. No test for this will be constucted.
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.
No test for this will be constucted.
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.
A test which sends DTD and gets a fault back.
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.
Construct a test which sends a XML message which does not have env as its root.
No test designed for this assertion yet!
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.
Construct a test which sends a XML message with dtd containing entities and notation. Construct a test which sends a XML message with standalong property as false.
The XML infoset of a SOAP message MUST NOT contain a document type declaration information item.
A test which sends DTD and gets a fault back.
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.
Construct a test which sends a PI. The sender should get back the expected response (assuming PI is ignored).
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.
Construct a test which sends 2 msgs. The only diff between the 2 msg is whitespace. Expect the same response back.
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).
Generate a test that sends a bad env. This test will test more than one assertion (eg. version mismatch etc).
The encodingStyle attribute information item has:
- A [local name] of encodingStyle .
- A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
Will be tested anytime soapencoding is tested.
The encodingStyle attribute information item MAY appear on any element information item in the SOAP message except the Envelope element information item.
Construct a test which sets the encodingStyle attr on the Env. Expect a fault.
Its scope 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.
Create a test which uses soap enc, with an unknow encodingStyle on the Body and soap enc on the body block (for rpc) and expect to get the correct response.
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.
does this means that the 'claims' can be turned off forever or for just the scope of the element on which the encodingStyle attribute is attached
No test designed for this assertion yet!
check that the "" URI is accepted>
check that the "" URI switches off a previous encoding style
check the scope of this 'switch off'
Test 1: Test for acceptance of empty encoding style attribute. Send a message with encoding style attribute set to empty string. No fault should be returned. Expect empty encoding style to be echoed back. Test 2: Check scoping rules work correctly for encoding style. Send a message with 3 nested elements with only the top element defining a encoding style. Ask for the encoding style of the middle element. It should be the same as set for the top element. Send a message with 3 nested elements each with different encoding style. Outer one in SOAP encoding style, the middle one with empty value for encoding style and the last one SOAP again. Ask for the encoding style value of the middle element. It should be empty. Send a message with 3 nested elements each with different encoding style. Outer one in SOAP encoding style, the middle one with empty value for encoding style and the last one SOAP again. Ask for the encoding style value of the inner most element. It should be the same as the one specified for inner-most element.The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema.
if an encoding style is present, check the namespace, the schema type and the structure of the list (ie whitespace delimited, using all different types of whitespace)
Goal is to test whether the server understands the presence of encodingStyle attribute in SOAP namespace. Send a simple SOAP message with an encodingStyle attribute in SOAP namespace. Expect the service to echo the namespace and the value of the encoding style sent. Success is indicated by a clean match with the values sent. Send another message with a local name of encodingStyle in a different namespace other than the SOAP namespace. Expect to get back empty values for namespace and empty value for the encoding style. rdm5.1.1.48The 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.
As for DA9, the syntax should be checked at every test.
No test designed for this assertion yet!
tests are pretty much specified in the quote above!
Tests o, Send a message with a proper header element and with one header block whose element name is not namespace qualified. Expect a fault back. What is the fault code ( check the spec ) o, Send a message with header element defined under different namespace other than the SOAP namespace. Expect a fault back. (what is the fault code? to expect) o, Send a message with a proper header element with attributes for header. If the request succeeds without any fault, then it indicates that the node can live with the attributes on header element. Other variation of this test case be, write a echo service that echoes back the attributes. Testing mustUnderstand/role and other SOAP defined attributes. The handling of these attributes by the SOAP server is probably going to be tested through process/behavioral testing and in the case of encoding through part II testing. So, what ever we do here as part of this assertion will probably end up as overlaps at the least. Forgetting that, we can define some unit tests to check whether the server provides special treatment or understands them as soap defined attributes. o, Expect a echo service that echoes back all SOAP defined attributes in a message with the Qname of the attribute sent, the namespace the attribute is associated with and the value specified in the message for that attribute. Send many messages each containing all or nothing or some combinations of SOAP defined attributes. Expect the response message to contain the SOAP defined attributes sent in the request.Each SOAP header block element information item:
- MUST be namespace qualified;
- MAY have an encodingStyle attribute information item
- MAY have an role attribute information item
- MAY have a mustUnderstand attribute information item
As for DA9, the syntax should be checked at every test.
No test designed for this assertion yet!
tests are pretty much specified in the quote above!
Tests o, Send a message with a proper header element and with one header block whose element name is not namespace qualified. Expect a fault back. What is the fault code ( check the spec ) o, Send a message with header element defined under different namespace other than the SOAP namespace. Expect a fault back. (what is the fault code? to expect) o, Send a message with a proper header element with attributes for header. If the request succeeds without any fault, then it indicates that the node can live with the attributes on header element. Other variation of this test case be, write a echo service that echoes back the attributes. Testing mustUnderstand/role and other SOAP defined attributes. The handling of these attributes by the SOAP server is probably going to be tested through process/behavioral testing and in the case of encoding through part II testing. So, what ever we do here as part of this assertion will probably end up as overlaps at the least. Forgetting that, we can define some unit tests to check whether the server provides special treatment or understands them as soap defined attributes. o, Expect a echo service that echoes back all SOAP defined attributes in a message with the Qname of the attribute sent, the namespace the attribute is associated with and the value specified in the message for that attribute. Send many messages each containing all or nothing or some combinations of SOAP defined attributes. Expect the response message to contain the SOAP defined attributes sent in the request.A SOAP receiver MUST ignore all such attribute information items on descendant of a SOAP header block.
No test designed for this assertion yet!
no testsThe 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 that use roles will test this assertion.
No test designed for this assertion yet!
no testsOmitting 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".
Create a test that uses an intemediary with a header with MU=1 and no role attr. Expect the ultimate receiver to process the header.
An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the block at an ultimate SOAP receiver.
Create a test that uses an intemediary with a header with MU=1 and no role attr. Expect the ultimate receiver to process the header.
SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP role attribute information item for SOAP header blocks targeted at an ultimate SOAP receiver (see section 1.2.2 Robustness Principle).
Create a test that uses an intemediary with a header with MU=1 and with role attr as "http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver" Expect the ultimate receiver to process the header.
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 that use MU will 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. These MAY include an encodingStyle attribute information item.
- 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.
Almost all test that do not result in a fault test this assertion. A separate test for this assertion will not be constructed.
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 faultcode element information item (see 5.4.1 SOAP faultcode Element).
- A mandatory faultstring element information item (see 5.4.2 SOAP faultstring Element).
- An optional faultnode element information item (see 5.4.3 SOAP faultnode Element).
- An optional faultrole element information item (see 5.4.4 SOAP faultrole Element).
- An optional detail element information item (see 5.4.5 SOAP detail Element).
All tests that generate faults will test this assertion.
To be recognized as carrying SOAP error information, a SOAP message MUST contain exactly one SOAP Fault as the only child element of the SOAP body.
This should be tested in every scenario in which a fault is expected.
The faultcode element information item has:
- A [local name] of faultcode .
- A [namespace name] which has no value.
- 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 faultcode parent))
- An optional subcode element information item as described below (see 5.4.1.2 SOAP subcode element).
This should be tested in every scenario in which a fault is expected.
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] which has no value.
This should be tested in every scenario in which a fault is expected.
The subcode element information item has:
- A [local name] of subcode .
- A [namespace name] which has no value.
- 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).
Constuct a test that returns a fault subcode.
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] which has no value.
Constuct a test that returns a fault subcode.
The faultstring element information item has:
- A [local name] of faultstring .
- A [namespace name] which has no value.
All tests that return fault will test this assertion.
The type of the faultstring element information item is string in the "http://www.w3.org/2001/XMLSchema" namespace.
All tests that return fault will test this assertion.
The faultnode element information item has:
- A [local name] of faultnode .
- A [namespace name] which has no value.
Constuct a test that returns a faultnode.
SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item.
Constuct a test where the intermediary returns a faultnode.
The faultrole element information item has:
The type of the faultrole element information item is anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.
- A [local name] of faultrole .
- A [namespace name] which has no value.
Construct a test which generates a fault which includes faultrole element.
The detail element information item has:
- A [local name] of detail .
- A [namespace name] which has no value.
- Zero or more attribute information items in its [attributes] property.
- Zero or more child element information items in its [children] property.
Construct a test which generates a fault which includes a detail element.
The detail element information item MUST present when the contents of the SOAP Body could not be processed successfully.
Construct a test which generates a fault because of the problem with the body.
It MUST NOT be used to carry error information about any SOAP header blocks.
This negative test will not be tested.
Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.
Construct a test which generates a fault because of the problem with the header, have the server return the details in the header.
The values of the value child element information item of the faultcode element are restricted to those in the table below. Specifications that wish to implement their own fault codes MUST do so by sub-categorizing an existing fault code via the subcode element.
A lot of test in the test suite will be testing this assertion. Do we need a soap validator to validate a soap message?
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.
Construct a test which results in generation of upgrade element.
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".
Construct a test with a header that is relevant and has a MU=1/true. Expect the server to return a MU fault.
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.
No test designed for this assertion yet!
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.
The 8k limitation is easily tested with a simple SOAP sender and receiver node transmitting and receiving a SOAP message with a contrived URI of greater than this length. Ensuring that a SOAP node will handle the length of all URIs that it publishes difficult to test explicitly as there is no way to tell a priori what URIs a SOAP node will generate during its lifetime.
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 talk about what a SOAP 1.1 node does it should not be tested -ASK.
This assertion is easily tested: a SOAP node will send a 1.2 message to a node that only supports 1.1 and will ensure that
2. 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.
Construct a test where a sender sends a soap 1.1 message and the receiver returns a version mismatch fault with an upgrade header block.
If a SOAP 1.1 sender transmits a 1.1 message to a SOAP 1.2 node, the receiving node will either
In the case where the 1.A.4 test returns a VersionMismatch fault, the fault should contain a list of supported versions - at this time only 1.2 will be included in that list. If the fault does not contain this information, then there should be a warning issued that the implementation has performed a minor transgression of the specification.
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.
Construct a test which consists of sending 2 request messages representing the same data, but different serializations. Expect the same response back.
No test designed for this assertion yet!
Each graph edge is encoded as an element information item and each element information item represents a graph edge.
All tests that use soap encoding will test this assertion.
Test for this should be covered in ASK2
No test designed for this assertion yet!
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), 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".
Implementations should be tested to ensure that they understand multi-reference values.
Construct two tests to have a multiref simple (int?) and a multiref compound value echoed back by a soap node using the RPC convention
No test designed for this assertion yet!
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.
Implementations should be tested to ensure that they understand simple values.
A variety of types should be used.
SB tests are pretty extensive.
Do we want a test for every simple type in the XML Schema specification?
SB (soapbuilder) tests are pretty extensive.
No test designed for this assertion yet!
SBR1 tests: SBR1 echoString; SBR1 echoInteger; SBR1 echoFloat; SBR1 echoBase64; SBR1 echoDate
SBR2A tests: SBR2 echoString; SBR2 echoInteger; SBR2 echoFloat; SBR2 echoBase64; SBR2 echoDate; SBR2 echoDecimal; SBR2 echoBoolean
SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct
No test designed for this assertion yet!
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).
All tests that that test compound types will test this assertion.
Construct a test for a compound value (structure) with unqualified and qualified names. SB tests are pretty extensive. Array changes of course need to be added to the SB tests.
No test designed for this assertion yet!
SBR1 tests:SBR1 echoStruct; SBR1 echoStructArray SBR2A tests: SBR2 echoStruct; SBR2 echoStructArray SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct; SBR2 echoNestedStruct; SBR2 echoNestedArrayFor 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).
SB tests pretty extensive.
No test designed for this assertion yet!
SBR1 tests:SBR1 echoStruct; SBR1 echoStructArray
SBR2A tests: SBR2 echoStruct; SBR2 echoStructArray
SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct; SBR2 echoNestedStruct; SBR2 echoNestedArray
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.
Implementations should be tested to ensure that they understand arrays.
SB tests pretty extensive.
Construct a test which has an encoded array (say of int) with elements of the array having accessors with different names: such as "itemA" "itemB". Have a SOAP node echo the same array back.
No test designed for this assertion yet!
SBR1 tests: SBR1 echoStringArray; SBR1 echoIntegerArray; SBR1 echoFloatArray; SBR1 echoStructArray
SBR2A tests: SBR2 echoStringArray; SBR2 echoIntegerArray; SBR2 echoFloatArray; SBR2 echoStructArray
SBR2B tests: SBR2 echo2DStringArray; SBR2 echoNestedArray
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).
Identify which tests test this assertion.
Test for assertion ASK10 should cover this. A negative test can be constructed to have an array without the arrayType attribute and have the SOAP node return a fault (rpc:BadArguments?)
No test designed for this assertion yet!
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.
No test designed for this assertion yet!
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.
Should be tested every time a response is received from the SOAP node tested.
Construct 2 tests one which uses xsi:type for a serialized type and one which does not but with a corresponding XML Schema. The first test that uses xsi:type should create serialized data using element names that have no relation to the type of the element (expressed by the value of the attribute xsi:type).
This assertion allows elements to have names which are not identical to the type of the contained value. Case (1) and (3) are covered by ASK2. Case (2) is covered by ASK12 and ASK13
No test designed for this assertion yet!
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.
No test designed for this assertion yet!
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".
No test designed for this assertion yet!
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.
No test designed for this assertion yet!
The value of a ref attribute information item MUST also be the value of exactly one id attribute information item.
Two tests can be constructed for this assertion (positive and negative)
No test designed for this assertion yet!
A ref attribute information item and an id attribute information item MUST NOT appear on the same element information item.
No test designed for this assertion yet!
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 "*"
No test designed for this assertion yet!
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.
No test designed for this assertion yet!
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.
Difficult to test since it allows any encoding to be used. A test would have to utilize a specific alternate encoding, which a given implementation might not support. A reference implementation could test the validity of the concept by supporting an alternate encoding.
Construct a test for literal encoding.
No test designed for this assertion yet!
However, use of the SOAP RPC Representation is not limited to the SOAP HTTP Binding (see 7. SOAP HTTP Binding).
No test designed for this assertion yet!
RPC invocations and responses are both carried in the SOAP Body element (see [1] section 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 is named identically to the procedure or method name (see A. Mapping Application Defined Names to XML Names).
- Each outbound edge 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.
- 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. The return value outbound edge SHOULD be the first outbound edge.
- Each outbound edge 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. The label of the return value outbound edge is "result" and it is namespace-qualified with the namespace name "http://www.w3.org/2001/12/soap-rpc". The return value outbound edge MUST be present if the return value of the procedure is non-void. The return value outbound edge MUST NOT be present if the return value of the procedure is void.
Invocation faults are handled according to the rules in 4.3 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.
No test designed for this assertion yet!
Applications MAY process invocations with missing parameters but also MAY RPC response to contain both a result and a fault.
Because a result indicates success and a fault indicates failure, it is an error for an RPC response to contain both a result and a fault.
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in 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): 1. 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. 2. 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. 3. A fault with a Value of "env:Sender" for Code and a Value of "rpc:ProcedureNotPresent" for Subcode MUST be generated when the receiver does not support the procedure or method specified. (used to be Assertion 4.3.140) 4. 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. (used to be Assertion 4.3.141) 5. Other faults arising in an extension or from the application SHOULD be generated as described in Part 1 [1] section SOAP Faults.
Section 5 of Part 2 of the SOAP 1.2 specification provides an introduction to the concepts of features and properties as used by the transport binding framework. Sections 6 and 7 follow this introduction by describing a normative message exchange pattern (mep) for a simple request-response scenario and an instance of a protocol binding, respectively. Viewed from a testing standpoint, the subject matter treated in these sections varies considerably from that which has gone before. Tests for the content of sections 5-7 examine the metadata that is associated with an exchange, rather than the messages themselves. This means that cataloguing sample message content is not relevant for testing sections 5-7.
Exchange Metadata TestingSection 5 describes two forms of message exchange metadata
The specification sets the properties defined by the environment to be out of scope for normative description, with the caveat that those properties must conform to correct property form.
Testing the Transport Message Exchange ContextThere are two prerequisites to make the transport message exchange context (the container of the exchange metadata) testable. Firstly, the context must be *publicly accessible* by api so that it may be inspected and altered to create suitable test conditions. Secondly, the SOAP 1.2 node state machines that are described in section 6 must also be publicly accessible by API so that they may be 'driven' by a suitable test harness.
The test assertions for sections 5-7 are constructed using a simplified notation that is intended to illustrate suitable provisions for assertions 3 and 4 above. The notation is not intended to prejudice any particular implementation of such APIs.
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 that introduces the property.
No explicit text.
No explicit text.
The reference is Table 1, section 6.1
This message exchange pattern is named by the URI 'http://www.w3.org/2001/12/soap/mep/single-request-response/'
Instantiation of a Message Exchange Context for a Requesting SOAP Node.
Instantiation of a Message Exchange Context for an inbound Request Message.
Requesting SOAP Node State Transition Table
Requesting Node State Transition Table
Requesting Node State Transition Table
Requesting Node State Transition Table
Responding SOAP Node State Transition Table
Responding Node State Transition Table
Responding Node State Transition Table
Section 7 covers the binding of SOAP to HTTP and associated state machine, state transitions, properties and their values, and status codes for successful and failed message exchanges. It covers SOAP and HTTP fault and status code mappings. There are certain features external to the SOAP message which should be tested. In particular, the client-side and server-side usage of the SOAPAction feature and properties.
There will be three main areas to be tested.
1. State Machine States and Transitions
2. Fault Handling - Testing of Fail Codes - SOAP Fault to HTTP Mapping
3. Features External to the Message Envelope - SOAPAction
HTTP applications MUST use the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges. See [12] for parameters defined by this media type and their recommended use.
Test that text/xml SOAP data is processed for an HTTP request.
Check that HTTP response containing a SOAP message is using the correct media type.
No test designed for this assertion yet!
Use of the SOAP HTTP Binding is optional; nothing precludes the specification of different bindings to other protocols or other bindings to HTTP. Because of the optionality of using the SOAP HTTP Binding, it is NOT a requirement to implement it as part of a SOAP node. A node that does correctly and completely implement the HTTP binding may to be said to "conform to the SOAP 1.2 HTTP binding."
No test designed for this assertion yet!
An implementation of the SOAP HTTP Binding MUST support the following message exchange pattern:
"http://www.w3.org/2001/12/soap/mep/single-request-response/" (see 6.2 Single-Request-Response MEP)
If HTTP is the binding used for the tests, this will be verified at each tests. Maybe check that SOAP message is correctly embedded (Host header, Content-Length, etc). HTTP/1.1 validity?
No test designed for this assertion yet!
State Description: Requesting
No test designed for this assertion yet!
State Description: Waiting
No test designed for this assertion yet!
HTTP Status Codes Dependent Transitions
No test designed for this assertion yet!
State Description: Receiving
No test designed for this assertion yet!
State Description: Responding
No test designed for this assertion yet!
State Description: Processing
No test designed for this assertion yet!
This underlying protocol binding specification defines a binding specific expression for the following features:
"http://www.w3.org/2001/12/soap/bindings/HTTP/SOAPAction/"
Other features that are compatible with the message exchange patterns listed above are supported using their generic in-envelope expression defined in the relevant feature specification.
No test designed for this assertion yet!
Use of the SOAP Action feature is OPTIONAL. SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD NOT require its presence in order to operate. Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receiver specifies its use).
The syntax for the SOAPAction and Required-SOAPAction HTTP headers fields is defined as follows: SOAP Action HTTP Header [4] soapaction ::= "SOAPAction" ":" URI-reference [5] URI-reference ::= as defined in RFC2396
No test designed for this assertion yet!
No tests designed for this assertion yet!Required SOAP Action HTTP Header [6] req-soapaction ::= "required-SOAPAction" ":" " URI-reference "
No test designed for this assertion yet!
No tests designed for this assertion yet!Appendix A lists rules to convert a application defined name to an XML name
No test designed for this assertion yet!
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.
A test will not be created for this assertion.
No test designed for this assertion yet!
No test designed for this assertion yet!
The following tests use the 3 SOAP nodes. No other SOAP nodes must be used in communication between these 3 SOAP nodes.
NodeA, NodeB and NodeC implement some mechanizm for routing so that the following messaging scenarios are allowed:
NodeC message processing:
then NodeC replies with the test:responseOk header block:
stringNodeB message processing:
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 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
No test designed for this assertion yet!
The following tests use the 2 SOAP nodes. No other SOAP nodes must be used in communication between these 2 SOAP nodes.
NodeC processing model is similar to the one in section 2,
then NodeC replies with the test:responseOk element in the Body:
Message sent from Node A
Message sent from Node C
No test designed for this assertion yet!
The following tests use the 2 SOAP nodes. No other SOAP nodes must be used in communication between these 2 SOAP nodes.
NodeC processing model is similar to the one in section 2,
then NodeC replies with the test:responseOk element in the Body:
stringMessage 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
Message sent from Node
Message sent from Node
Message sent from Node
Message sent from Node
Message sent from Node
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
Message sent from Node
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 people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.