SOAP Version 1.2 Specification Assertions and Test Collection (Second Edition)

Text from the specification

For an implementation to claim conformance with the SOAP Version 1.2 specification, it MUST correctly implement all mandatory ("MUST") requirements expressed in Part 1 of the SOAP Version 1.2 specification (this document) that pertain to the activity being performed. Note that an implementation is not mandated to implement all the mandatory requirements.

Comments

This statement applies to all assertions and as such will not be tested separately.

Text from the specification

The implementation of an Adjunct MUST implement all the pertinent mandatory requirements expressed in the specification of the Adjunct to claim conformance with the Adjunct.

Comments

This statement applies to all assertions in part 2 and as such will not be tested separately.

Text from the specification

SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by Parts 1 and 2 of this specification. The values associated with element and attribute information items defined in this specification MUST be carried explicitly in the transmitted SOAP message except where stated otherwise (see 5. SOAP Message Construct).

Comments

This assertion will not be tested.

Text from the specification

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, e.g. the boolean lexical forms "1" and "true" are interchangeable.

Comments

This assertion will not be tested.

Text from the specification

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.

Comments

This assertion is tested by the entire test collection.

Text from the specification

The roles assumed by a node MUST be invariant during the processing of an individual SOAP message.

Comments

This assertion cannot be fully tested, as a SOAP node is allowed to process and remove SOAP headers, reinsert them and send them upstream.

Tests

Text from the specification

Table 2: SOAP Roles defined by this specification, row 1

Tests

Text from the specification

Table 2: SOAP Roles defined by this specification, row 2

Tests

Text from the specification

Table 2: SOAP Roles defined by this specification, row 3

Tests

Text from the specification

Mandatory SOAP header blocks are presumed to somehow modify the semantics of other SOAP header blocks or SOAP body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).

Comments

All tests in the test collection that use mustUnderstand attribute with a value of true/1 will test this assertion.

Text from the specification

In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory SOAP header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver.

Tests

Text from the specification

An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body).

Comments

All tests in the test collection that have body block(s).

Text from the specification

Unless otherwise stated, processing of all generated SOAP messages, SOAP faults and application-level side effects MUST be semantically equivalent to performing the following steps separately, and in the order given.

1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any SOAP header blocks and the SOAP body, MAY be inspected in making such determination.

2. Identify all header blocks targeted at the node that are mandatory.

3. If one or more of the SOAP header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with the Value of Code set to "env:MustUnderstand" (see 5.4.8 SOAP mustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the SOAP body MUST NOT be generated in this step.

   Note:

   Throughout this document, the term "Value of Code " is used as a shorthand for "value of the Value child element information item of the Code element information item" (see 5.4.1 SOAP Code Element).

4. Process all mandatory SOAP header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node MAY also choose to process non-mandatory SOAP header blocks targeted at it.

5. In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message as described in section 2.7 Relaying SOAP Messages.

Comments

All tests in the test collection test this assertion.

Text from the specification

In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block.

Comments

All tests in the test collection that process a soap header without generating a fault, test this assertion.

Text from the specification

An ultimate SOAP receiver MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.

Comments

All tests in the test collection that have body block(s) test this assertion.

Text from the specification

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.

Comments

All tests in the test collection that generate a fault test this assertion.

Text from the specification

The selection of a fault need not be predicated on the application of the "MUST", "SHOULD" or "MAY" keywords to the generation of the fault, with the exception that if one or more of the prescribed faults is qualified with the "MUST" keyword, then any one fault from the set of possible faults MUST be generated.

Comments

This assertion will not be tested.

Text from the specification

Table 3: SOAP Nodes Forwarding behavior

Text from the specification

Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. In addition, when generating a SOAP message for the purpose of forwarding, they MUST:

1. Remove all processed SOAP header blocks.

2. Remove all non-relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.

3. Retain all relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.

Comments

All tests in the test collection that use Node B.

Text from the specification

Forwarding SOAP 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.

Comments

This assertion will not be tested.

Text from the specification

All XML infoset properties of a message MUST be preserved with the following exceptions:

1. The element information item for a header block targeted at an intermediary MAY be removed, by that intermediary, from the [children] property of the SOAP Header element information item as detailed in 2.7.2 SOAP Forwarding Intermediaries.

2. Element information items for additional header blocks MAY be added to the [children] property of the SOAP Header element information item as detailed in 2.7.2 SOAP Forwarding Intermediaries.

3. Whitespace character information items MAY be removed from the [children] property of the SOAP Envelope element information item.

4. Whitespace character information items MAY be added to the [children] property of the SOAP Envelope element information item.

5. Whitespace character information items MAY be removed from the [children] property of the SOAP Header element information item.

6. Whitespace character information items MAY be added to the [children] property of the SOAP Header element information item.

7. Comment information items MAY be added to the [children] property of the SOAP Envelope element information item.

8. Comment information items MAY be removed from the [children] property of the SOAP Envelope element information item.

9. Comment information items MAY be added to the [children] property of the SOAP Header element information item.

10. Comment information items MAY be removed from the [children] property of the SOAP Header element information item.

11. Attribute information items MAY be added to the [attributes] property of the SOAP Envelope element information item.

12. Attribute information items MAY be added to the [attributes] property of the SOAP Header element information item.

13. Attribute information items MAY be added to the [namespace attributes] property of the SOAP Envelope element information item.

14. Attribute information items MAY be added to the [namespace attributes] property of the SOAP Header element information item.

15. SOAP role attribute information items that are present in the [attributes] property of SOAP header block element information items may be transformed as described in 5.2.2 SOAP role Attribute.

16. SOAP mustUnderstand attribute information items that are present in the [attributes] property of SOAP header block element information items may be transformed as described in 5.2.3 SOAP mustUnderstand Attribute.

17. SOAP relay attribute information items that are present in the [attributes] property of SOAP header block element information items may be transformed as described in 5.2.4 SOAP relay Attribute.

18. The [base URI] property of the document information item need not be maintained.

19. The [base URI] property of element information items MAY be changed or removed.

20. The [character encoding scheme] property of the document information item MAY be changed or removed.

21. All namespace information items in the [in-scope namespaces] of element information items MUST be preserved. Additional namespace information items MAY be added.

Comments

This assertion is partially tested by all tests that use Node B.

Text from the specification

A SOAP node determines whether it supports the version of a SOAP message on a per message basis.

Comments

This assertion will not be tested.

Text from the specification

A SOAP node MAY support multiple envelope versions. However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.

Tests

Text from the specification

If a SOAP node receives a message whose version is not supported it MUST generate a fault (see 5.4 SOAP Fault) with a Value of Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".

Tests

Text from the specification

The processing of SOAP envelopes in accordance with the SOAP Processing Model (see 2. SOAP Processing Model) MUST NOT be overridden by binding specifications.

Comments

This assertion will not be tested.

Text from the specification

The specification of a feature MUST include the following:

1. A URI used to name the feature. This enables the feature to be unambiguously referenced in description languages or during negotiation.

2. The information (state) required at each node to implement the feature.

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

4. The information to be transmitted from node to node.

Comments

This assertion will not be tested.

Text from the specification

The specification of a message exchange pattern MUST:

• As mandated by 3.1.1 Requirements on Features, provide a URI to name the MEP.

• Describe the life cycle of a message exchange conforming to the pattern.

• Describe the temporal/causal relationships, if any, of multiple messages exchanged in conformance with the pattern (e.g. responses follow requests and are sent to the originator of the request.)

• Describe the normal and abnormal termination of a message exchange conforming to the pattern.

Comments

This assertion will not be tested.

Text from the specification

MEPs are SOAP features, so an MEP specification MUST conform to the requirements for SOAP feature specifications (see 3.1.1 Requirements on Features).

Comments

Text from the specification

An MEP specification MUST also include:

1. Any requirements to generate additional messages (such as responses to requests in a request/response MEP).

2. Rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP.

Comments

This assertion will not be tested.

Text from the specification

A module specification adheres to the following rules. It:

1. MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation.

2. MUST declare the features provided by a module (see 3.1 SOAP Features).

3. MUST clearly and completely specify the content and semantics of the SOAP header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model. The SOAP extensibility model does not limit the extent to which SOAP can be extended. Nor does it prevent extensions from modifying the SOAP processing model from that described in 2. SOAP Processing Model

4. MAY utilize the property conventions defined in [SOAP Part2]Part 2], section A Convention for Describing Features and Bindings, in describing the functionality that the module provides. If these conventions are followed, the module specification MUST clearly describe the relationship between the abstract properties and their representations in the SOAP envelope. Note that it is possible to write a feature specification purely in terms of abstract properties, and then write a separate module specification which implements that feature, mapping the properties defined in the feature specification to SOAP header blocks in the SOAP module.

5. MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features and SOAP modules For example, we can imagine a module which encrypts and removes the SOAP body, inserting instead a SOAP header block containing a checksum and an indication of the encryption mechanism used. The specification for such a module would indicate that the decryption algorithm on the receiving side is to be run prior to any other modules which rely on the contents of the SOAP body.

Comments

This assertion will not be tested.

Text from the specification

A binding specification MUST enable one or more MEPs.

Comments

HTTP binding specified in SOAP 1.2 part 2 enables an MEP. This assertion will not be tested.

Text from the specification

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.

Comments

HTTP binding specified in SOAP 1.2 part 2 is an example of this assertion. This assertion will not be tested.

Text from the specification

Similarly, any dependencies of one feature on another (i.e. if successful use of one feature depends on use or non-use of another) MUST be specified.

Comments

HTTP binding specified in SOAP 1.2 part 2 is an example of this assertion. This assertion will not be tested.

Text from the specification

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.

Comments

This assertion will not be tested.

Text from the specification

Although streaming SOAP receivers will acquire such Infosets incrementally, SOAP processing MUST yield results identical to those that would have been achieved if the entire SOAP envelope were available prior to the start of processing.

Comments

This assertion will not be tested.

Text from the specification

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.

Comments

All tests in the test collection test this assertion.

Text from the specification

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.

Tests

Text from the specification

The XML infoset of a SOAP message MUST NOT contain a document type declaration information item.

Tests

Text from the specification

SOAP messages sent by initial SOAP senders MUST NOT contain processing instruction information items. SOAP intermediaries MUST NOT insert processing instruction information items in SOAP messages they relay. SOAP receivers receiving a SOAP message containing a processing instruction information item SHOULD generate a SOAP fault with the Value of Code set to "env:Sender".

Tests

Text from the specification

The SOAP Envelope element information item has:

• A [local name] of Envelope .

• A [namespace name] of "http://www.w3.org/2003/05/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:

  1. An optional Header element information item (see 5.2 SOAP Header).

  2. A mandatory Body element information item (see 5.3 SOAP Body).

Comments

All the tests in the test collection test this assertion.

Text from the specification

The encodingStyle attribute information item has:

• A [local name] of encodingStyle .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

The encodingStyle attribute information item is of type xs:anyURI.

Comments

All tests in the test collection that use encodingSytle attribute test this assertion.

Text from the specification

The encodingStyle attribute information item MAY appear on the following:

1. A SOAP header block (see 5.2.1 SOAP Header block).

2. A child element information item of the SOAP Body element information item (see 5.3.1 SOAP Body child Element) if that child is not a SOAP Fault element information item (see 5.4 SOAP Fault).

3. A child element information item of the SOAP Detail element information item (see 5.4.5.1 SOAP detail entry).

4. Any descendent of 1, 2, and 3 above.

The encodingStyle attribute information item MUST NOT appear on any element other than above in a SOAP message infoset.

Comments

All tests in the test collection that use encodingSytle attribute test this assertion.

Text from the specification

The scope of the encodingStyle attribute information item is that of its owner element information item and that element information item's descendants, unless a descendant itself carries such an attribute information item.

Tests

Text from the specification

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 "http://www.w3.org/2003/05/soap-envelope/encoding/none" then no claims are made regarding the encoding style of that element information item and its descendants.

Tests

Text from the specification

The Header element information item has:

• A [local name] of Header .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• Zero or more namespace qualified attribute information items in its [attributes] property.

• Zero or more namespace qualified element information items in its [children] property.

Comments

All the tests in the test collection that use headers, test this assertion.

Text from the specification

Each SOAP header block element information item:

• MUST have a [namespace name] property which has a value, that is the name of the element MUST be namespace qualified.

• MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

• MAY have any number of element information item children. Such element information items MAY be namespace qualified.

• MAY have zero or more attribute information items in its [attributes] property. Among these MAY be any or all of the following, which have special significance for SOAP processing:

  • encodingStyle attribute information item (see 5.1.1 SOAP encodingStyle Attribute ).

  • role attribute information item (see 5.2.2 SOAP role Attribute).

  • mustUnderstand attribute information item (see 5.2.3 SOAP mustUnderstand Attribute).

  • relay attribute information item (see 5.2.4 SOAP relay Attribute ).

Comments

All tests in the test collection that use headers, test this assertion.

Text from the specification

The role attribute information item has the following XML infoset properties:

• A [local name] of role .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• A [specified] property with a value of "true".

The type of the role attribute information item is xs:anyURI. The value of the role attribute information item is a URI that names a role that a SOAP node can assume.

Comments

All tests in the test collection that use roles, will test this assertion.

Text from the specification

Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver".

Tests

Text from the specification

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP role attribute information item with a value of "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver".

Tests

Text from the specification

A SOAP sender generating a SOAP message SHOULD use the role attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

Tests

T74

Text from the specification

The mustUnderstand attribute information item has the following XML infoset properties:

• A [local name] of mustUnderstand .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• A [specified] property with a value of "true".

The type of the mustUnderstand attribute information item is xs:boolean.

Comments

All tests in the test collection that use mustUnderstand attribute, test this assertion.

Text from the specification

Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".

Comments

'this' in the specification text refers to the mustUnderstand attribute information item.

Tests

Text from the specification

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP mustUnderstand attribute information item with a value of "false" or "0".

Tests

Text from the specification

A SOAP receiver MUST accept any valid lexical representation of the attribute value.

Comments

The attribute mentioned in the spec text refers to env:mustUnderstand.

Tests

Text from the specification

A SOAP sender generating a SOAP message SHOULD use the mustUnderstand attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

Comments

Text from the specification

The relay attribute information item has the following XML infoset properties:

• A [local name] of relay .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• A [specified] property with a value of "true".

The type of the relay attribute information item is xs:boolean.

Text from the specification

Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".

Text from the specification

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP relay attribute information item with a value of "false" or "0".

Text from the specification

A SOAP receiver MUST accept any valid lexical representation of the attribute value.

Text from the specification

A SOAP sender generating a SOAP message SHOULD use the relay attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

Text from the specification

The Body element information item has:

• A [local name] of Body .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• Zero or more namespace qualified attribute information items in its [attributes] property.

• Zero or more namespace qualified element information items in its [children] property.

Comments

All tests in the test collection that have the Body element, test this assertion.

Text from the specification

The Fault element information item has:

• A [local name] of Fault .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• Two or more child element information items in its [children] property in order as follows:

  1. A mandatory Code element information item (see 5.4.1 SOAP Code Element ).

  2. A mandatory Reason element information item (see 5.4.2 SOAP Reason Element ).

  3. An optional Node element information item (see 5.4.3 SOAP Node Element ).

  4. An optional Role element information item (see 5.4.4 SOAP Role Element ).

  5. An optional Detail element information item (see 5.4.5 SOAP Detail Element). ).

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child element information item of the SOAP Body .

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

When generating a fault, SOAP senders MUST NOT include additional element information items in the SOAP Body . A message whose Body contains a Fault plus additional element information items has no SOAP-defined semantics.

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

The Code element information item has:

• A [local name] of Code .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

• One or two child element information items in its [children] property, in order, as follows:

  1. A mandatory Value element information item as described below (see 5.4.1.1 SOAP Value element (with Code parent))

  2. An optional Subcode element information item as described below (see 5.4.1.2 SOAP Subcode element).

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

The Value element information item has:

• A [local name] of Value .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

The type of the Value element information item is env:faultCodeEnum.

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

The Subcode element information item has:

• A [local name] of Subcode .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

• One or two child element information items in its [children] property, in order, as follows:

  1. A mandatory Value element information item as described below (see 5.4.1.3 SOAP Value element (with Subcode parent)).

  2. An optional Subcode element information item (see 5.4.1.2 SOAP Subcode element).

Tests

Text from the specification

The Value element information item has:

• A [local name] of Value .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

The type of the Value element information item is xs:QName.

Tests

Text from the specification

The Reason element information item has:

• A [local name] of Reason .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

• One or more Text element information item children (see 5.4.2.1 SOAP Text Element). Each child Text element information item SHOULD have a different value for its xml:lang attribute information item.

The type of the Reason element information item is env:faultReason.

Comments

All tests in the test collection that generate fault, test this assertion.

Text from the specification

The Text element information item has:

• A [local name] of Text .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

• A mandatory attribute information item with a [local name] of lang and [namespace name] of "http://www.w3.org/XML/1998/namespace". Note that the definition in of the lang attribute information item requires that the [prefix] is "xml" or any capitalization thereof (see [XML 1.0], Language Identification).

• Any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

The type of the Text element information item is env:reasontext

Text from the specification

The Node element information item has:

• A [local name] of Node .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

The type of the Node element information item is xs:anyURI.

Tests

Text from the specification

SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item.

Comments

The element information item in the specification text refers to the 'Node' element.

Tests

Text from the specification

The Role element information item has:

• A [local name] of Role .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

The type of the Role element information item is xs:anyURI.

The value of the Role element information item MUST be one of the roles assumed by the node during processing of the message (see 2.2 SOAP Roles and SOAP Nodes).

Tests

Text from the specification

The Detail element information item has:

• A [local name] of Detail .

• A [namespace name] of http://www.w3.org/2003/05/soap-envelope .

• Zero or more attribute information items in its [attributes] property.

• Zero or more child element information items in its [children] property.

Tests

Text from the specification

A SOAP node MUST understand all SOAP fault codes in a SOAP fault message in order to be able to interpret the Detail element information item in a SOAP fault.

Comments

This assertion will not be tested

Text from the specification

The Upgrade element information item has:

• A [local name] of Upgrade .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• One or more SupportedEnvelope element information items in its [children] property in 5.4.7.2 SOAP SupportedEnvelope Element.

The Upgrade element information item MUST NOT have an encodingStyle attribute information item.

Tests

Text from the specification

The SupportedEnvelope element information item has:

• A [local name] of SupportedEnvelope .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• A qname attribute information item in its [attributes] property as described in 5.4.7.3 SOAP QName Attribute.

Tests

Text from the specification

The qname attribute information item has the following XML infoset properties:

• A [local name] of qname .

• A [namespace name] which has no value.

• A [specified] property with a value of "true".

The type of the qname attribute information item is xs:QName.

Tests

Text from the specification

Each NotUnderstood header block element information item has:

• A [local name] of NotUnderstood .

• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".

• A qname attribute information item in its [attributes] property as described in 5.4.8.2 SOAP QName Attribute.

The NotUnderstood element information item MUST NOT have an encodingStyle attribute information item.

Tests

Text from the specification

The qname attribute information item has the following XML infoset properties:

• A [local name] of qname .

• A [namespace name] which has no value.

• A [specified] property with a value of "true".

The type of the qname attribute information item is xs:QName.

Tests

Text from the specification

SOAP does not define a base URI but relies on the mechanisms defined in [XML Base] and [RFC 2396]3986] for establishing a base URI against which relative URIs can be made absolute.

Comments

seems to me that this assertion should be removed: ASK

Tests

Text from the specification

The use of IP addresses in URIs SHOULD be avoided whenever possible (see [RFC 1900]. However, when used, the literal format for IPv6 addresses in URIs as described by [RFC 2732]3986] SHOULD be supported.

Comments

seems to me that this assertion should be removed: ASK

Tests

Text from the specification

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.

Tests

Text from the specification

If a SOAP node supports versioning from SOAP 1.1 to SOAP 1.2, then the SOAP node MUST implement the rules described in this appendix.

The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:

1. 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/".

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 using a SOAP/1.1 binding to the underlying protocol (see [soap11] ).protocol. The SOAP fault SHOULD include an Upgrade SOAP 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.

Comments

The requirement on the behavior of SOAP 1.1 compliant SOAP node will not be tested by the test collection.

Tests

Text from the specification

A graph node whose outbound edges are distinguished solely