Please refer to the errata for this document, which may
include normative corrections.some
TheEnglishversionofthisspecificationistheonlynormativeversion.Non-normativetranslationsSee also maybetranslations.available.
Copyright © 2007 W3C © 2003 ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark ®and document use ,,andsoftwarerules apply.licensing
This document draws on assertions
found in the SOAP Version 1.2 specifications [SOAP Part 1],
[SOAP Part1]Part 2], and provides a set of tests in
order to show whether the assertions are implemented in a SOAP
processor.Part2]
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,
2003062007 04 27. 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 compliant
with the SOAP Version 1.2 specifications based on its failure
to pass one or more of the tests in this test suite. 24.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest Therevision of this statusdocumentseriesismaintainedtechnical report can be found in the atW3C technical reports index at http://www.w3.org/TR/.W3C.
This document is a W3C Recommendation oftheW3C.This. It has been produced by the XML Protocol Working Group, which
is part of the Web Services
Activity.
documentThis second edition updates and supersedes the original Recommendation by the inclusion of the accumulated errata.
Changes between these two versions are described in a
diff document.It
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and Membershasis endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited beenasanormativefrom another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.reference
CommentsPlease report errors in this document onarewelcome.Pleasesendto the public themmailing list xmlp-comments@w3.org
(archive).
It is inappropriate to send discussion email to this address.mailing-list
InformationaboutimplementationsrelevanttothisSOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 [soap11]specification
The SOAP 1.2 Implementation Report can be found intheImplementationat
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html.
ReportPatentdisclosuresrelevanttothisspecificationAdditional implementation experience of the Request
Optional Response MEP can be found mayin the onWorkingWSDL 2.0 implementation testing here:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html.Group's
This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page disclosurealso includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in ,accordance with section 6 of the W3C conformancePatent Policy. policy.
A list of current W3C Recommendations and
other technical reports can be found at http://www.w3.org/TR.http://www.w3.org/TR.
1. Introduction
2. SOAP 1.2 Assertions
3. SOAP 1.2 Test Collection
4. References
A. Acknowledgements (Non-Normative)
1. Introduction
2. SOAP 1.2 Assertions
2.1 SOAP 1.2, Part 1 Assertions 2.1
2.2 SOAP 1.2, Part 2 Assertions 2.2
3. SOAP 1.2 Test Collection
3.1 Introduction 3.1
3.2 Header Blocks Used by the Test Collection 3.2
3.2.1 echoOk 3.2.1
3.2.2 responseOk 3.2.2
3.2.3 Ignore 3.2.3
3.2.4 requiredHeader 3.2.4
3.2.5 DataHolder 3.2.5
3.2.6 concatAndForwardEchoOk 3.2.6
3.2.7 concatAndForwardEchoOkArg1 3.2.7
3.2.8 concatAndForwardEchoOkArg2 3.2.8
3.2.9 validateCountryCode 3.2.9
3.2.10 validateCountryCodeFault 3.2.10
3.2.11 echoResolvedRef 3.2.11
3.2.12 responseResolvedRef 3.2.12
3.3 Body Blocks Used by the Test Collection 3.3
3.3.1 echoOk 3.3.1
3.3.2 responseOk 3.3.2
3.3.3 echoHeader 3.3.3
3.3.4 echoHeaderResponse 3.3.4
3.4 RPC Methods/Procedures Used by the Test Collection 3.4
3.4.1 returnVoid 3.4.1
3.4.2 echoStruct 3.4.2
3.4.3 echoStructArray 3.4.3
3.4.4 echoStructAsSimpleTypes 3.4.4
3.4.5 echoSimpleTypesAsStruct 3.4.5
3.4.6 echoNestedStruct 3.4.6
3.4.7 echoNestedArray 3.4.7
3.4.8 echoFloatArray 3.4.8
3.4.9 echoStringArray 3.4.9
3.4.10 echoIntegerArray 3.4.10
3.4.11 echoBase64 3.4.11
3.4.12 echoBoolean 3.4.12
3.4.13 echoDate 3.4.13
3.4.14 echoDecimal 3.4.14
3.4.15 echoFloat 3.4.15
3.4.16 echoString 3.4.16
3.4.17 countItems 3.4.17
3.4.18 isNil 3.4.18
3.5 Tests 3.5
4. References
4.1 Normative References 4.1
4.2 Informative References 4.2
A. Acknowledgements (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
2007/04/27 $.
2003/06/24
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.
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.
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).
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.
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.
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).
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.
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.Note:
Throughout this document, the term "
Value
ofCode
" is used as a shorthand for "value of theValue
child element information item of theCode
element information item" (see 5.4.1 SOAP Code Element).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.
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.
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 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:
Remove all processed SOAP header blocks.
Remove all non-relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.
Retain all relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.
All XML infoset properties of a message MUST be preserved with the following exceptions:
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.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.Whitespace character information items MAY be removed from the [children] property of the SOAP
Envelope
element information item.Whitespace character information items MAY be added to the [children] property of the SOAP
Envelope
element information item.Whitespace character information items MAY be removed from the [children] property of the SOAP
Header
element information item.Whitespace character information items MAY be added to the [children] property of the SOAP
Header
element information item.Comment information items MAY be added to the [children] property of the SOAP
Envelope
element information item.Comment information items MAY be removed from the [children] property of the SOAP
Envelope
element information item.Comment information items MAY be added to the [children] property of the SOAP
Header
element information item.Comment information items MAY be removed from the [children] property of the SOAP
Header
element information item.Attribute information items MAY be added to the [attributes] property of the SOAP
Envelope
element information item.Attribute information items MAY be added to the [attributes] property of the SOAP
Header
element information item.Attribute information items MAY be added to the [namespace attributes] property of the SOAP
Envelope
element information item.Attribute information items MAY be added to the [namespace attributes] property of the SOAP
Header
element information item.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.
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.
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.
The [base URI] property of the document information item need not be maintained.
The [base URI] property of element information items MAY be changed or removed.
The [character encoding scheme] property of the document information item MAY be changed or removed.
All namespace information items in the [in-scope namespaces] of element information items MUST be preserved. Additional namespace information items MAY be added.
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".
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.
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.
A module specification 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 declare the features provided by a module (see 3.1 SOAP Features).
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
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.Part2]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.
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.
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".
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:
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 appear on the following:
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) if that child is not a SOAP Fault element information item (see 5.4 SOAP Fault).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
encodingStyle
attribute information item MUST NOT appear on any element other than above in a SOAP message infoset.
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 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.
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.
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 ).
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 therole
attribute information item is a URI that names a role that a SOAP node can assume.
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).
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.
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).
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.
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).
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.
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:
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/2003/05/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/2003/05/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/2003/05/soap-envelope
.One or more
Text
element information item children (see 5.4.2.1 SOAP Text Element). Each childText
element information item SHOULD have a different value for itsxml:lang
attribute information item.The type of the
Reason
element information item is env:faultReason.
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 thelang
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
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.
SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item.
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).
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.
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 anencodingStyle
attribute information item.
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 anencodingStyle
attribute information item.
SOAP does not define a base URI but relies on the mechanisms defined in [XML Base] and [RFC
3986] for establishing a base URI against which relative URIs can be made absolute.2396]
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
3986] SHOULD be supported.2732]
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.
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:
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/".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.
The requirement on the behavior of SOAP 1.1 compliant SOAP node will not be tested by the test collection.
When serializing a graph for transmission inside a SOAP message, a representation that deserializes to the identical graph MUST be used; when multiple such representations are possible, any of them MAY be used. When receiving an encoded SOAP message, all representations MUST be accepted.
The graph node at which an edge terminates is determined by examination of the serialized XML 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) among 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 nodeIf 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 oneid
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 theid
attribute information item appears. That element information item MUST be in the scope of anencodingStyle
attribute with a value of "http://www.w3.org/2003/05/soap-encoding" (see SOAP 1.2 Part 1 SOAP encodingStyle Attribute).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:
The ordinal position of the graph edge corresponds to the position of the child element information item relative to its siblings
The [local name] and [namespace name] properties of the child 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 xs:QName (see XML Schema [XML Schema
Part 2]); 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.Part2]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 [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
A [specified] property with a value of "true".
The type of the
itemType
attribute information item is xs:QName.
A
ref
attribute information item and anid
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 [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
The type of the
arraySize
attribute information item is enc:arraySize. The value of thearraySize
attribute information item MUST conform to the following EBNF grammarThe 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 have a single dimension of unspecified size.
The
nodeType
attribute information item has the following Infoset properties:
A [local name] of
nodeType
.A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
A [specified] property with a value of "true".
The type of the
nodeType
attribute information item is enc:nodeType.The value of the
nodeType
attribute information item MUST, if present, be one of the strings "simple" or "struct" or "array". The value indicates what kind of a value this node represents - a simple value, a compound struct value or a compound array value respectively.
The SOAP
encodingStyle
attribute information item (see SOAP 1.2 Part 1 [SOAPPart 1] SOAP encodingStyle Attribute) is used to indicate the encoding style of the RPC representation. The encoding thus specified MUST support the 2. SOAP Data Model.Part1]
An RPC invocation is modeled as a follows:
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 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 follows:
The response is represented by a single struct containing an outbound edge for the return value and each [out] or [in/out] parameter. The name of the struct is not significant.
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 as follows:
There MUST be an outbound edge with a local name of
result
and a namespace name of "http://www.w3.org/2003/05/soap-rpc" which terminates in a terminal nodeThe type of that terminal node is a xs:QName and its value is the name of the outbound edge which terminates in the actual return value.
If the return value of the procedure is void then an outbound edge with a local name of
result
and a namespace name of "http://www.w3.org/2003/05/soap-rpc" MUST NOT be present.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.
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:
A fault with a
Value
ofCode
set to "env:Receiver" SHOULD be generated when the receiver cannot handle the message because of some temporary condition, e.g. when it is out of memory.Note:
Throughout this document, the term "
Value
ofCode
" is used as a shorthand for "value of theValue
child element information item of theCode
element information item" (see SOAP 1.2 Part 1 [SOAPPart 1], SOAP Code Element ).Part1]A fault with a
Value
ofCode
set to "env:DataEncodingUnknown" SHOULD be generated when the arguments are encoded in a data encoding unknown to the receiver.A fault with a
Value
ofCode
set to "env:Sender" and aValue
ofSubcode
set to "rpc:ProcedureNotPresent" MAY be generated when the receiver does not support the procedure or method specified.Note:
Throughout this document, the term "
Value
ofSubcode
" is used as a shorthand for "value of theValue
child element information item of theSubcode
element information item" (see SOAP 1.2 Part 1 [SOAPPart 1], SOAP Subcode element).Part1]A fault with a
Value
ofCode
set to "env:Sender" and aValue
ofSubcode
set to "rpc:BadArguments" MUST be generated when the receiver cannot parse the arguments or when there is a mismatch in 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 1.2 Part 1 [SOAP
Part 1] SOAP Fault Codes.Part1]
This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 [SOAP
Part 1] SOAP Features):Part1]
"http://www.w3.org/2003/05/soap/mep/request-response/"
All the rules in SOAP 1.2 Part 1 [SOAP
Part 1] Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.Part1]
This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 [SOAP
Part 1] SOAP Features):Part1]
"http://www.w3.org/2003/05/soap/mep/soap-response/"
The SOAP Web Method feature is identified by the URI (see SOAP 1.2 Part 1 [SOAP
Part 1] SOAP Features):Part1]
"http://www.w3.org/2003/05/soap/features/web-method/"
This binding is identified by the URI (see SOAP 1.2 Part 1 [SOAP
Part 1] SOAP Protocol Binding Framework):Part1]
"http://www.w3.org/2003/05/soap/bindings/HTTP/"
An implementation of the SOAP HTTP Binding MUST support the following message exchange patterns (MEPs):
"http://www.w3.org/2003/05/soap/mep/request-response/" (see 6.2 Request-Response Message Exchange Pattern)
"http://www.w3.org/2003/05/soap/mep/soap-response/" (see 6.3 SOAP Response Message Exchange Pattern)
The possible values of
http://www.w3.org/2003/05/soap/features/web-method/Method
property are restricted in this HTTP binding according to the MEP in use (as present inhttp://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
):Table 14: Possible values of the Web-Method Method property
Unless otherwise stated 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".
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".
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".
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 has xsi:nil attribute with a value of '1'. A boolean 'false' is returned otherwise.
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 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
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
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 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
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
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
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
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): CarineBournez(W3C),MichaelChampion(SoftwareGlen Daniels AG),(Sonic Software, formerly of (Macromedia,Allaire),DavidFallside(IBM),DietmarGaertner(SoftwareAG),TonyGraham(SunMicrosystems),MartinGudgin(MicrosoftMacromedia),
Vikas Deolaliker (Sonoa Systems, Inc.),
Chris Ferris (IBM, formerly of Corporation,Sun Microsystems),
Marc Hadley (Sun Microsystems),
DevelopMentor),GerdHoelzing(SAPAG),OisinHurley(IONATechnologies),JohnIbbotson(IBM),RyujiInoue(MatsushitaElectric),KazunoriIwasa(FujitsuLimited),MarioJeckle(DaimlerChryslerR.&Tech),MarkJonesDavid Hull (TIBCO Software, Inc.),
Anish Karmarkar (Oracle),
(AT&T),JacekKopeckyYves Lafon (W3C),
(Systinet/Idoox),MichahLerner(AT&T),NoahMendelsohn(IBM,formerlyofLotusJonathan Marsh (WSO2),
Jeff Mischkinsky (Oracle),
Development),NiloMitra(Ericsson),Jean-JacquesMoreau(Canon),MasahikoNarita(FujitsuEric Newcomer (IONA Technologies),
Limited),MarkNottingham(BEASystems,formerlyofAkamaiDavid Orchard (BEA Systems, formerly of Jamcracker),
Technologies),AndreasRiegg(DaimlerChryslerR.&Tech),HervéRuellan(Canon),JeffSchlimmer(MicrosoftCorporation),MiroslavSimekSeumas Soltysik (IONA Technologies),
Davanum Srinivas (WSO2),
Pete Wenzel (Systinet/Idoox),(SeeBeyond),VolkerWiechers(SAP(Sun Microsystems, formerly of SeeBeyond).
AG).
Previous members were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (webMethods),
Mark Baker (Idokorro (WebMethods),MobileMobile, Inc., formerly of Sun Microsystems),
Philippe Bedu (EDF (Planetfred),(Electricité(Electricite De France)),
Olivier Boudeville (EDF de(Electricité(Electricite De France)),
Carine Bournez (W3C),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus de(Novell, Inc.),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
(Novell),ConlethO'ConnellDave Cleary (webMethods),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (Vignette),(Excelon Corporation),
Ron Daniel (Interwoven),
(eXcelon),Doug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning Dug(MITRE Corporation),
Frank DeRose (MITRE),(TIBCO Software, Inc.),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Tibco),(Hewlett Packard),
James Falek (TIBCO Software, Inc.),
David Fallside (IBM),
Eric Fedok (Active Data Exchange),
(Hewlett-Packard),ChrisFerris(SunDaniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Tony Graham (Sun Microsystems),
Mike Greenberg (IONA Technologies),
Rich Greenfield (Library of Congress),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Frederick Hirsch (Zolera Systems),
Gerd Hoelzing (SAP AG),
Erin Microsystems),HoffmanHoffmann (Tradia Inc.),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu (Tradia),SoftwareLimited),
Oisin Hurley (IONA Technologies),
Yin-Leng Husband Corporation),(Hewlett Packard, formerly of Compaq),
John Ibbotson (IBM),
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
Scott Isaacson (Hewlett-Packard,(Novell, Inc.),
Kazunori Iwasa (Fujitsu Limited),
Murali Janakiraman (Rogue Wave),
Mario Jeckle (DaimlerChrysler Research and Technology),
Eric Jenkins (Engenia Software),
Mark Jones (AT&T),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Suresh Kodichath (IONA Technologies),
Richard Koo (Vitria Technology Inc.),
Jacek Kopecky (Systinet),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
(Novell),AmyLewisMichah Lerner (AT&T),
Bob Lojek (TIBCO),(Intalio Inc.),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Michael Mahan (Nokia),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
(Intalio),HighlandMaryMountainNoah Mendelsohn (IBM, formerly of Lotus Development),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Nilo Mitra (Ericsson),
Ed Mooney (Sun Microsystems),
Jean-Jacques Moreau (Canon),
Dean Moses (Epicentric),
Highland Mary Mountain (Intel),
Don Mullen (Intel),(TIBCO Software, Inc.),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Tibco),(Cisco Systems),
Masahiko Narita (Fujitsu Limited),
Mark Needleman (Data Research Associates),
Art Nevarez (Cisco),(Novell, Inc.),
Henrik Nielsen (Microsoft Corporation),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
Conleth O'Connell (Vignette),
Kevin Perkins (Compaq),
Doug Purdy (Microsoft Corporation),
Jags Ramnaryan (BEA Systems),
Andreas Riegg (DaimlerChrysler Research and Technology),
Vilhelm Rosenqvist (NCR),
Herve Ruellan (Canon),
Marwan Sabbouh (Novell),(MITRE Corporation),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (MITRE),(Zolera Systems),
Krishna Sankar (Zolera),(Cisco Systems),
Jeff Schlimmer (Microsoft Corporation),
George Scott (Cisco),(Tradia Inc.),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
(Tradia),SimeonSimeonovMiroslav Simek (Systinet),
Simeon Simeonov (Macromedia),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Anne Thomas Manes (Sun Microsystems),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (Allaire),(webMethods),
Mike Vernal (Microsoft Corporation),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Volker Wiechers (SAP AG),
Stuart Williams (WebMethods),(Hewlett Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (Hewlett-Packard),(MartSoft Corp.).
(Martsoft).
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.