Basic Profile Version 2.0

Editors' Draft - revision 66

2009-10-16

This revision:

http://mp.ws-i.org/apps/org/workgroup/bpwg/download.php/BasicProfile-2.0-ED.html?versionID=$Revision: 1.26 $

Latest revision:

http://mp.ws-i.org/apps/org/workgroup/bpwg/download.php/BasicProfile-2.0-ED.html

Editors:

Robert Chumbley , IBM

Jacques Durand , Fujitsu

Gilbert Pilz , Oracle

Tom Rutt , Fujitsu

Administrative contact:

secretary@ws-i.org

Abstract

This document defines the WS-I Basic Profile 2.0, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability. It also contains a set of executable test assertions for assessing the conformance to the profile.

Status of this Document

This document is an editors' copy that has no official standing; it is not complete. Other documents may supersede this document. Discussion of this document takes place on the Member-only mailing list, wsi_wsbasic@lists.ws-i.org.

Notice

The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this material or WS-I. The material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Feedback

The Web Services-Interoperability Organization (WS-I) would like to receive input, suggestions and other feedback ("Feedback") on this work from a wide variety of industry participants to improve its quality over time.

By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an individual, and your company if you are providing Feedback on behalf of the company) will be deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner whatsoever the Feedback you provide regarding the work. You acknowledge that you have no expectation of confidentiality with respect to any Feedback you provide. You represent and warrant that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you represent and warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all of your Feedback in a future version of the work, it may, but is not obligated to include your name (or, if you are identified as acting on behalf of your company, the name of your company) on a list of contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf you are acting, please do not provide any Feedback.

Feedback on this document should be directed to wsbasic_comment@ws-i.org.

1. Introduction
1.1. Relationships to Other Profiles
1.2. Guiding Principles
1.3. Test Assertions
1.4. Compatibility with Basic Profile 1.1 and 1.2
1.5. Notational Conventions
1.6. Profile Identification and Versioning
2. Profile Conformance
2.1. Conformance Requirements
2.2. Conformance Targets
2.3. Conformance Scope
2.4. Claiming Conformance
3. Messaging
3.1. Message Serialization
3.1.1. XML Envelope Serialization
3.1.2. Unicode BOMs
3.1.3. XML Declarations
3.1.4. Character Encodings
3.1.5. XOP Encoded Messages
3.2. SOAP Envelopes
3.2.1. SOAP Envelope Structure
3.2.2. SOAP Body Namespace Qualification
3.2.3. Disallowed Constructs
3.2.4. xsi:type Attributes
3.2.5. SOAP 1.2 attributes on SOAP 1.2 elements
3.3. SOAP Processing Model
3.3.1. SOAP Fault Processing
3.4. SOAP Faults
3.4.1. Identifying SOAP Faults
3.5. Use of SOAP in HTTP
3.5.1. HTTP Protocol Binding
3.5.2. Parameters on the Content-Type MIME Header
3.5.3. HTTP Success Status Codes
3.5.4. HTTP Redirect Status Codes
3.5.5. HTTP Cookies
3.5.6. Non-Addressable Consumers and Instances
3.6. Use of URIs in SOAP
3.6.1. Use of SOAP-defined URIs
3.7. WS-Addressing Support
3.7.1. Requiring WS-Addressing SOAP headers
3.7.2. NotUnderstood block in MustUnderstand Fault on WS-Addressing SOAP headers
3.7.3. Use of wsa:Action and WS-Addressing 1.0 - Metadata
3.7.4. Valid Values for action Parameter on the Content-Type MIME header When WS-Addressing is Used
3.7.5. SOAP Defined Faults Action URI
3.7.6. Understanding WS-Addressing SOAP Header Blocks
3.7.7. Ignored or Absent WS-Addressing MAPs
3.7.8. Present and Understood WS-Addressing MAPs
3.7.9. SOAP MustUnderstand or VersionMismatch fault Transmission
3.7.10. Faulting Behavior with Present and Understood WS-Addressing MAPs
3.7.11. [message id] and One-Way Operations
3.7.12. Refusal to Honor WS-Addressing MAPs
3.7.13. Use of Non-Anonymous Response EPRs
3.7.14. Optionality of the wsa:To header
3.7.15. Extending WSDL Endpoints with an EPR
3.7.16. Combining Synchronous and Asynchronous Operations
3.7.17. Conflicting Addressing Policies
4. Service Description
4.1. Required Description
4.2. Document Structure
4.2.1. WSDL Schema Definitions
4.2.2. WSDL and Schema Import
4.2.3. WSDL Import location Attribute Structure
4.2.4. WSDL Import location Attribute Semantics
4.2.5. Placement of WSDL import Elements
4.2.6. XML Version Requirements
4.2.7. XML Namespace Declarations
4.2.8. WSDL and the Unicode BOM
4.2.9. Acceptable WSDL Character Encodings
4.2.10. Namespace Coercion
4.2.11. WSDL documentation Element
4.2.12. WSDL Extensions
4.3. Types
4.3.1. QName References
4.3.2. Schema targetNamespace Structure
4.3.3. soapenc:Array
4.3.4. WSDL and Schema Definition Target Namespaces
4.3.5. Multiple GED Definitions with the same QName
4.3.6. Multiple Type Definitions with the same QName
4.4. Messages
4.4.1. Bindings and Parts
4.4.2. Bindings and Faults
4.4.3. Unbound portType Element Contents
4.4.4. Declaration of part Elements
4.5. Port Types
4.5.1. Ordering of part Elements
4.5.2. Allowed Operations
4.5.3. Distinctive Operations
4.5.4. parameterOrder Attribute Construction
4.5.5. Exclusivity of type and element Attributes
4.6. Bindings
4.6.1. Use of SOAP Binding
4.7. SOAP Binding
4.7.1. Specifying the transport Attribute
4.7.2. HTTP Transport
4.7.3. Consistency of style Attribute
4.7.4. Encodings and the use Attribute
4.7.5. Multiple Bindings for portType Elements
4.7.6. Operation Signatures
4.7.7. Multiple Ports on an Endpoint
4.7.8. Child Element for Document-Literal Bindings
4.7.9. One-Way Operations
4.7.10. Namespaces for wsoap12 Elements
4.7.11. Consistency of portType and binding Elements
4.7.12. Enumeration of Faults
4.7.13. Type and Name of SOAP Binding Elements
4.7.14. name Attribute on Faults
4.7.15. Omission of the use Attribute
4.7.16. Default for use Attribute
4.7.17. Consistency of Envelopes with Descriptions
4.7.18. Response Wrappers
4.7.19. Part Accessors
4.7.20. Namespaces for Children of Part Accessors
4.7.21. Required Headers
4.7.22. Allowing Undescribed Headers
4.7.23. Ordering Headers
4.7.24. Describing action Parameter on the Content-Type MIME Header
4.7.25. SOAPAction HTTP Header
4.7.26. SOAP Binding Extensions
4.8. http://mp.ws-i.org/apps/org/workgroup/bpwg/download.php/5013/latest/BasicProfile-2.0-ED.html#WSDL11SOAP12SA
4.9. Use of XML Schema
4.10. WS-Addressing 1.0 - Metadata
5. Service Publication and Discovery
5.1. bindingTemplates
5.2. tModels
6. Security
6.1. Use of HTTPS
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Normative References
Appendix D: Defined Terms
Appendix E: Acknowledgements

1. Introduction

This document defines the WS-I Basic Profile 2.0 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability.

Section 1 introduces the Profile, and explains its relationships to other profiles.

Section 2, "Profile Conformance," explains what it means to be conformant to the Profile.

Each subsequent section addresses a component of the Profile, and consists of two parts; an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.

1.1 Relationships to Other Profiles

This Profile is derived from the Basic Profile 1.1 by incorporating any errata to date and including those requirements related to the serialization of envelopes and their representation in messages from the Simple SOAP Binding Profile 1.0 .

This Profile is NOT intended to be composed with the Simple SOAP Binding Profile 1.0. The Attachments Profile 1.0 adds support for SOAP with Attachments, and is intended to be used in combination with this Profile.

1.2 Guiding Principles

The Profile was developed according to a set of principles that, together, form the philosophy of the Profile, as it relates to bringing about interoperability. This section documents these guidelines.

No guarantee of interoperability

It is impossible to completely guarantee the interoperability of a particular service. However, the Profile does address the most common problems that implementation experience has revealed to date.

Application semantics

Although communication of application semantics can be facilitated by the technologies that comprise the Profile, assuring the common understanding of those semantics is not addressed by it.

Testability

When possible, the Profile makes statements that are testable. However, such testability is not required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts "on the wire").

Strength of requirements

The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce ambiguity and mismatches between implementations.

Restriction vs. relaxation

When amplifying the requirements of referenced specifications, the Profile may restrict them, but does not relax them (e.g., change a MUST to a MAY).

Multiple mechanisms

If a referenced specification allows multiple mechanisms to be used interchangeably, the Profile selects those that are well-understood, widely implemented and useful. Extraneous or underspecified mechanisms and extensions introduce complexity and therefore reduce interoperability.

Future compatibility

When possible, the Profile aligns its requirements with in-progress revisions to the specifications it references. This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration.

Compatibility with deployed services

Backwards compatibility with deployed Web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues.

Focus on interoperability

Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability.

Conformance targets

Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP messages) rather than the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone.

Lower-layer interoperability

The Profile speaks to interoperability at the application layer; it assumes that interoperability of lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and well-understood. Similarly, statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting Web services specifically; WS-I does not attempt to assure the interoperability of these protocols as a whole. This assures that WS-I's expertise in and focus on Web services standards is used effectively.

1.3 Test Assertions

This profile document contains embedded Test Assertions (TA) that are associated with each normative profile requirement. In the HTML rendering of this document, these test assertions are accessible via a toggle link at the end of each requirement. When clicking on such a link, a table pops up that displays the TA parts. At the end of this table is another toggle link ("help-glossary") that displays an explanation glossary for the TA structure. In other formats of this document, the test assertions are grouped in an appendix not controlled by any link, in order to facilitate the printing of hard copies. The resulting set of test assertions embedded in this document represents a conformance test suite for the profile.

Release notes related to the test material included in this document are available here:

TESTING-RELEASE-NOTES

Note Item:	Release Notes : 2009-08-26
test suite	The test assertions are scripted using XPath2.0 and are automatically processable using the version 2.0 of the WS-I Analyzer tools. Several requirements have been tagged "NOT_TESTABLE". This means that these requirements cannot be tested based on the technology choices (black-box testing, XPath scripting). Other requirements have been tagged "NOT_TESTED". This is the case for most optional requirements (SHOULD, MAY), and for most Extensibility points as well as for requirements targeting UDDI. Other requirements have been tagged "TESTABLE_SCENARIO_DEPENDENT". This is the case when a specific test scenario is needed in order to exercise the related test assertion, because the test assertion is designed to trigger only on specific input material, e.g. that is known to NEVER be recognizable by an endpoint. A subsequent version may cover untested requirements. In this profile, the core requirements for assessing interoperability of implementations have been initially targeted.
test assertions notes	Test assertions are not guaranteed to exhaustively cover every case where a profile requirement applies. In several instances, more than one test assertion is needed to address the various situations where a profile requirement applies. To learn more about the details of test assertion outcomes and how they are reported in the test report, see the glossary link that appears below each test assertion table.
test log rules	*Test Log content conventions:* The test assertions designed for this test suite are written to work over "test log" files that are assumed to follow some rules in their structure and content. These rules are more completely stated in the documentation associated with the log file description. Some of these rules are: - Every message in the log must be uniquely identified: it must have a unique pair of values for: {message/@conversation, message/@id}, where @id is unique within each conversation. Typically, a conversation is used to identify an HTTP connection and the group of messages over this connection. - A response message (for WSDL request-responses as well as RM lifecycle messages) always appears after the request message in the log file. - A wsa:RelatesTo reference always refers to a message that has been logged before. - A Fault message always appears after the message-in-error. - An RM acknowledgement always appears after the messages it acknowledges. - there should not be both a doc-lit and an rpc-lit bindings for the same portType. - imports must be resolved locally to the log file.

1.4 Compatibility with Basic Profile 1.1 and 1.2

The Basic Profile 2.0 is the first version of the WS-I Basic Profile that changes the version of SOAP in the profile scope from SOAP 1.1 to the W3C SOAP 1.2 Recommendation. As such, clients, servers and the artifacts that comprise a Basic Profile 1.0, 1.1 or 1.2 conformant application are inherently incompatible with an application that is conformant with the Basic Profile 2.0. However, in general, the Basic Profile WG members have tried to preserve in the Basic Profile 2.0 as much consistency with the guidance and constraints of the Basic Profile 1.0, 1.1 and 1.2 as possible. This has been in part facilitated by the fact that the WG tried to remain consistent in the guidance and constraints of the original Basic Profile with the decisions that were being made in the context of the W3C XML Protocols WG as they were concurrently working on the SOAP 1.2 specificatons. For the most part, issues that were resolved in the context of the development of the Basic Profile 1.0, 1.1 and 1.2 were not revisited.

1.5 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in " Conformance Requirements") are presented in the following manner:

RnnnnStatement text here.

where "nnnn" is replaced by a number that is unique among the requirements in the Profile, thereby forming a unique requirement identifier.

Requirement identifiers can be considered to be namespace qualified, in such a way as to be compatible with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed to "bp10:R9999"), it should be interpreted as being in the namespace identified by the conformance URI of the document section it occurs in. If it is qualified, the prefix should be interpreted according to the namespace mappings in effect, as documented below.

Some requirements clarify the referenced specification(s), but do not place additional constraints upon implementations. For convenience, clarifications are annotated in the following manner: C

Some requirements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "WSDL20" for WSDL Version 2.0). Note that because such work was not complete when this document was published, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

As noted above, some requirements may present compatibility issues (whether forwards or backwards) with previously published versions of the profile. For convenience, such requirements are annotated in the following manner: Compat

Extensibility points in underlying specifications (see " Conformance Scope") are presented in a similar manner:

EnnnnExtensibility Point Name - Description

where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As with requirement statements, extensibility statements can be considered namespace-qualified.

This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

soap12 - " http://www.w3.org/2003/05/soap-envelope "
xsi - " http://www.w3.org/2001/XMLSchema-instance "
xsd - " http://www.w3.org/2001/XMLSchema "
soapenc - " http://www.w3.org/2003/05/soap-encoding "
wsdl - " http://schemas.xmlsoap.org/wsdl/ "
wsoap12 - " http://schemas.xmlsoap.org/wsdl/soap12/ "
uddi - "urn:uddi-org:api_v2"
wsa - " http://www.w3.org/2005/08/addressing "
xop - " http://www.w3.org/2004/08/xop/include "

1.6 Profile Identification and Versioning

This document is identified by a name (in this case, Basic Profile) and a version number (here, 2.0). Together, they identify a particular profile instance.

Version numbers are composed of a major and minor portion, in the form "major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances.

Instances of profiles with the same name (e.g., "Example Profile 1.1" and "Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances).

One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g., "Example Profile 1.0" and "Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.

2 Profile Conformance

Conformance to the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This section explains these terms and describes how conformance is defined and used.

2.1 Conformance Requirements

Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Profile are considered normative, and those in the specifications it references that are in-scope (see "Conformance Scope") should likewise be considered normative. When requirements in the Profile and its referenced specifications contradict each other, the Profile's requirements take precedence for purposes of Profile conformance.

Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified (e.g., R9999) for convenience.

For example;

R9999 Any WIDGET SHOULD be round in shape.

This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a conditional requirement upon widgets; i.e., although this requirement must be met to maintain conformance in most cases, there are some situations where there may be valid reasons for it not being met (which are explained in the requirement itself, or in its accompanying text).

Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold text (e.g. " MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target. Additional text may be included to illuminate a requirement or group of requirements (e.g., rationale and examples); however, prose surrounding requirement statements must not be considered in determining conformance.

Definitions of terms in the Profile are considered authoritative for the purposes of determining conformance.

None of the requirements in the Profile, regardless of their conformance level, should be interpreted as limiting the ability of an otherwise conforming implementation to apply security countermeasures in response to a real or perceived threat (e.g., a denial of service attack).

2.2 Conformance Targets

Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to.

This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances).

Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.

The following conformance targets are used in the Profile:

MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
ENVELOPE - the serialization of the soap12:Envelope element and its content
DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and data format bindings, and the network access points associated with Web services (e.g., WSDL descriptions) (from Basic Profile 1.0)
INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate (from Basic Profile 1.0)
CONSUMER - software that invokes an INSTANCE (from Basic Profile 1.0)
SENDER - software that generates a message according to the protocol(s) associated with it (from Basic Profile 1.0)
RECEIVER - software that consumes a message according to the protocol(s) associated with it (e.g., SOAP processors) (from Basic Profile 1.0)
REGDATA - registry elements that are involved in the registration and discovery of Web services (e.g. UDDI tModels) (from Basic Profile 1.0)
SIMPLE_SOAP_MESSAGE - A MESSAGE that has as an entity-body that has a 'Content-Type' HTTP header field with a field-value of 'application/soap+xml'
XOP_ENCODED_MESSAGE - A MESSAGE that has an entity-body that has a 'Content-Type' HTTP header field with a field-value of 'multipart/related' with a type parameter of 'application/xop+xml'

2.3 Conformance Scope

The scope of the Profile delineates the technologies that it addresses; in other words, the Profile only attempts to improve interoperability within its own scope. Generally, the Profile's scope is bounded by the specifications referenced by it.

The Profile's scope is further refined by extensibility points. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use or non-use is not relevant to conformance.

Note that the Profile may still place requirements on the use of an extensibility point. Also, specific uses of extensibility points may be further restricted by other profiles, to improve interoperability when used in conjunction with the Profile.

Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.

The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the extensibility points in Appendix B.

2.4 Claiming Conformance

Claims of conformance to the Profile can be made using the following mechanisms, as described in Conformance Claim Attachment Mechanisms, when the applicable Profile requirements associated with the listed targets have been met:

WSDL 1.1 Claim Attachment Mechanism for Web Services Instances - MESSAGE DESCRIPTION INSTANCE RECEIVER
WSDL 1.1 Claim Attachment Mechanism for Description Constructs - DESCRIPTION
UDDI Claim Attachment Mechanism for Web Services Instances - MESSAGE DESCRIPTION INSTANCE RECEIVER
UDDI Claim Attachment Mechanism for Web Services Registrations - REGDATA

The conformance claim URI for this Profile is " http://ws-i.org/profiles/basic/2.0 " .

3. Messaging

This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:

SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
Extensibility points:

E0001 - Header blocks - Header blocks are the fundamental extensibility mechanism in SOAP. TESTABLE BP1901

Test Assertion:	BP1901
Description:	The soap12:Envelope contains other header blocks.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Header[some $hbloc in child::* satisfies not(fn:namespace-uri($hbloc) = 'http://www.w3.org/2005/08/addressing') and not($hbloc/attribute::*:IsReferenceParameter) ]]
Predicate:	fn:true()
Reporting:	true=passed, false=failed
Prescription:	permitted
Error Message:	Extensibility Point WARNING: The soap12:Envelope makes use of extra SOAP headers
Diagnostic Data:

HELP - GLOSSARY

Test Assertion Part	What it means:
Test Assertion ID:	[ markup: testAssertion/@id] (required) A unique ID for the current test assertion.
Description:	[ markup: testAssertion/description* ]* (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate.
Comments:	[ markup: testAssertion/comments* ]* (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.).
Target:	[ markup: testAssertion/target* ]* (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined See the "reporting" item for the meaning of these results.
Cotarget:	[ markup: testAssertion/cotarget* ]* (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate.
Prerequisite:	[ markup: testAssertion/@preReq* ]* (optional) [ markup: testAssertion/prerequisite* ]* (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]).
Predicate:	[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report). - A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]).
Prescription:	[ markup: testAssertion/prescription/@level* ]* (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL.
Reporting:	[ markup: testAssertion/reporting* ]* (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present: § @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed') § @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed') The reported outcomes have the following meaning: § passed: the target passes the test and can be considered as fulfilling the profile feature. § failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are: § notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

E0002 - Processing order - The order of processing of a SOAP envelope's components (e.g., headers) is unspecified, and therefore may need to be negotiated out-of-band. NOT_TESTABLE
E0003 - Use of intermediaries - SOAP Intermediaries is an underspecified mechanism in SOAP 1.2, and their use may require out-of-band negotiation. Their use may also necessitate careful consideration of where Profile conformance is measured. NOT_TESTABLE
E0004 - soap role values - Values of the soap role attribute, other than the special uri 'http://www.w3.org/2003/05/soap-envelope/role/next' , represent a private agreement between parties of the web service. TESTABLE BP1904

Test Assertion:	BP1904
Description:	The soap12:Envelope contains @role with unspecified values.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[.//attribute::*:role]
Predicate:	every $rval in .///attribute:::role satisfies ($rval = 'http://www.w3.org/2003/05/soap-envelope/role/next' or $rval = 'http://www.w3.org/2003/05/soap-envelope/role/none')
Reporting:	true=passed, false=failed
Prescription:	permitted
Error Message:	Extensibility Point WARNING: The soap12:Envelope contains @role with unspecified values
Diagnostic Data:

HELP - GLOSSARY

Test Assertion Part	What it means:
Test Assertion ID:	[ markup: testAssertion/@id] (required) A unique ID for the current test assertion.
Description:	[ markup: testAssertion/description* ]* (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate.
Comments:	[ markup: testAssertion/comments* ]* (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.).
Target:	[ markup: testAssertion/target* ]* (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined See the "reporting" item for the meaning of these results.
Cotarget:	[ markup: testAssertion/cotarget* ]* (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate.
Prerequisite:	[ markup: testAssertion/@preReq* ]* (optional) [ markup: testAssertion/prerequisite* ]* (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]).
Predicate:	[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report). - A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]).
Prescription:	[ markup: testAssertion/prescription/@level* ]* (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL.
Reporting:	[ markup: testAssertion/reporting* ]* (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present: § @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed') § @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed') The reported outcomes have the following meaning: § passed: the target passes the test and can be considered as fulfilling the profile feature. § failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are: § notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

E0005 - Fault details - the contents of a Fault's detail element are not prescribed by SOAP 1.2. TESTABLE BP1905

Test Assertion:	BP1905
Description:	The soap12:Envelope contains a Fault with unspecified Detail content.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Body/soap12:Fault/soap12:Detail]
Predicate:	fn:true()
Reporting:	true=passed, false=failed
Prescription:	permitted
Error Message:	Extensibility Point WARNING: The soap12:Fault makes use of optional Detail element
Diagnostic Data:

HELP - GLOSSARY

Test Assertion Part	What it means:
Test Assertion ID:	[ markup: testAssertion/@id] (required) A unique ID for the current test assertion.
Description:	[ markup: testAssertion/description* ]* (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate.
Comments:	[ markup: testAssertion/comments* ]* (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.).
Target:	[ markup: testAssertion/target* ]* (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined See the "reporting" item for the meaning of these results.
Cotarget:	[ markup: testAssertion/cotarget* ]* (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate.
Prerequisite:	[ markup: testAssertion/@preReq* ]* (optional) [ markup: testAssertion/prerequisite* ]* (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]).
Predicate:	[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report). - A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]).
Prescription:	[ markup: testAssertion/prescription/@level* ]* (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL.
Reporting:	[ markup: testAssertion/reporting* ]* (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present: § @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed') § @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed') The reported outcomes have the following meaning: § passed: the target passes the test and can be considered as fulfilling the profile feature. § failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are: § notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

E0006 - Envelope serialization - The Profile does not constrain some aspects of how the envelope is serialized into the message. NOT_TESTABLE

SOAP Version 1.2 Part 2: Adjuncts (Second Edition)
Extensibility points:

E0026 - SOAP envelope in HTTP Response message to WSDL one-way operation - The SOAP 1.2 Request Response Binding specification does not specify the purpose or processing of such envelopes. TESTABLE

RFC2616: Hypertext Transfer Protocol -- HTTP/1.1
Extensibility points:

E0007 - HTTP Authentication - HTTP authentication allows for extension schemes, arbitrary digest hash algorithms and parameters. TESTABLE
E0008 - Unspecified Header Fields - HTTP allows arbitrary headers to occur in messages. TESTABLE
E0009 - Expect-extensions - The Expect/Continue mechanism in HTTP allows for expect-extensions. TESTABLE
E0010 - Content-Encoding - The set of content-codings allowed by HTTP is open-ended and any besides 'gzip', 'compress', or 'deflate' are an extensibility point. TESTABLE
E0011 - Transfer-Encoding - The set of transfer-encodings allowed by HTTP is open-ended. TESTABLE
E0012 - Upgrade - HTTP allows a connection to change to an arbitrary protocol using the Upgrade header. TESTABLE
E0024 - Namespace Attributes - Namespace attributes on soap12:Envelope and soap12:Header elements TESTABLE
E0025 - Attributes on soap12:Body elements - Neither namespaced nor local attributes are constrained by SOAP 1.2. TESTABLE
E0029 - Use of messages other than SOAP 1.2 or XOP messages - Use of Messages other than a SIMPLE_SOAP_MESSAGE or a XOP_ENCODED_MESSAGE is an extensibility point TESTABLE

RFC2965: HTTP State Management Mechanism
WS-Addressing 1.0 - Core
WS-Addressing 1.0 - SOAP Binding (except for sections 4, 5.1.1, 5.2.1 and 6.2)
Extensibility points:

E0027 - Use of soaactor and WS-Addressing - WS-Addressing allows multiple instances of headers such as wsa:To, wsa:ReplyTo, and wsa:FaultTo, so long as they are targeted to different SOAP roles. TESTABLE
E0028 - Endpoint references are extensible - When extension attributes or elements appear as part of an endpoint reference, the processing model for such extensions is defined by the specification for those extensions. NOT_TESTABLE

WS-Addressing 1.0 - Metadata (except for sections 4.1.1, 4.4.2, 4.4.3 and 5.2)
SOAP Message Transmission Optimization Mechanism
XML-Binary Optimized Packaging

3.1 Message Serialization

The profile is intended to compose with mechanisms currently under development to describe whether messages are encoded as SIMPLE_SOAP_MESSAGEs or XOP_ENCODED_MESSAGEs. As such it does not mandate that both of those encodings be supported for any given operation. Indeed, neither of these encodings need be supported if an alternate encoding such as that described in the Attachments Profile 1.0 is used.

SOAP 1.2 defines an XML structure for transmitting messages, the envelope. The Profile places the following constraints on the use and serialization of the soap12:Envelope element and its content:

This section of the Profile incorporates the following specifications by reference:

Attachments Profile Version 1.0

3.1.1 XML Envelope Serialization

R9701 (from issue: ) An ENVELOPE MUST be serialized as XML 1.0. TESTABLE BP1019

Test Assertion:	BP1019
Description:	The soap12:Envelope in the message is a well-formed XML 1.0 document.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
co-Target: metadata	$target/../../wsil:messageContents[@validXml and @xmlVersion]
Predicate:	$target/../../wsil:messageContents[@validXml = fn:true() and @xmlVersion = '1.0']
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The soap12:Envelope does not conform to XML 1.0.
Diagnostic Data:	{SOAP message}{any XML parser error messages}

Test Assertion:	BP1015
Description:	A receiver must not fault messages with envelopes that contain an XML Declaration.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents[@containsXmlDecl = 'true']/soap12:Envelope
Predicate:	not (/wsil:testLog/wsil:messageLog/wsil:message[(@type = 'response' and @conversation = $target/../../@conversation) or (.//soap12:Envelope/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/soap12:Header/wsa:MessageID)]/wsil:messageContents/soap12:Envelope/soap12:Body/soap12:Fault )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A soap Fault has been generated when receiving a message with an XML declaration: verify that this Fault has another cause - it must not be caused by the XML declaration.
Diagnostic Data:	{SOAP message}

Test Assertion:	BP1018
Description:	The logged SOAP envelope is a UTF-8 transcript of an envelope originally encoded as UTF-8 or UTF-16. The HTTP Content-Type header's charset value is either UTF-8 or UTF-16. Looking at the messageContent element of the logged message, either (1) it has a BOM attribute which maps the charset value in the Content-Type header, or (2) it has it has an XML declaration which matches the charset value in the Content-Type header, or (3) there is no BOM attribute and no XML declaration, and the charset value is UTF-8.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
Predicate:	$target/../../wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'charset' and (fn:starts-with(fn:lower-case(@value), 'utf-8') or fn:starts-with(fn:lower-case(@value),'utf-16'))] or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-8') or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-16')
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	Either (1a) the message contains a Content-Type header but no charset value, or (1b) the charset value is neither UTF-8 nor UTF-16, or (2) there is a BOM attribute in the messageContent element, but its value does not match the charset value, or (3) there is an XML declaration, and the charset value does not match its value, or (4) there is no BOM attribute, no XML declaration, and the charset value in Content-Type header is not UTF-8.
Diagnostic Data:	Complete message.

Test Assertion:	BP1020
Description:	A XOP_ENCODED_MESSAGE MUST include the start-info parameter in the Content-Type header of the enclosing multipart/related MIME entity body.
Target:	/wsil:testLog/wsil:messageLog/wsil:message[wsil:httpHeaders/wsil:contentTypeHeader/@type = 'multipart' and wsil:httpHeaders/wsil:contentTypeHeader/@subtype = 'related' and wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value= 'application/xop+xml']
Predicate:	wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[fn:lower-case(@key) = 'start-info' and @value != '']
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The XOP_ENCODED_MESSAGE does not include the start-info parameter with proper @value.
Diagnostic Data:

Test Assertion:	BP1021
Description:	A XOP_ENCODED_MESSAGE SHOULD include the full value of the type parameter from the root entity body part inside the start-info parameter of the enclosing multipart/related MIME entity body part's Content-Type header.
Target:	/wsil:testLog/wsil:messageLog/wsil:message[wsil:httpHeaders/wsil:contentTypeHeader/@type = 'multipart' and wsil:httpHeaders/wsil:contentTypeHeader/@subtype = 'related' and wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value = 'application/xop+xml']
Predicate:	some $rootContentID in string(wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'start']/@value) satisfies string(wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[fn:lower-case(@key) = 'start-info']/@value) = string(wsil:messageAttachments//:mimeHeaders[ :mimeHeader[@key = 'Content-ID' and @value = $rootContentID]]/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value)
Reporting:	true=passed, false=failed
Prescription:	preferred
Error Message:	The XOP_ENCODED_MESSAGE SHOULD include the full value of the type parameter
Diagnostic Data:

Test Assertion:	BP1600
Description:	The envelope conforms to the structure specified in SOAP 1.2 Part 1, Section 5.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
co-Target: metadata	$target/../@schemaValid
Predicate:	$target/../@schemaValid = fn:true()
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The envelope does not conform to the structure specified in SOAP 1.2 Part 1, Section 5
Diagnostic Data:	SOAP envelope.

Test Assertion:	BP1881
Description:	The envelope must have exactly zero or one child elements of the soap12:Body
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
Predicate:	count(soap12:Body/*) le 1
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The envelope does not have exactly zero or one child elements of the soap12:Body
Diagnostic Data:	SOAP envelope.

Test Assertion:	BP1202
Description:	Each child element (if any) of the soap12:Body element is namespace qualified (not the grandchildren).
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[count(soap12:Body/*) > 0]
Predicate:	fn:namespace-uri-from-QName(fn:node-name(soap12:Body/*)) != ''
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A child element of the soap12:Body element is not namespace qualified.
Diagnostic Data:	SOAP envelope.

Test Assertion:	BP1007
Description:	DTDs relating to soap12:Header or soap12:Body documents, are not present in the envelope: no DOCTYPE element is present.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
co-Target: metadata	$target/../@containsDTD
Predicate:	not(../@containsDTD = fn:true())
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The soap12:Header or soap12:Body elements in the envelope, were described with an included DTD.
Diagnostic Data:	SOAP envelope.

Test Assertion:	BP1208
Description:	The SOAP envelope does not include XML processing instructions.
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
co-Target: metadata	$target/../@containsProcessingInstructions
Predicate:	not(../@containsProcessingInstructions = fn:true())
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	a SOAP envelope contains XML processing instructions.
Diagnostic Data:	SOAP envelope.

Test Assertion:	BP1033
Description:	The SOAP envelope does not contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
Predicate:	not(.//*[fn:namespace-uri(.) = 'http://www.w3.org/XML/1998/namespace'])
Reporting:	true=passed, false=failed
Prescription:	preferred
Error Message:	The SOAP envelope contains the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Diagnostic Data:	SOAP envelope

Test Assertion:	BP1002
Description:	If it is a request, the arg #2 of POST is <HTTP/1.1> or <HTTP/1.0>. If absent, first line of the body is: HTTP-Version = HTTP/1.1. (or HTTP/1.0). If it is a response, it starts with <HTTP/1.1> or <HTTP/1.0>
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']
Predicate:	fn:contains(wsil:httpHeaders/wsil:requestLine/text(), 'HTTP/1.0') or fn:contains(wsil:httpHeaders/wsil:requestLine/text(), 'HTTP/1.1')
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The message is not sent using HTTP/1.1 or HTTP/1.0.
Diagnostic Data:	All HTTP headers.

Test Assertion:	BP1032
Description:	The soap12:Envelope, soap12:Header, and soap12:Body elements do not have any attributes in the namespace "http://schemas.xmlsoap.org/soap/envelope/"
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
Predicate:	every $attrib in (self::node()/attribute::, ./soap12:Header/attribute::, ./soap12:Body/attribute::*) satisfies fn:namespace-uri($attrib) != 'http://www.w3.org/2003/05/soap-envelope' and fn:namespace-uri($attrib) != 'http://schemas.xmlsoap.org/soap/envelope/'
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A soap12:Envelope, soap12:Header, or soap12:Body element has an attribute in the namespace "http://schemas.xmlsoap.org/soap/envelope/".
Diagnostic Data:	SOAP envelope

Test Assertion:	BP1001
Description:	If it is a request, the arg #2 of POST is <HTTP/1.1>. If absent, first line of the body is: HTTP-Version = HTTP/1.1. If it is a response, it starts with <HTTP/1.1>
Target:	//message
Prerequisite:	BP1002
Predicate:	contains(wsil:httpHeaders/requestLine/text(), 'HTTP/1.1')
Reporting:	true=passed, false=failed
Prescription:	preferred
Error Message:	The message is not sent using HTTP/1.1.
Diagnostic Data:	All HTTP headers.

Test Assertion:	BP1006
Description:	The SOAPAction header contains a quoted string of any value, including "".
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request'][wsil:httpHeaders/wsil:contentTypeHeader]
Predicate:	every $par in wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter satisfies not($par/@quoted) or not($par/@key eq 'type' or fn:lower-case($par/@key) eq 'start-info' or $par/@key eq 'action' or $par/@key eq 'boundary') or $par/@quoted = fn:true()
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	SOAPAction HTTP header does not contain a quoted string.
Diagnostic Data:	All HTTP headers.

Test Assertion:	BP1100
Description:	The message uses a "200 OK" HTTP status code.
Target:	//wsil:message[@type='response'][wsil:messageContents/soap12:Envelope/soap12:Body[not(soap12:Fault)]]
Predicate:	contains(wsil:httpHeaders/wsil:requestLine, "200 OK")
Reporting:	true=passed, false=failed
Prescription:	preferred
Error Message:	The envelope of the response message does not contain a soap12:Fault and the message does not use a "200 OK" HTTP status code.
Diagnostic Data:	Complete message.

Test Assertion:	BP1101
Description:	The response message, if successfully processed at HTTP level, is sent using either a "200 OK" or "202 Accepted" HTTP status code.
Target:	//wsil:message[@type='response'][wsil:messageContents[not(soap12:Envelope)]][not (matches(wsil:httpHeaders/wsil:requestLine, "4[0-9][0-9]"))]
Predicate:	contains(wsil:httpHeaders/wsil:requestLine, "200 OK") or contains(wsil:httpHeaders/wsil:requestLine, "202 Accepted")
Reporting:	true=passed, false=failed
Prescription:	preferred
Error Message:	A response message without a SOAP message, is not using either a "200 OK" or "202 Accepted" HTTP status code, though successful at HTTP level.
Diagnostic Data:	Complete message.

Test Assertion:	BP1142a
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/wsil:messageContents/soap12:Envelope [soap12:Header[ wsa:Action and not (wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] )] and soap12:Body/* and not (soap12:Body/soap12:Fault) ] [ some $myenv in . satisfies some $message in //wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding [.//wsoap12:[@style = 'rpc']]/wsdl:operation[@name = fn:local-name-from-QName(node-name($target/soap12:Body/[1]))]
Predicate:	( if ( /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference ) then (some $portEpr in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference satisfies ( $target/soap12:Header/wsa:To ) ) else fn:true() ) and ( if ( $myOpBinding/wsdl:output ) then ($target/soap12:Header/wsa:MessageID) else fn:true() ) and (: correct wsa:Action value :) (some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/ wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:input satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Request' ),'' ) ),'/' ) ) ) )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header
Diagnostic Data:	Complete message.

Test Assertion:	BP1142b
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'response']/wsil:messageContents/ soap12:Envelope[soap12:Header[wsa:Action] and soap12:Body/* and not (soap12:Body/soap12:Fault)] [ some $myenv in . satisfies some $message in //wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:[@style = 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) = fn:local-name-from-QName(node-name($target/soap12:Body/[1]))]
co-Target: related-Request	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID = $target/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ]
Predicate:	( not ($related-Request/soap12:Header/wsa:ReplyTo) or ($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous' ) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or (@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and ( $target/soap12:Header[ not (wsa:To) or (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' )] ) and (: correct wsa:Action value :) (some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/ wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:output satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Response' ),'' ) ),'/' ) ) ) )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl
Diagnostic Data:	Complete message.

Test Assertion:	BP1142c
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a non-anonymous response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element must be present, and must have a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/wsil:messageContents/ soap12:Envelope [soap12:Body[not (soap12:Fault)] and soap12:Header [wsa:Action and (wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ) ] ] [ some $myenv in . satisfies some $message in //wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:[@style = 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) = fn:local-name-from-QName(node-name($target/soap12:Body/[1]))]
co-Target: related-Request	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID = $target/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ]
Predicate:	( ($related-Request/soap12:Header/wsa:ReplyTo) and not ($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous' ) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or (@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and ( $target/soap12:Header[ (wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' ) ] ) and (: correct wsa:Action value :) (some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/ wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:output satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Response' ),'' ) ),'/' ) ) ) )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a non-anonymous response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element must be present, and must have a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl
Diagnostic Data:	Complete message.

Test Assertion:	BP1143a
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using a doc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo present in the soap12:Header
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/wsil:messageContents/ soap12:Envelope [soap12:Body[not (soap12:Fault)] and soap12:Header [wsa:Action and not (wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ) ] ] [ some $myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1] or $myenv/soap12:Header/wsa:Action )) ) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation [ some $opBinding in . satisfies (if ($target/soap12:Body/[1] ) then (some $dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element), . ) = fn:node-name($target/soap12:Body/[1])] ] satisfies some $dopmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input [fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) = $dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true() ) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Request' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) ) else fn:true() ) ]
Predicate:	( if ( /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference ) then (some $portEpr in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference satisfies ( $target/soap12:Header/wsa:To ) ) else fn:true() ) and ( if ( $myOpBinding/wsdl:output ) then ( $target/soap12:Header/wsa:MessageID) else fn:true() )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using a doc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header
Diagnostic Data:	Complete message.

Test Assertion:	BP1143b
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence)
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'response']/wsil:messageContents/soap12:Envelope [soap12:Body[not (soap12:Fault) ] and soap12:Header[wsa:Action] ] [ some $myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1] or $myenv/soap12:Header/wsa:Action )) ) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation [ some $opBinding in . satisfies (if ($target/soap12:Body/[1] ) then (some $dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element), . ) = fn:node-name($target/soap12:Body/[1])] ] satisfies some $dopmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output [fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) = $dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true() ) (: and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Response' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) ) else fn:true() ) :) ]
co-Target: related-Request	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID = $target/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ]
Predicate:	( not ($related-Request/soap12:Header/wsa:ReplyTo) or ($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous' ) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or (@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and ( $target/soap12:Header[ not (wsa:To) or (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' )] )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence)
Diagnostic Data:	Complete message.

Basic Profile Version 2.0

Editors' Draft - revision 66

2009-10-16

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Relationships to Other Profiles

1.2 Guiding Principles

1.3 Test Assertions

1.4 Compatibility with Basic Profile 1.1 and 1.2

1.5 Notational Conventions

1.6 Profile Identification and Versioning

2 Profile Conformance

2.1 Conformance Requirements

2.2 Conformance Targets

2.3 Conformance Scope

2.4 Claiming Conformance

3. Messaging

3.1 Message Serialization

3.1.1 XML Envelope Serialization

3.1.2 Unicode BOMs

3.1.3 XML Declarations

3.1.4 Character Encodings

3.1.5 XOP Encoded Messages

3.2 SOAP Envelopes

3.2.1 SOAP Envelope Structure

3.2.2 SOAP Body Namespace Qualification

3.2.3 Disallowed Constructs

3.2.4 xsi:type Attributes

3.2.5 SOAP 1.2 attributes on SOAP 1.2 elements

3.3 SOAP Processing Model

3.3.1 SOAP Fault Processing

3.4 SOAP Faults

3.4.1 Identifying SOAP Faults

3.5 Use of SOAP in HTTP

3.5.1 HTTP Protocol Binding

3.5.2 Parameters on the Content-Type MIME Header

3.5.3 HTTP Success Status Codes

3.5.4 HTTP Redirect Status Codes

3.5.5 HTTP Cookies

3.5.6 Non-Addressable Consumers and Instances

3.6 Use of URIs in SOAP

3.6.1 Use of SOAP-defined URIs

3.7 WS-Addressing Support

3.7.1 Requiring WS-Addressing SOAP headers

3.7.2 NotUnderstood block in MustUnderstand Fault on WS-Addressing SOAP headers

3.7.3 Use of wsa:Action and WS-Addressing 1.0 - Metadata

3.7.4 Valid Values for action Parameter on the Content-Type MIME header When WS-Addressing is Used

3.7.5 SOAP Defined Faults Action URI

3.7.6 Understanding WS-Addressing SOAP Header Blocks

3.7.7 Ignored or Absent WS-Addressing MAPs

3.7.8 Present and Understood WS-Addressing MAPs

3.7.9 SOAP MustUnderstand or VersionMismatch fault Transmission

3.7.10 Faulting Behavior with Present and Understood WS-Addressing MAPs

3.7.11 [message id] and One-Way Operations

3.7.12 Refusal to Honor WS-Addressing MAPs

3.7.13 Use of Non-Anonymous Response EPRs

3.7.14 Optionality of the wsa:To header

3.7.15 Extending WSDL Endpoints with an EPR

3.7.16 Combining Synchronous and Asynchronous Operations

3.7.17 Conflicting Addressing Policies

4. Service Description

4.1 Required Description

4.2 Document Structure

4.2.1 WSDL Schema Definitions

4.2.2 WSDL and Schema Import

4.2.3 WSDL Import location Attribute Structure

4.2.4 WSDL Import location Attribute Semantics

4.2.5 Placement of WSDL import Elements

4.2.6 XML Version Requirements

4.2.7 XML Namespace Declarations

4.2.8 WSDL and the Unicode BOM

4.2.9 Acceptable WSDL Character Encodings

4.2.10 Namespace Coercion

4.2.11 WSDL documentation Element

4.2.12 WSDL Extensions

4.3 Types

Test Assertion:	BP1143c
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a non anon response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - the wsa:To element, must be present and not anonymous - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence)
Target:	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/wsil:messageContents/soap12:Envelope [soap12:Body[not (soap12:Fault)] and soap12:Header [wsa:Action and (wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ) ] ] [ some $myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1] or $myenv/soap12:Header/wsa:Action )) ) ]
co-Target: myOpBinding	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation [ some $opBinding in . satisfies (if ($target/soap12:Body/[1] ) then (some $dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element), . ) = fn:node-name($target/soap12:Body/[1])] ] satisfies some $dopmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output [fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) = $dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true() ) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Response' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) ) else fn:true() ) ]
co-Target: related-Request	/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID = $target/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ]
Predicate:	( ($related-Request/soap12:Header/wsa:ReplyTo) and not ($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous' ) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or (@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and ( $target/soap12:Header[ (wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' )] )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a non anon response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element, must be present with a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence)
Diagnostic Data:	Complete message.

Test Assertion:	BP1144
Description:	The message must specify a SOAPAction HTTP header with either a value that is an absolute URI that has the same value as the value of the wsa:Action MAP, or a value of "" (empty string).
Target:	/wsil:testLog/wsil:messageLog/wsil:message[wsil:messageContents/soap12:Envelope/soap12:Header/wsa:Action]
Predicate:	(messageContents/soap12:Envelope/soap12:Header/wsa:Action/text() = wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@value) or not(wsil:httpHeaders/wsil:httpHeader[@key = 'action'])
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A message did not specify a SOAPAction HTTP header with either a value that is an absolute URI that has the same value as the value of the wsa:Action MAP, or a value of "" (empty string).
Diagnostic Data:	Complete message.

Test Assertion:	BP1035
Description:	The value of the wsa:Action element is http://www.w3.org/2005/08/addressing/soap/fault
Target:	/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Header/wsa:Action and (fn:ends-with(soap12:Body/soap12:Fault/soap12:Code/soap12:Value,'MustUnderstand') or fn:ends-with(soap12:Body/soap12:Fault/soap12:Code/soap12:Value, 'VersionMismatch'))]
Predicate:	normalize-space(string(./soap12:Header/wsa:Action)) eq 'http://www.w3.org/2005/08/addressing/soap/fault'
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A fault response does not contain the expected wsa:Action value of http://www.w3.org/2005/08/addressing/soap/fault.
Diagnostic Data:	Complete message.

Test Assertion:	BP1146
Description:	A non-faulting response must be sent to the [reply endpoint] MAP or generate a fault instead.
Target:	/wsil:testLog/wsil:messageLog/wsil:message [ (@type = 'response' and (some $resp in . satisfies some $req in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and @conversation = $resp/@conversation] satisfies $req//wsa:* ) ) or ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ] [wsil:messageContents/soap12:Envelope[not(soap12:Body/soap12:Fault)]]
co-Target: myRequestMsg	/wsil:testLog/wsil:messageLog/wsil:message [(@type = 'request' and @conversation = $target/@conversation) or (./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID = $target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ) ]
Predicate:	((not($myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo) or $myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo/wsa:Address = 'http://www.w3.org/2005/08/addressing/anonymous') and $target[@type = 'response']/wsil:messageContents/soap12:Envelope/soap12:Header [ wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' or not(wsa:To )]) or ( $target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:To = $myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo/wsa:Address )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A response message was sent to a destination other than the expected [reply endpoint] MAP, i.e. different from wsa:ReplyTo in the request message.
Diagnostic Data:	Complete message

Test Assertion:	BP1152a
Description:	The message must be sent in the entity body of an HTTP request in a separate HTTP connection specified by the response EPR using the SOAP 1.1 Request Optional Response HTTP binding.
Target:	/wsil:testLog/wsil:messageLog/wsil:message [wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and (some $req in /wsil:testLog/wsil:messageLog/wsil:message satisfies $req/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID = wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and $req/wsil:messageContents/soap12:Envelope/soap12:Header[wsa:ReplyTo[1]/wsa:Address ne 'http://www.w3.org/2005/08/addressing/anonymous'] )]
co-Target: myRequestMsg	/wsil:testLog/wsil:messageLog/wsil:message [wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID = $target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]]
Predicate:	($target/@type = 'request') and ( $target/wsil:messageContents/soap12:Envelope/soap12:Header [ (wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' ) ] )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A response message was not sent in the entity body of an HTTP request in a separate HTTP connection as required by the (non-anonymous) response EPR.
Diagnostic Data:	Complete message

Test Assertion:	BP1152b
Description:	The message must be sent in the entity body of an HTTP request in a separate HTTP connection specified by the response EPR using the SOAP 1.1 Request Optional Response HTTP binding.
Target:	/wsil:testLog/wsil:messageLog/wsil:message[wsil:messageContents/soap12:Envelope [(wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' ) ]]
Predicate:	$target/@type = 'request'
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A message with a non-anonymous destination was not sent in the entity body of an HTTP Request in a separate HTTP connection as required by the (non-anonymous) destination EPR.
Diagnostic Data:	Complete message

Test Assertion:	BP2703
Description:	The wsdl:definitions is a well-formed XML 1.0 document. The wsdl:definitions namespace has value: http://schemas.xmlsoap.org/wsdl/.
Target:	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[fn:prefix-from-QName(fn:node-name(*:definitions)) eq 'wsdl' or wsdl:definitions]
Predicate:	fn:namespace-uri-from-QName(fn:node-name(./:definitions)) eq 'http://schemas.xmlsoap.org/wsdl/' or ./:bindingTemplate
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The wsdl:definitions is not a well-formed XML 1.0 document, or WSDL definition does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd for some element using the WSDL-SOAP binding namespace, or does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd for some element using the WSDL namespace.
Diagnostic Data:	Error message from the XML parser

Test Assertion:	BP2705
Description:	The wsdl:definitions in namespace http://schemas.xmlsoap.org/wsdl/ is valid in accordance with the wsi version of the wsdl 1.1 schema at http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd .
Target:	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[wsdl:definitions]
co-Target: metadata	$target/@schemaValid
Predicate:	$target/@schemaValid = fn:true()
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The description file contains a WSDL definition which does not conform to the schema located at http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd
Diagnostic Data:	Error message from the XML parser

Test Assertion:	BP2704
Description:	The wsdl:definitions using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) MUST be valid according to the XML Schema found at " http://schemas.xmlsoap.org/wsdl/soap12/wsdl11soap12.xsd ".
Target:	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[.//wsoap12:*]
co-Target: metadata	$target/../@schemaValid
Predicate:	$target/../@schemaValid = fn:true()
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	The wsdl:definitions is using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) in a way that is not valid according to the XML Schema found at " http://schemas.xmlsoap.org/wsdl/soap12/wsdl11soap12.xsd ".
Diagnostic Data:	Error message from the XML parser

Test Assertion:	BP2101
Description:	Each wsdl:import statement is only used to import another WSDL description.
Target:	/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:import]
Predicate:	every $wsdlImp in $target/wsdl:import satisfies some $wsdlFile in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[@filename=$wsdlImp/@location] satisfies ( (fn:namespace-uri($wsdlFile/[1]) = 'http://schemas.xmlsoap.org/wsdl/' ) and ( fn:local-name($wsdlFile/[1]) = 'definitions' ) )
Reporting:	true=passed, false=failed
Prescription:	mandatory
Error Message:	A wsdl:import element does not contain a reference to another WSDL description.
Diagnostic Data:	wsdl:import element(s) that does not reference a WSDL description.