Copyright ©2001 W3C®(MIT,INRIA,Keio), All Rights Reserved. W3C liability,trademark,document use and software licensing rules apply.
This document attempts to draw a list of testable assertions found in the SOAP Version 1.2 specification.
The goal is to get a list of features whose implementation can be tested in order to satisfy the entrance criteria of the Proposed Recommendation stage.
See the XMLP conformance issues for some background information.
Foreword: this version of the document is very rough. Stay tuned.
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 9th July 2001 Working Draft of the SOAP Version 1.2 specification. Please refer to the latest SOAP Version 1.2 Working Draft for any current normative information.
Currently, the tests proposed are just ideas, without many details.
The document now lists the SOAPBuilders Interoperability tests.
Please send comments on this document to xml-dist-app@w3.org (public archive), especially if something is missing from this list.
This section reproduces the structure of the SOAP Version 1.2 Working Draft.
In order to make this document evolve nicely and easily, some information should probably be enclosed in the mark-up of the specification. In any case, changes in working drafts should be reviewed in order to keep this list up-to-date.
Assertions are given a unique number. Should assertions be modified, the assertion number will be changed so that tests can be easily named.
A means assertion. Tests will probably have to be numbered as well.
SOAPBuilders interoperability tests 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.
The tests assume some sort of communication with a SOAP node. Since an HTTP binding will be defined, this seems like a good candidate. It will also mostly rely on RPCs.
Note that the envelope, the encoding, the RPC and the HTTP binding parts are orthogonal. The list of assertions and tests is not a list of things that every implementation needs to comply with. However, there are groups that should be formed (4 groups, 1 for each component).
Tests for the encoding part could mostly be done by type transformation, echoing back some parts of the information received, etc.
Section 2.1: SOAP Nodes
A SOAP node receiving a SOAP message MUST perform processing, generate SOAP faults, SOAP responses, and if appropriate send additional SOAP messages, as provided by the remainder of this specification.
A SOAP node must react to something sent to it. Redundant with the rest of the test.
None proposed.
Section 2.2: SOAP Actors and SOAP Nodes
Each SOAP node MUST act in the role of the special SOAP actor named "http://www.w3.org/2001/06/soap-envelope/actor/next", and can additionally assume the roles of zero or more other SOAP actors.
Other header blocks with unrecognized values for the actor attribute must be ignored.
SB tests do not cover the case of the URI of the node, they only cover the .../next URI case.
Test .../next
Test the URI for the node.
Test with another (random) URI.
SBR2C tests: SBR2 echoMeStringRequest which uses mustUnderstand="0"; SBR2 echoMeStructRequest which uses mustUnderstand="1"; SBR2 unknown header entry which uses a combination of both.
Section 2.2: SOAP Actors and SOAP Nodes
A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor.
Another similar assertion later?
Pretty much any RPC test is redundant with this.
Use untargetted (targetted for the ultimate receiver) blocks.
SBR1 tests; SBR2A tests; SBR2B tests
Section 2.4: Understanding SOAP Headers
When a SOAP header block is tagged with a SOAP mustUnderstand attribute with a value of "1", the targeted SOAP node MUST: either process the SOAP block according to the semantics conveyed by the fully qualified name of the outer-most element of that block; or not process the SOAP message at all, and fail.
Check how A4, A5 and A6 are related (in the spec, and for the tests).
Send an understandable mustUnderstand block.
Send an ununderstandable (??) mustUnderstand block.
SB tests: check A5 and A6.
Section 2.5: Processing SOAP Messages
Generate a single SOAP mustUnderstand fault if one or more SOAP blocks targeted at the SOAP node carry the attribute env:mustUnderstand="1" and are not understood by that node. If such a fault is generated, any further processing MUST NOT be done.
Some commonality with A4.
Send one not understandable mustUnderstand block.
Send several not understandable mustUnderstand block.
Check processing and the fault returned.
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
Section 2.5: Processing SOAP Messages
A SOAP node MUST process SOAP blocks identified as env:mustUnderstand="1".
Some commonality with A4.
SB tests should cover this.
Send one mustUnderstand block.
Send several mustUnderstand blocks.
Check that they are processed.
SBR2C tests: SBR2 echoMeStructRequest sends an understandable header with mustUnderstand="1".
Section 2.5: Processing SOAP Messages
[Intermediary role discussion] Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored).
Check that a SOAP node behaves correctly as an intermediary.
Check that the targeted blocks (both with .../next and a particular URI) are removed.
Check that all the others are present in the original order (use IDs to distinguish them).
Section 2.5: Processing SOAP Messages
MUST discard messages that have incorrect namespaces (see section 4.4) and it MAY process SOAP messages without SOAP namespaces as though they had the correct SOAP namespaces.
None.
Send a message with an unknown namespace.
Send a message without any namespace.
Section 4: SOAP Envelope
The introduction of section 4 explains the structure of a SOAP message.
The structure of the envelope could be checked on every test, and this would not require an extra test.
@@@
Section 4.1.2: Envelope Versioning Model
A SOAP message MUST contain a SOAP envelope associated with the "http://www.w3.org/2001/06/soap-envelope" namespace. If a SOAP message is received by a SOAP node in which the SOAP envelope is associated with a different namespace, the SOAP node MUST treat this as a version error and generate a VersionMismatch SOAP fault (see section 4.4). A SOAP VersionMismatch fault message MUST use the SOAP/1.1 envelope namespace "http://schemas.xmlsoap.org/soap/envelope/" (see Appendix C).
None.
Send a message with a different namespace.
Section 4.2: SOAP Header
A SOAP header block is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the SOAP Header MUST be namespace-qualified.
As for DA9, the syntax should be checked at every test.
@@@
Section 4.2.1: Use of Header Attributes
A SOAP receiver MUST ignore all SOAP Header attributes that are not applied to an immediate child element of the SOAP Header.
None.
Send a message with the actor and mustUnderstand attributes randomly located on elements.
Section 4.2.2:SOAP actor Attribute
Note that this section has redundant information and hence redundant assertions.
This [actor] attribute MUST appear in the SOAP message itself in order to be effective, and not in an eventual corresponding XML Schema (see section 3 and 4.2.1).
Application specific; not testable.
@@@
Section 4.2.3:SOAP mustUnderstand Attribute
Note that this section has redundant information and hence redundant assertions.
This [mustUnderstand] attribute MUST appear in the SOAP message itself in order to be effective, and not in an eventual corresponding XML Schema (see section 3 and 4.2.1).
Application specific; not testable.
@@@
Section 4.4: SOAP Fault
If present, the SOAP fault MUST appear as a SOAP body block and MUST NOT appear more than once within a SOAP Body.
This should be tested in every scenario in which a fault is expected.
@@@
Section 4.4 describes the structure of a fault element, plus:
[The detail element] 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.
This should be tested in every scenario in which a fault is expected.
Additional test: check that details about a fault in a header isn't carried in the detail element but in header blocks.
Section 4.4.1: SOAP Fault Codes
Section 4.4.1: SOAP Fault Codes
The SOAP faultcode values defined in this section MUST be used in the SOAP faultcode element when describing faults defined by this specification.
None.
Trigger a number of faults and check that the appropriate faultcode is used.
Section 4.4.2: MustUnderstand Faults
Section 4.4.2 defines the syntax of a mustUnderstand fault, i.e. the syntax of the Misunderstood element.
The syntax could be tested. However, this error reporting mechanism is not mandatory. The syntax should be tested when faults are generated, if this is the case that the Misunderstood element is used.
@@@
Section 5.1: Rules for Encoding Types in XML
All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element.
None.
@@@
Section 5.1: Rules for Encoding Types in XML
For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an xsi:type attribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted) enc:arrayType attribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.
Should be tested every time a response is received from the SOAP node tested.
@@@
Section 5.2: Simple Types
Section 5.1 and section 5.2 define simple values.
All simple values MUST be encoded as the content of elements whose type is either defined in "XML Schema Part 2: Datatypes" Specification [11], or is based on a type found there by using the mechanisms provided in the XML Schema specification.
Implementations should be tested to ensure that they understand simple values.
A variety of types should be used, including the examples found in the SOAP Version 1.2 specification (subsections of section 5.2).
SB tests are pretty extensive.
@@@
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
Section 5.3: Compound Types
A polymorphic accessor instance MUST contain an "xsi:type" attribute that describes the type of the actual value.
Not sure what/how to test that.
@@@
Section 5.4: Compound Types
Section 5.4.1: Compound Values, Structs and References to Values
Section 5.1 and section 5.4 & 5.4.1 define compound values.
A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
Implementations should be tested to ensure that they understand compound values.
SB tests pretty extensive.
@@@
SBR1 tests:SBR1 echoStruct; SBR1 echoStructArray
SBR2A tests: SBR2 echoStruct; SBR2 echoStructArray
SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct; SBR2 echoNestedStruct; SBR2 echoNestedArray
Section 5.4: Compound Types
Section 5.4.1: Compound Values, Structs and References to Values
Sections 5.1 and 5.4.1 define multi-reference values.
Implementations should be tested to ensure that they understand multi-reference values.
@@@
Section 5.4: Compound Types
Section 5.4.2: Arrays
Sections 5.1 and 5.4.2 define arrays.
Implementations should be tested to ensure that they understand arrays.
SB tests pretty extensive.
@@@
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
Section 5.4.2.1: Partially Transmitted Arrays
A partially transmitted array indicates in an "enc:offset" attribute the zero-origin offset of the first element transmitted.
Test the understanding of the enc:offset attribute.
@@@
Section 5.4.2.2: Sparse Arrays
Each element representing a member value contains a "enc:position" attribute that indicates its position within the array.
Test the understanding of the enc:position attribute.
@@@
Section 6: Using SOAP in HTTP
HTTP applications MUST use the media type "text/xml" according to RFC 2376 [3] when including SOAP messages in HTTP exchanges.
None.
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.
Section 6.1: SOAP HTTP Request
this binding only defines SOAP within HTTP POST requests
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?
@@@
Section 6.1.1: The SOAPAction HTTP Header Field
The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
Again, probably on all tests, check presence of SOAPAction.
@@@
Section 6.2: SOAP HTTP Response
If an error occurs while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP fault (see section 4.4) indicating the SOAP processing error.
Check with scenarios causing an error.
@@@
Section 7.1: RPC and SOAP Body
Section 7.1 states the rules for RPCs.
Most of the tests will use RPCs, so the syntax of the response should be tested.
SB tests make use of this.
@@@
SBR1 tests; a particular case is tested by SBR1 echoVoid (no arguments in nor out).
SBR2 tests; a particular case is tested by SBR2 echoVoid (no arguments in nor out).
Section 7.2: RPC and SOAP Header
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in the RPC encoding. If so, it MUST be expressed as a header block.
None.
Send an RPC with some extra information in a header block.