SOAP Version 1.2 specification testable assertions

Version: $Id: spec-ta.html,v 1.14 2001/09/25 20:19:27 hugo Exp $

Maintainer
Hugo Haas (W3C)
This document is out-of-date. The latest version can be found at:
http://www.w3.org/2000/xp/Group/1/09/ts

Copyright 2001 W3C(MIT,INRIA,Keio), All Rights Reserved. W3C liability,trademark,document use and software licensing rules apply.


Abstract

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.

Status of this Document

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.

List of testable assertions

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.

A1

References

Section 2.1: SOAP Nodes

Assertion

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.

Comment

A SOAP node must react to something sent to it. Redundant with the rest of the test.

Test

None proposed.

A2

References

Section 2.2: SOAP Actors and SOAP Nodes

Assertion

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.

Comment

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

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.

A3

References

Section 2.2: SOAP Actors and SOAP Nodes

Assertion

A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor.

Comment

Another similar assertion later?

Pretty much any RPC test is redundant with this.

Test

Use untargetted (targetted for the ultimate receiver) blocks.

SBR1 tests; SBR2A tests; SBR2B tests

A4

References

Section 2.4: Understanding SOAP Headers

Assertion

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.

Comment

Check how A4, A5 and A6 are related (in the spec, and for the tests).

Test

Send an understandable mustUnderstand block.

Send an ununderstandable (??) mustUnderstand block.

SB tests: check A5 and A6.

A5

References

Section 2.5: Processing SOAP Messages

Assertion

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.

Comment

Some commonality with A4.

Test

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

A6

References

Section 2.5: Processing SOAP Messages

Assertion

A SOAP node MUST process SOAP blocks identified as env:mustUnderstand="1".

Comment

Some commonality with A4.

SB tests should cover this.

Test

Send one mustUnderstand block.

Send several mustUnderstand blocks.

Check that they are processed.

SBR2C tests: SBR2 echoMeStructRequest sends an understandable header with mustUnderstand="1".

A7

References

Section 2.5: Processing SOAP Messages

Assertion

[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).

Comment

Check that a SOAP node behaves correctly as an intermediary.

Test

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).

A8

References

Section 2.5: Processing SOAP Messages

Assertion

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.

Comment

None.

Test

Send a message with an unknown namespace.

Send a message without any namespace.

A9

References

Section 4: SOAP Envelope

Assertion

The introduction of section 4 explains the structure of a SOAP message.

Comment

The structure of the envelope could be checked on every test, and this would not require an extra test.

Test

@@@

A10

References

Section 4.1.2: Envelope Versioning Model

Assertion

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).

Comment

None.

Test

Send a message with a different namespace.

A11

References

Section 4.2: SOAP Header

Assertion

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.

Comment

As for DA9, the syntax should be checked at every test.

Test

@@@

A12

References

Section 4.2.1: Use of Header Attributes

Assertion

A SOAP receiver MUST ignore all SOAP Header attributes that are not applied to an immediate child element of the SOAP Header.

Comment

None.

Test

Send a message with the actor and mustUnderstand attributes randomly located on elements.

A13

References

Section 4.2.2:SOAP actor Attribute

Note that this section has redundant information and hence redundant assertions.

Assertion

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).

Comment

Application specific; not testable.

Test

@@@

A14

References

Section 4.2.3:SOAP mustUnderstand Attribute

Note that this section has redundant information and hence redundant assertions.

Assertion

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).

Comment

Application specific; not testable.

Test

@@@

A15

References

Section 4.4: SOAP Fault

Assertion

If present, the SOAP fault MUST appear as a SOAP body block and MUST NOT appear more than once within a SOAP Body.

Comment

This should be tested in every scenario in which a fault is expected.

Test

@@@

A16

Assertion

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.

Comment

This should be tested in every scenario in which a fault is expected.

Test

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

A17

References

Section 4.4.1: SOAP Fault Codes

Assertion

The SOAP faultcode values defined in this section MUST be used in the SOAP faultcode element when describing faults defined by this specification.

Comment

None.

Test

Trigger a number of faults and check that the appropriate faultcode is used.

A18

References

Section 4.4.2: MustUnderstand Faults

Assertion

Section 4.4.2 defines the syntax of a mustUnderstand fault, i.e. the syntax of the Misunderstood element.

Comment

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.

Test

@@@

A19

References

Section 5.1: Rules for Encoding Types in XML

Assertion

All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element.

Comment

None.

Test

@@@

A20

References

Section 5.1: Rules for Encoding Types in XML

Assertion

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.

Comment

Should be tested every time a response is received from the SOAP node tested.

Test

@@@

A21

References

Section 5.2: Simple Types

Assertion

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.

Comment

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.

Test

@@@

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

A25

References

Section 5.3: Compound Types

Assertion

A polymorphic accessor instance MUST contain an "xsi:type" attribute that describes the type of the actual value.

Comment

Not sure what/how to test that.

Test

@@@

A22

References

Section 5.4: Compound Types

Section 5.4.1: Compound Values, Structs and References to Values

Assertion

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.

Comment

Implementations should be tested to ensure that they understand compound values.

SB tests pretty extensive.

Test

@@@

SBR1 tests:SBR1 echoStruct; SBR1 echoStructArray

SBR2A tests: SBR2 echoStruct; SBR2 echoStructArray

SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct; SBR2 echoNestedStruct; SBR2 echoNestedArray

A23

References

Section 5.4: Compound Types

Section 5.4.1: Compound Values, Structs and References to Values

Assertion

Sections 5.1 and 5.4.1 define multi-reference values.

Comment

Implementations should be tested to ensure that they understand multi-reference values.

Test

@@@

A24

References

Section 5.4: Compound Types

Section 5.4.2: Arrays

Assertion

Sections 5.1 and 5.4.2 define arrays.

Comment

Implementations should be tested to ensure that they understand arrays.

SB tests pretty extensive.

Test

@@@

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

A26

References

Section 5.4.2.1: Partially Transmitted Arrays

Assertion

A partially transmitted array indicates in an "enc:offset" attribute the zero-origin offset of the first element transmitted.

Comment

Test the understanding of the enc:offset attribute.

Test

@@@

A27

References

Section 5.4.2.2: Sparse Arrays

Assertion

Each element representing a member value contains a "enc:position" attribute that indicates its position within the array.

Comment

Test the understanding of the enc:position attribute.

Test

@@@

A29

References

Section 6: Using SOAP in HTTP

Assertion

HTTP applications MUST use the media type "text/xml" according to RFC 2376 [3] when including SOAP messages in HTTP exchanges.

Comment

None.

Test

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.

A30

References

Section 6.1: SOAP HTTP Request

Assertion

this binding only defines SOAP within HTTP POST requests

Comment

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?

Test

@@@

A28

References

Section 6.1.1: The SOAPAction HTTP Header Field

Assertion

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.

Comment

Again, probably on all tests, check presence of SOAPAction.

Test

@@@

A31

References

Section 6.2: SOAP HTTP Response

Assertion

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.

Comment

Check with scenarios causing an error.

Test

@@@

A32

References

Section 7.1: RPC and SOAP Body

Assertion

Section 7.1 states the rules for RPCs.

Comment

Most of the tests will use RPCs, so the syntax of the response should be tested.

SB tests make use of this.

Test

@@@

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).

A33

References

Section 7.2: RPC and SOAP Header

Assertion

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.

Comment

None.

Test

Send an RPC with some extra information in a header block.

Changelog

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.

Valid XHTML 1.0! Valid CSS!