Copyright © @@ W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document draws on assertions found in the SOAP Version 1.2 specifications [SOAP Part1], [SOAP Part2], and provides a set of tests in order to show whether the assertions are implemented in a SOAP processor.
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, @@ @@ @@. It is incorrect to claim to be compliant with the SOAP Version 1.2 specifications merely by passing successfully all the tests provided in this test suite. It is also incorrect to claim that an implementation is non complaint with the SOAP Version 1.2 specifications based on its failure to pass one or more of the tests in this test suite.
This document is an editors' copy that has no official standing.
Editorial note: ASK | |
This document refers to SOAP 1.2 part 1 Editors SNAPSHOT
$Date: 2002/10/22 12:08:49 $ This document refers to SOAP 1.2 part 2 Editors SNAPSHOT $Date: 2002/10/22 12:08:49 $ |
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is the Last Call W3C Working Draft of the SOAP Version 1.2 Specification Assertions and Test Collection for review by by W3C members and other interested parties. It has been produced by the XML Protocol Working Group (WG), which is part of the Web Services Activity. This version is based on the @@ @@ @@ of the SOAP Version 1.2 Part 1 and Part 2 specifications. In the event of any discrepancy between the assertions in this document and Parts 1 and 2 of the specification, then the specification is considered to be authoritative.
The WG intends to publish this document as part of its eventual recommendation, to facilitate testing of SOAP implementations. In addition to soliciting feedback on its utility for that purpose, this document serves to identify the specific features of SOAP for which interoperable implementations will be shown prior to requesting Proposed Recommendation. The Working Group maintains a list of SOAP 1.2 implementations for the purpose of tracking implementation of these features.
Following completion of Last Call, the XML Protocol Working Group has agreed to advance the specification according to four exit criteria:
Sufficient reports of implementation experience have been gathered to demonstrate that SOAP processors based on the specification are implementable and have compatible behavior.
An implementation report shows that there are at least two different and interoperable implementations of every mandatory and optional feature.
Formal responses to all comments received by the Working Group.
If these criteria are met, the specification will advance to Proposed Recommendation. If the implementation exit criteria are not met then the specification will enter a Candidate Recommendation phase to ensure they are met.
A list of open Last Call issues against this document can be found at http://www.w3.org/2000/xp/Group/xmlp-lc-issues.
Comments on this document should be sent to xmlp-comments@w3.org (public archive [xmlp-comments archive]). It is inappropriate to send discussion email to this address. Comments should be sent during the last call review period, which ends 19 July 2002
Discussion of this document takes place on the public xml-dist-app@w3.org mailing list [distapp archive] under the email communication rules in the XML Protocol Working Group Charter [XMLP Charter].
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "works in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
1. Introduction
2. SOAP 1.2 Assertions
3. SOAP 1.2 Test Collection
4. References
A. Acknowledgements (Non-Normative)
B. Change Log (Non-Normative)
1. Introduction
2. SOAP 1.2 Assertions
2.1 SOAP 1.2, Part 1 Assertions
2.2 SOAP 1.2, Part 2 Assertions
3. SOAP 1.2 Test Collection
3.1 Introduction
3.2 Header Blocks Used by the Test Collection
3.2.1 echoOk
3.2.2 responseOk
3.2.3 Ignore
3.2.4 requiredHeader
3.2.5 DataHolder
3.2.6 concatAndForwardEchoOk
3.2.7 concatAndForwardEchoOkArg1
3.2.8 concatAndForwardEchoOkArg2
3.2.9 validateCountryCode
3.2.10 validateCountryCodeFault
3.2.11 echoResolvedRef
3.2.12 responseResolvedRef
3.3 Body Blocks Used by the Test Collection
3.3.1 echoOk
3.3.2 responseOk
3.3.3 echoHeader
3.3.4 echoHeaderResponse
3.4 RPC Methods/Procedures Used by the Test Collection
3.4.1 returnVoid
3.4.2 echoStruct
3.4.3 echoStructArray
3.4.4 echoStructAsSimpleTypes
3.4.5 echoStruct
3.4.6 echoNestedStruct
3.4.7 echoNestedArray
3.4.8 echoFloatArray
3.4.9 echoStringArray
3.4.10 echoIntegerArray
3.4.11 echoBase64
3.4.12 echoBoolean
3.4.13 echoDate
3.4.14 echoDecimal
3.4.15 echoFloat
3.4.16 echoString
3.4.17 countItems
3.4.18 echoBase64
3.5 Tests
4. References
4.1 Normative References
4.2 Informative References
A. Acknowledgements (Non-Normative)
B. Change Log (Non-Normative)
This document draws on assertions found in the SOAP Version 1.2 specifications, and provides a set of tests in order to show whether the assertions are implemented in a SOAP processor. The primary goal of this document is to foster interoperability between different SOAP 1.2 implementations. The document is intended to help implementors to write SOAP processors that comply with SOAP 1.2 specification, and interoperate with other SOAP processors that comply with SOAP 1.2 specification.
A SOAP 1.2 implementation that passes all of the tests specified in this document may claim to conform to the SOAP 1.2 Test Suite $Date @@/@@/@@ $.
Even though the purpose of the SOAP 1.2 Test Suite is to facilitate the creation of interoperable implementations, conformance to the SOAP 1.2 Test Suite does not imply conformance to the SOAP 1.2 specifications; there are mandatory requirements of the specifications that are not tested by the suite (as a simple example, SOAP 1.2 requires that every legal value of a role name is accepted, and all illegal ones rejected). An implementation may be said to be SOAP 1.2 conformant if and only if it it satisfies the conformance requirements specified in SOAP 1.2 specifications. The W3C does not at this time provide for any comprehensive means of testing for such conformance.
Similarly, an implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. SOAP 1.2 specifications admits special purpose implementations, such as those in dedicated controllers, which may send and receive only a very limited suite of messages; the requirement is that whatever is done be done correctly. An implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. The test suite defines higher level application semantics to enable testing and facilitate interoperable implementations. It is not necessary for a SOAP processor to support these higher level semantics to be SOAP 1.2 compliant.
Assertions for SOAP Version 1.2 Part 1 and Part 2 are numbered sequentially (1..n). "Location of the assertion" points the source of the assertion (section or subsection number) in Part 1 or Part 2. Hyperlinks are used to cross-reference to the original specification section/subsection.
Some of the tests in this document use SOAPBuilders interoperability tests as a started point, but have been modified to conform to the SOAP 1.2 specifications.
In particular, this document defines the following namespace names:
The SOAP envelope has the namespace name "http://www.w3.org/2002/06/soap-envelope" (see 5. SOAP Message Construct).
The SOAP Misunderstood element information item has the namespace name "http://www.w3.org/2002/06/soap-faults" (see 5.4.8 SOAP mustUnderstand Faults).
The SOAP Upgrade element information item has the namespace name "http://www.w3.org/2002/06/soap-upgrade" (see 5.4.7 VersionMismatch Faults).
Normative XML Schema [4], [5] documents for these namespace names can be found by dereferencing the namespace names above.
SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by this specification. The values associated with element and attribute information items defined in this specification MUST be carried explicitly in the transmitted SOAP message except where stated otherwise (see 5. SOAP Message Construct).
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.
The roles assumed by a node MUST be invariant during the processing of an individual SOAP message.
This assertion cannot be fully tested, as a SOAP node is allowed to process and remove SOAP headers, reinsert them and send them upstream.
A SOAP header block MAY carry a role attribute information item (see 5.2.2 SOAP role Attribute) that is used to target the header block at SOAP nodes operating in the specified role. This specification refers to the value of the SOAP role attribute as the SOAP role for the corresponding SOAP header block.
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
[local name] and [namespace name]
of the outer-most element information item of that header block.
SOAP header blocks MAY carry mustUnderstand attribute information items (see 5.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory.
Mandatory SOAP header blocks are presumed to somehow modify the semantics of other headers or body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).
This specification therefore does not require any fault to be generated based on the presence or value of the mustUnderstand attribute information item on a SOAP header block not targeted at the current processing node. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver.
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 SOAP header blocks and the SOAP 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 SOAP header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with the
Value
ofCode
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.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 MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the application level processing specified by non-mandatory SOAP header blocks targeted at it.
A SOAP node MAY also choose to process non-mandatory SOAP header blocks targeted at it.
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.
Header-related faults other than those related to understanding header blocks (see 2.4 Understanding SOAP Headers) MUST conform to the specification for the corresponding SOAP header block.
A message may contain or result in multiple errors during processing. Except where the order of detection is specifically indicated (as in 2.4 Understanding SOAP Header Blocks), a SOAP node is at liberty to reflect any single fault from the set of possible faults prescribed for the errors encountered. 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.
Forwarding intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the message all SOAP header blocks targeted to them, prior to forwarding, regardless of whether these blocks were processed or ignored.
A SOAP node MAY support multiple envelope versions. However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.
If a SOAP node receives a message whose version is not supported it MUST generate a fault (see 5.4 SOAP Fault) with a Value of Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".
Certain features might require end-to-end as opposed to hop-to-hop processing semantics. Although the SOAP Protocol Binding Framework allows end-to-end features to be expressed outside the SOAP envelope, no standard mechanism is provided for the processing by intermediaries of the resulting messages. A binding specification that expresses such features external to the SOAP envelope needs to define its own processing rules for those externally expressed features. A SOAP node is expected to conform to these processing rules (for example, describing what information is passed along with the SOAP message as it leaves the intermediary). The processing of SOAP envelopes in accordance with the SOAP Processing Model (see 2. SOAP Processing Model) MUST NOT be overridden by binding specifications.
The specification of a feature MUST include the following:
A URI used to name the feature. This enables the feature to be unambiguously referenced in description languages or during negotiation.
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 request-response MEP specified in SOAP 1.2 Part 2 [1] illustrates the specification of a MEP feature.
See 3.3 SOAP Message Exchange Patterns (MEPs) for additional requirements on MEP features.
A module specification follows the following rules. It:
The term 'SOAP Module' refers to the set of syntax and semantics associated with implementing a particular feature (see 3.1 SOAP Features) as SOAP header blocks. A Module is described in a Module Specification, which adheres to the following rules. It:
MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation.
MUST, if* the Module implements a Feature which has already been defined elsewhere, clearly refer to that Feature's URI. Note that a Module may EITHER explicitly refer to a separate Feature in this way OR may implicitly define a Feature simply by describing the semantics of the Module.
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
MAY utilize the property conventions defined in [SOAP Part2], 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.
MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules). For example, we can imagine a module which encrypts the SOAP body and inserts 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.
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.
MEPs are SOAP features, so an MEP specification MUST conform to the requirements for SOAP feature specifications (see 3.1.1 Requirements on Features). An MEP specification MUST also include:
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.
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. Similarly if a certain feature cannot be used if another feature is present this MUST be specified.
; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.
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. 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. This binding framework does not provide any explicit mechanism for controlling the use of such interdependent features.
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.
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 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.
The XML infoset of a SOAP message MUST NOT contain a document type declaration information item.
A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages that it receives.
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
ofCode
set to "env:Sender". However, in the case where performance considerations make it impractical for an intermediary to detect processing instruction information items in a message to be relayed, the intermediary MAY leave such processing instruction information items unchanged in the relayed message.
Element information items defined by this specification may have zero or more character information item children whose character code is amongst the whitespace characters as defined by [8]. Unless otherwise indicated, such character information items are considered insignificant. A SOAP receiver MUST ignore such insignificant character information items.
The Envelope element information item has:
A [local name] of Envelope .
A [namespace name] of "http://www.w3.org/2002/06/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).
The encodingStyle attribute information item MAY only appear on:
A SOAP header block (see 5.2.1 SOAP header block).
A child element information item of the SOAP Body element information item (see 5.3.1 SOAP Body child Element).
A child element information item of the SOAP Detail element information item (see 5.4.5.1 SOAP detail entry).
Any descendent of 1, 2, and 3 above.
The scope of the encodingStyle attribute information item is that of its owner element information item and that element information item's descendants, unless a descendant itself carries such an attribute information item.
If no
encodingStyle
attribute information item is in scope for a particular element information item or the value of such an attribute information item isthe zero-length URI ("")
"http://www.w3.org/2002/06/soap-envelope/encoding/none"
then no claims are made regarding the encoding style of that element information item and its descendants.
Each SOAP header block element information item:
MUST have a [namespace name] property which has a value, that is, MUST be namespace qualified.
MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.
MAY have an
encodingStyle
attribute information item in its [attributes] property.MAY have an
role
attribute information item in its [attributes] property.MAY have an
mustUnderstand
attribute information item in its [attributes] property.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).
The SOAP header block attribute information items defined later in 5.2.2 SOAP role Attribute and 5.2.3 SOAP mustUnderstand Attribute affect the processing of SOAP messages by SOAP receivers (see 2. SOAP Processing Model). A SOAP sender generating a SOAP message SHOULD use these attributes only on SOAP header block. A SOAP receiver MUST ignore these attribute information items if they appear on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).
The role attribute information item has the following Infoset properties:
A [local name] of role .
A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".
A [specified] property with a value of "true".
The type of the
role
attribute information item isanyURI in the namespace named "http://www.w3.org/2001/XMLSchema".
xs:anyURI.
The value of the
role
attribute information item is a URI that names a role that a SOAP node can assume.
The mustUnderstand attribute information item has the following Infoset properties:
A [local name] of mustUnderstand .
A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".
A [specified] property with a value of "true".
The type of the
mustUnderstand
attribute information item isboolean in the namespace "http://www.w3.org/2001/XMLSchema".
xs:boolean.
The Body element information item has:
A [local name] of Body .
A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".
Zero or more namespace qualified attribute information items in its [attributes] property.
Zero or more namespace qualified element information items in its [children] property.
All child element information items of the SOAP
Body
element information item:
MUST have a [namespace name] property which has a value, that is, be namespace qualified.
MAY have an
encodingStyle
attribute information item in their [attributes] property.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 the following, which has special significance for SOAP processing:
encodingStyle
attribute information item (see 5.1.1 SOAP encodingStyle Attribute).
The Fault element information item has:
A [local name] of Fault .
A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".
Two or more child element information items in its [children] property in order as follows:
A mandatory Code element information item (see 5.4.1 SOAP Code Element).
A mandatory Reason element information item (see 5.4.2 SOAP Reason Element).
An optional Node element information item (see 5.4.3 SOAP Node Element).
An optional Role element information item (see 5.4.4 SOAP Role Element).
An optional Detail element information item (see 5.4.5 SOAP Detail Element).
The Code element information item has:
A [local name] of Code .
A [namespace name] of http://www.w3.org/2002/06/soap-envelope .
One or two child element information items in its [children] property, in order, as follows:
A mandatory Value element information item as described below (see 5.4.1.1 SOAP Value element (with Code parent))
An optional Subcode element information item as described below (see 5.4.1.2 SOAP Subcode element).
The Subcode element information item has:
A [local name] of Subcode .
A [namespace name] of http://www.w3.org/2002/06/soap-envelope .
One or two child element information items in its [children] property, in order, as follows:
A mandatory Value element information item as described below (see 5.4.1.3 SOAP Value element (with Subcode parent)).
An optional Subcode element information item (see 5.4.1.2 SOAP Subcode element).
The
Reason
element information item has:
A [local name] of
Reason
.A [namespace name] of
http://www.w3.org/2002/06/soap-envelope
.An optional attribute information item with a [local name] of
lang
and [namespace name] of "http://www.w3.org/XML/1998/namespace" (see [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.
One or more
Text
element information item children (see 5.4.2.1 SOAP Text Element).
The
Text
element information item has:
A [local name] of
Text
.A [namespace name] of
http://www.w3.org/2002/06/soap-envelope
.A mandatory attribute information item with a [local name] of
lang
and [namespace name] of "http://www.w3.org/XML/1998/namespace" (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 Node element information item has:
A [local name] of Node .
A [namespace name] of http://www.w3.org/2002/06/soap-envelope .
SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item.
The type of the
Node
element information item isanyURI in the "http://www.w3.org/2001/XMLSchema" namespace.
xs:anyURI.
/p>The
Role
element information item has:
A [local name] of
Role
.A [namespace name] of
http://www.w3.org/2002/06/soap-envelope
.The type of the
Role
element information item isanyURI in the "http://www.w3.org/2001/XMLSchema" namespace.
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).
The Detail element information item has:
A [local name] of Detail .
A [namespace name] of http://www.w3.org/2002/06/soap-envelope .
Zero or more attribute information items in its [attributes] property.
Zero or more child element information items in its [children] property.
The values of the
Value
child element information item of theCode
element information item are restricted to those in Table 2. Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in theValue
child element information item of theSubcode
element information item.The values of the
Value
child element information item of theCode
element information item are restricted to those defined by theenv:faultCodeEnum
type (see Table 2). Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in theValue
child element information item of theSubcode
element information item.
The
Upgrade
element information item has:
A [local name] of
Upgrade
.A [namespace name] of "http://www.w3.org/2002/06/soap-upgrade".
One or more
envelope
Envelope
element information items in its [children] property as described below:
The
envelope
Envelope
element information item has:
A [local name] of
envelope
Envelope
.
A [namespace name]
which has no value.
of "http://www.w3.org/2002/06/soap-upgrade".
An unqualified attribute information item with a local name of
qname
whose type isQName in the "http://www.w3.org/2001/XMLSchema" namespace.
xs:QName.
A SOAP node MAY generate a SOAP fault for any one or more SOAP header blocks that were not understood in a SOAP message. It is NOT a requirement that the fault contain the qualified names of ALL such SOAP header blocks.
Each such header block element information item has:
A [local name] of
Misunderstood
.A [local name] of
NotUnderstood
.A [namespace name] of "http://www.w3.org/2002/06/soap-faults".
A
qname
attribute information item in its [attributes] property as described below.The
qname
attribute information item has the following 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 isQName in the "http://www.w3.org/2001/XMLSchema" namespace.
xs:QName.
Its value is the XML qualified name of a SOAP header block which the faulting node failed to understand.
SOAP does not define a base URI but relies on the mechanisms defined in XML Base[11] and RFC 2396[6] for establishing a base URI against which relative URIs can be made absolute.
The use of IP addresses in URIs SHOULD be avoided whenever possible (see RFC 1900 [18]. However, when used, the literal format for IPv6 addresses in URIs as described by RFC 2732 [12] SHOULD be supported.
SOAP does not place any a priori limit on the length of a URI. Any SOAP node MUST be able to handle the length of any URI that it publishes and both SOAP senders and SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length.
A SOAP/1.1 node receiving a SOAP Version 1.2 message will according to SOAP/1.1 generate a version mismatch SOAP fault based on a SOAP/1.1 message construct. That is, the envelope will have a
local name
[local name]
of
Envelope
and anamespace name
[namespace name]
of "http://schemas.xmlsoap.org/soap/envelope/".
A SOAP Version 1.2 node receiving a SOAP/1.1 message either:
MAY process the message as a SOAP/1.1 message (if supported), or
MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics. The SOAP fault SHOULD include an Upgrade header block as defined in this specification (see 5.4.7 VersionMismatch Faults) indicating support for SOAP Version 1.2. This allows a receiving SOAP/1.1 node to correctly interpret the SOAP fault generated by the SOAP Version 1.2 node.
When serializing a graph for transmission inside a SOAP message any representation that deserializes to the identical graph MAY be used; when receiving an encoded SOAP message, all representations MUST be accepted.
The graph node at which an edge terminates is determined as follows:
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.
In such cases the element information item represents both a graph edge and a graph node
If the element information item representing the edge does have a ref attribute information item (see 3.1.5.2 ref Attribute Information Item) among its attributes, then the value of that attribute information item MUST be identical to the value of exactly one id attribute information item ( see 3.1.5.1 id Attribute Information Item ) in the same envelope. In this case the edge terminates at the graph node represented by the element information item on which the id attribute information item appears. That element information item MUST be in the scope of an encodingStyle attribute with a value of "http://www.w3.org/2002/06/soap-encoding".
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.
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
The [local name] and [namespace name]
properties of the element information item are not significant.
The following rules apply to the encoding of a graph node that represents an "array":
The element information item representing an array node MAY have amongst its attributes an itemType attribute information item (see 3.1.4.1 itemType Attribute Information Item).
The element information item representing an array node MAY have amongst its attributes an arraySize attribute information item (see 3.1.6 arraySize Attribute Information Item).
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:nil attribute information item.
The type name property of a graph node is a {namespace name, local name} pair computed as follows:
If the element information item representing the graph node has an
xsi:type
attribute information item among its attributes then the type name property of the graph node is the value of thexsi:type
attribute information item.Note:
This attribute is of type
QName in the namespace named "http://www.w3.org/2001/XMLSchema"
xs:QName
(see [XML Schema Part2]); its value consists of the pair {namespace name, local name}. Neither the prefix used to construct the QName nor any information relating to any definition of the type is considered to be part of the value. The SOAP graph carries only the qualified name of the type.
Otherwise if the parent element information item of the element information item representing the graph node has an
enc:itemType
attribute information item (see 3.1.4.1 itemType Attribute Information Item) among its attributes then the type name property of the graph node is the value of theenc:itemType
attribute information itemOtherwise the value of the type name property of the graph node is unspecified.
The
itemType
attribute information item has the following Infoset properties:
A local name of
itemType
;A [local name] of
itemType
.A namespace name of "http://www.w3.org/2002/06/soap-encoding".
A [namespace name] of "http://www.w3.org/2002/06/soap-encoding".
A specified property with a value of "true".
A [specified] property with a value of "true".
The type of the
itemType
attribute information item isQName in the namespace named "http://www.w3.org/2001/XMLSchema".
xs:QName.
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.
The
id
attribute information item has the following Infoset properties:
A local name of
id
;A [local name] of
id
.A namespace name which is empty
A [namespace name] of "http://www.w3.org/2002/06/soap-encoding".
A specified property with a value of "true".
A [specified] property with a value of "true".
The type of the
id
attribute information item isID in the namespace named "http://www.w3.org/2001/XMLSchema".
xs:ID.
The value of the
id
attribute information item is a unique identifier that can be referred to by aref
attribute information item (see 3.1.5.2 ref Attribute Information Item).
The
ref
attribute information item has the following Infoset properties:
A local name of
ref
;A [local name] of
ref
.A namespace name which is empty
A [namespace name] of "http://www.w3.org/2002/06/soap-encoding".
A specified property with a value of "true".
A [specified] property with a value of "true".
The type of the
ref
attribute information item isIDREF in the namespace named "http://www.w3.org/2001/XMLSchema".
xs:IDREF.
The value of the
ref
attribute information item is a reference to a unique identifier defined by anid
attribute information item (see 3.1.5.1 id Attribute Information Item).
A ref attribute information item and an id attribute information item MUST NOT appear on the same element information item.
The
arraySize
attribute information item has the following Infoset properties:
A local name of
arraySize
;A [local name] of
arraySize
.A namespace name of "http://www.w3.org/2002/06/soap-encoding".
A [namespace name] of "http://www.w3.org/2002/06/soap-encoding".
A default value of "*"
The type of the
arraySize
attribute information item isarraySize in the namespace named "http://www.w3.org/2002/06/soap-encoding".
enc:arraySize.
The value of the
arraySize
attribute information item MUST conform to the following EBNF grammar
[1] arraySizeValue
::= ("*" | concreteSize) nextConcreteSize*
[2] nextConcreteSize
::= " " concreteSize
whitespace concreteSize
[3] concreteSize
::= [0-9]+
[4] whitespace
::= (#x20 | #x9 | #xD | #xA)+
The array's dimensions are represented by each item in the list of sizes (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.
The default value of the
arraySize
attribute information item is "*", that is by default arrays are considered to be of unspecified size.
During deserialization a SOAP receiver:
SHOULD generate an "env:Sender" SOAP fault with a subcode of
enc:MissingID
if the message violates the constraints onid
andref
attribute information items (see 3.1.5.3 Constraints on id and ref attribute information items).SHOULD generate an "env:Sender" SOAP fault with a subcode of
enc:MissingID
if the message contains aref
attribute information item but no correspondingid
attribute information item (see 3.1.5.3 Constraints on id and ref attribute information items).SHOULD generate an "env:Sender" SOAP fault with a subcode of
enc:DuplicateID
if the message contains two or moreid
attribute information item that have the same value. (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.
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 or array is named identically to the procedure or method name (see B. Mapping Application Defined Names to XML Names).
The invocation is represented by a single struct containing an outbound edge for each [in] or [in/out] parameter. The struct is named identically to the procedure or method name and the conventions of B. Mapping Application Defined Names to XML Names SHOULD be used to represent method names that are not legal XML names.
Each outbound edge either has a label corresponding to the name of the parameter (see B. Mapping Application Defined Names to XML Names) or a position corresponding to the position of the parameter.
Each outbound edge has a label corresponding to the name of the parameter. The conventions of B. Mapping Application Defined Names to XML Names SHOULD be used to represent parameter names that are not legal XML names.
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 response is represented by a single struct containing an outbound edge for the return value and each [out] or [in/out] parameter.
If the response is represented by a struct, then
Each parameter is represented by an outbound edge with a label corresponding to the name of the parameter. The conventions of B. Mapping Application Defined Names to XML Names SHOULD be used to represent parameter names that are not legal XML names. A non-void return value is represented in the struct by an outbound edge that may be given any unique label. The XML qualified name of the label of the edge representing the return value is given by a separate outbound edge with a local name of
result
and the namespace name "http://www.w3.org/2002/06/soap-rpc". Theresult
outbound edge MUST be present and hold the XML qualified name of the edge containing the return value within any struct response if the return value of the procedure is non-void. Theresult
outbound edge MUST NOT be present if the return value of the procedure is void.If the response is represented by an array, each outbound edge has a label corresponding to the position of the parameter. A return value MUST be present if the return value of the procedure is non-void. If present, the return value MUST be represented as the first edge of the array with parameters following. If no return value is present, then parameters begin with the first outbound edge of the array.
Invocation faults are handled according to the rules in 4.4 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.
When using SOAP encoding (see 3. SOAP Encoding) in conjunction with the RPC convention described here, the SOAP
Body
MUST contain only a single child element information item, that child being the serialized RPC invocation or response struct.or array.
I.e. when using the SOAP encoding for serializing RPC invocations and responses, the encoding is constrained to produce a single tree of element information items.
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in a SOAP envelope carrying an RPC invocation or response. Such additional information MUST be expressed as SOAP header blocks.
Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):
A fault with a
Value
of "env:Receiver" forCode
SHOULD be generated when the receiver cannot handle the message because of some temporary condition, e.g. when it is out of memory.A fault with a
Value
of "env:DataEncodingUnknown" forCode
SHOULD be generated when the arguments are encoded in a data encoding unknown to the receiver.A fault with a
Value
of "env:Sender" forCode
and aValue
of "rpc:ProcedureNotPresent" forSubcode
MAY be generated when the receiver does not support the procedure or method specified.A fault with a
Value
of "env:Sender" forCode
and aValue
of "rpc:BadArguments" forSubcode
MUST be generated when the receiver cannot parse the arguments or when there is a mismatchin number and/or type of the arguments
between what the receiver expects and what was sent.
Other faults arising in an extension or from the application SHOULD be generated as described in [SOAP Part1] SOAP Fault Codes.
An implementation of the SOAP HTTP Binding MUST support the following message exchange patterns (MEPs):
"http://www.w3.org/2002/06/soap/mep/request-response/" (see 6.2 Request-Response Message Exchange Pattern)
"http://www.w3.org/2002/06/soap/mep/soap-response/" (see 6.3 SOAP Response Message Exchange Pattern)
All the tests in this test collection follow the following rules:
The tests use three SOAP nodes - Node A, Node B and Node C, identified by "http://example.org/ts-tests/A", "http://example.org/ts-tests/B", and "http://example.org/ts-tests/C" respectively. No other SOAP nodes must be used in communication between these three SOAP nodes.
Node A is the test client.
Node C is the ultimate destination.
Node B is a SOAP intermediary.
Node B must act in the role "http://example.org/ts-tests/B"
Node C must act in the role "http://example.org/ts-tests/C"
Node A, Node B and Node C implement some mechanism for routing so that the following messaging scenarios are allowed:
Node A sends message to Node C, Node C returns a response or fault message back to Node A (Node B is not involved in this scenario).
Node A sends message to Node B, Node B forwards the message to Node C or returns a fault back to Node A. Node C either:
returns a fault message to Node B and Node B forwards the fault message to Node A, OR
returns a response message to Node B and Node B forwards the response to Node A.
Unless otherwise specified the header blocks used by this test collection are in the namespace "http://example.org/ts-tests". If a header block not listed below is targeted at a Node, that Node must generate a fault with the Value of the fault Code as env:mustUnderstand.
The semantics of processing this header block require the SOAP node targeted by this header block, to reply to the SOAP node from which it received the SOAP message containing this header. The reponse SOAP message must contain the header block responseOk containing the same information set as that in echoOk header block. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
This header block is generated as a result of processing the echoOk header block as described above. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to ignore this header block altogether. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
This header block is used in conjunction with the body block echoHeader The semantics of processing the body block echoHeader requires the SOAP node to reply to the SOAP node from which it received the SOAP message containing this header. The response SOAP message must contain the SOAP body block echoHeaderResponse containing the same information set as that in requiredHeader header block. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to ignore this header block altogether. This header is used for encapsulating data used by other headers and body blocks. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to take the character information item children of the header block concatAndForwardEchoOkArg2 concatenate it to the character information item children of the header block concatAndForwardEchoOkArg1 and forward the result to the downstream SOAP node using the header block echoOK This header should not contain any
character
information item children.The semantics of processing this header block require the SOAP node targeted by this header block, to ignore this header block altogether. This header is used for encapsulating data used by the header concatAndForwardEchoOk block. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to ignore this header block altogether. This header is used for encapsulating data used by the header concatAndForwardEchoOk block. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to validate that the character information item of this header consists of two letters only (ignoring whitespace). If this condition is not satisfied then a fault is required to be sent back to the sender of the message with the Value of the fault Code as env:Sender along with a header block validateCountryCodeFault containing an explanation for the fault The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
This header block is used to cary information related to fault generated as a result of processing the header block validateCountryCode as described above. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
The semantics of processing this header block require the SOAP node targeted by this header block, to reply to the SOAP node from which it received the SOAP message containing this header. The reponse SOAP message must contain the header block responseResolvedRef This header block contains one child element information item RelativeReference in the namespace "http://example.org/ts-tests". RelativeReference element information item is required to have the attribute information items xml:base, and xlink:href. The responseResolvedRef contains the resolved reference pointed to by xml:base and xlink:href.
Unless otherwise specified the body blocks used by this test collection are in the namespace "http://example.org/ts-tests". If a body block not listed below is targeted at a Node, that Node must generate a fault.
The semantics of processing this body block require the SOAP node to reply to the SOAP node from which it received the SOAP message containing this block. The reponse SOAP message must contain the body block responseOk containing the same information set as that in echoOk body block. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
This body block is generated as a result of processing the echoOk body block as described above. The type of this header block is string in the namespace "http://www.w3.org/2001/XMLSchema".
This body block is used in conjuction with the header block requiredHeader The semantics of processing this body block require the SOAP node to reply to the SOAP node from which it received the SOAP message containing this block. The response SOAP message must contain the body block echoHeaderResponse containing the same information set as that in requiredHeader header block. This body block does not have any
children
element information items, or attribute information items.Unless otherwise specified the procedure/method names used by this test collection are in the namespace "http://example.org/ts-tests". If a RPC procedure/method is not listed below is targeted at a Node, that Node must generate a fault.
In addition to types defined in the namespace "http://www.w3.org/2001/XMLSchema", the test collection uses the following types:
SOAPStruct
defined in the namespace
"http://example.org/ts-tests/xsd". This type contains three
child element information items in its children property as
follows:
An element information item of type string in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type int in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type float in the namespace "http://www.w3.org/2001/XMLSchema".
SOAPStructStruct
defined in the namespace
"http://example.org/ts-tests/xsd". This type contains four
child element information items in its children property as
follows:
An element information item of type int in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type float in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type string in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type SOAPStruct in the namespace "http://example.org/ts-tests/xsd".
SOAPArrayStruct
defined in the namespace
"http://example.org/ts-tests/xsd". This type contains four
child element information items in its children property as
follows:
An element information item of type int in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type float in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item of type string in the namespace "http://www.w3.org/2001/XMLSchema".
An element information item representing an array of type string in the namespace "http://www.w3.org/2001/XMLSchema".
The encoding represented by the URI "http://example.org/PoisonEncoding" is an encoding that is not recognized by any of the SOAP nodes.
Some of the tests in this test collection, test SOAP 1.2 HTTP binding. The request and response messages for these tests contain HTTP start-line (request-line or status-line), HTTP headers required by the bindings and the XML payload. Additional HTTP headers can be generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. In the tests, the value of the 'Content-Length' and 'Host' header should be replaced with an appropriate value.
This procedure/method does not have any input and output parameters and does not have a return value.
This procedure/method has one input parameter and a return value. Both are of type SOAPStruct in the name space "http://example.org/ts-tests/xsd". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type array of SOAPStruct in the name space "http://example.org/ts-tests/xsd". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and three return value. The input parameter is of type SOAPStruct in the name space "http://example.org/ts-tests/xsd". The first output parameter is of type int in the namespace "http://www.w3.org/2001/XMLSchema". The
second
output parameter is of type float in the namespace "http://www.w3.org/2001/XMLSchema". The third output parameter is of type string in the namespace "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the individual members of SOAPStruct in the input argument as output arguments, in the response.This procedure/method has three input parameter and a return value. The first input parameter is of type int in the namespace "http://www.w3.org/2001/XMLSchema". The
second
input parameter is of type float in the namespace "http://www.w3.org/2001/XMLSchema". The third input parameter is of type string in the namespace "http://www.w3.org/2001/XMLSchema". The return type is SOAPStruct in the name space "http://example.org/ts-tests/xsd". The semantics of this method consists of using the input arguments to construct an instance of SOAPStruct and returning the result in the response.This procedure/method has one input parameter and a return value. Both are of type SOAPStructStruct in the name space "http://example.org/ts-tests/xsd". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type SOAPArrayStruct in the name space "http://example.org/ts-tests/xsd". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type array of float in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type array of string in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type array of int in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type base64Binary in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type boolean in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type date in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type decimal in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type float in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. Both are of type string in the name space "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the input argument in the response.
This procedure/method has one input parameter and a return value. The input parameter is of type array of string in the name space "http://www.w3.org/2001/XMLSchema" and the type of the return value is int in the namespace "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning the cardinality of the input array argument in the response.
This procedure/method has one input parameter and a return value. The input
parameter
is of type string in the name space "http://www.w3.org/2001/XMLSchema" and the type of the return value is boolean in the namespace "http://www.w3.org/2001/XMLSchema". The semantics of this method consists of returning a boolean 'true' if the input argument is absent, or a boolean 'false' if the input argument is present, in the response.Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Node A sends to node C message with Processing Instruction node. Node C ignores PI and returns back Body with test:responseOk element.
Message sent from Node A
Message sent from Node C
attribute
with a value of "http://www.w3.org/2002/06/soap-encoding", contains an element with attribute enc:itemType="xsd:string" (array of string), but with the child element of a complex type. Node C returns a Fault indicating that message didn't follow SOAP encoding rules (encoded array content didn't correspond to the type declared in the enc:itemType).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
A SOAP 1.1 sender, Node A, sends a 1.1 message to a SOAP Version 1.2 Node C. Node C may return back a VersionMismatch fault (tested here) or process the message (if it supports SOAP 1.1).
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
First set of messages.
Second set of messages.
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
identifier
defined by an id attribute information item. Node C responds by echoing the value of the element information item containing the referenced id attribute information item.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
concatenate
them and forward the result to Node C using the test:echoOk header. Node C then receives the concetanated data in the test:echoOk header and responds using the test:responsOk header.Message sent from Node A
Message sent from Node B
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node B
Message sent from Node C
non-existent
encoding to test a failure condition. It is the intention that no receiving SOAP 1.2 node will support this encoding and that on receiving this encoding style declaration in a SOAP message, will return the DataEncodingUnknown fault. Node A sends a simple SOAP 1.2 message to Node C containing the poison encoding style declaration. Node C responds with a fault.Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
Message sent from Node A
Message sent from Node C
This specification is the work of the W3C XML Protocol Working Group.
Members of the Working Group are (at the time of writing, and by alphabetical order): Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly Allaire), Paul Denning (MITRE), Frank DeRose (Tibco), Colleen Evans (Progress Software), David Fallside (Chair, IBM), Dietmar Gaertner (Software AG), Martin Gudgin (Microsoft Corporation, formerly DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Mario Jeckle (DaimlerChrysler Research & Technology), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet), Yves Lafon (W3C), Michah Lerner (AT&T), Bob Lojek (Intalio), Brad Lund (Intel), Noah Mendelsohn (IBM, formerly Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Highland Mary Mountain (Intel), Don Mullen (Tibco), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), David Orchard (BEA Systems, formerly JamCracker), Andreas Riegg (DaimlerChrysler Research & Technology), Herve Ruellan (Canon), Marwan Sabbouh (MITRE), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia, formerly Allaire), Nick Smilonich (Unisys), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Asir Vedamuthu (webMethods), Pete Wenzel (SeeBeyond), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Amr Yassin (Philips Research), Jin Yu (Martsoft).
Previous members were: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Mark Baker (Idokorro Mobile, formerly Sun Microsystems), Philippe Bedu (Electricite de France), Olivier Boudeville (Electricite de France), Don Box (DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software Corp), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corp), Yin-Leng Husband (Hewlett Packard, formerly Compaq), Scott Isaacson (Novell), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Henry Lowe (OMG), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Mark Nottingham (Akamai Technologies), Conleth O'Connell (Vignette), David Orchard (Jamcracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera) Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Aaron Skonnard (Developmentor), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Jim Trezzo (Oracle), Randy Waldrop (webMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Susan Yee (Active Data Exchange).
The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.
The editors would like to acknowledge Kirill Gavrylyuk (Microsoft Corp.) for the gladly-received contribution of test for SOAP 1.2 Part 1.
The editors would like to acknowledge Nick Smilonich for reviewing this document.
Date | Author | Description |
---|---|---|
20020831 | ASK | Changes as per the email at http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0091.html |
20020910 | ASK | Fixed incorrect namespace in tests T52 and T55 |
20020910 | ASK | Fixed the content model of the fault in tests T30 to use the one defined by SOAP 1.1 - error pointed out by Mark Jones |
20021008 | ASK | Synched with part 1 - version 2002/10/07 17:46:53. |
20021013 | ASK | Synched with part 1 - version 2002/10/11 19:40:53. |
20021016 | ASK | Synched with part 2 - version 2002/10/14 21:38:29. |
20021021 | ASK | Synched with part 1 - version 2002/10/20 17:51:45 Synched with part 2 - version 2002/10/20 17:51:45 These are the oct 2002 F2F snapshots. |