Basic Profile - Version 2.0 (WGD)

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

Status of this Document

This document is a Working Group Draft; it has been accepted by the Working Group as reflecting the current state of discussions. It is a work in progress, and should not be considered authoritative or final; other documents may supersede this document.

Note: The working group believes that the technical work related to the prose aspects of the profile is complete (barring any feedback). However, the technical work on the in-lined test assertions is still very much a work in progress.

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.

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.

1.3 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.4 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:

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:

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.

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

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.

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:

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:

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 soap:Envelope element and its content:

3.1.1 XML Envelope Serialization

R9701 An ENVELOPE MUST be serialized as XML 1.0. TESTABLE_NOT_XPATH BP1019

Test Assertion:	BP1019
Description:	The soap:envelope in the message is a well-formed XML 1.0 document.
Prerequisite:
Context:	//soap:Envelope
Match:	N/A
Error Message:	The soap:Envelope does not conform to XML 1.0.
Diagnostic:	{SOAP message}{any XML parser error messages}

3.1.2 Unicode BOMs

XML 1.0 allows UTF-8 encoding to include a BOM; therefore, receivers of envelopes must be prepared to accept them. The BOM is mandatory for XML encoded as UTF-16.

R4001 A RECEIVER MUST accept envelopes that include the Unicode Byte Order Mark (BOM). C NOT_TESTABLE BP3999

Test Assertion:	BP3999
Description:	Not testable.
Prerequisite:
Context:	not(1)
Match:	TBD
Error Message:
Diagnostic:

3.1.3 XML Declarations

Presence or absence of an XML declaration does not affect interoperability. Certain implementations might always precede their XML serialization with the XML declaration.

R1010 A RECEIVER MUST accept messages with envelopes that contain an XML Declaration. C NOT_TESTABLE BP3999

3.1.4 Character Encodings

The Profile requires XML processors to support the "UTF-8" and "UTF-16" character encodings, in order to aid interoperability.

To improve interoperabilitry, the "charset" parameter of Content-Type HTTP header field must be used to determine the correct character encoding of the message.

R1012 An ENVELOPE MUST be serialized using either UTF-8 or UTF-16 character encoding. TESTABLE BP1018

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.
Prerequisite:
Context:	//message[@type="request"]
Match:	httpHeaders/Content-Type/parameter[@key="charset]
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:	Complete message.

R1018 A SIMPLE_SOAP_MESSAGE MUST indicate the correct character encoding, using the "charset" parameter. C TESTABLE BP1018

R1019 A RECEIVER MUST ignore the encoding pseudo-attribute of the envelope's XML declaration. NOT_TESTABLE BP3999

3.1.5 XOP Encoded Messages

There is pervasive implementation that is apparently encoding the action parameter as a separate parameter of the enclosing MIME multipart/related entity body's Content-Type header. The multipart/related media type specification does not include an action parameter, though it does permit extensibility. Thus, the action parameter on the multipart/related Content-Type header has no defined semantic. The correct encoding is to include the action parameter inside the start-info parameter of the enclosing MIME multipart/related entity body as well as inside the type parameter of the root part.

R1020 A XOP_ENCODED_MESSAGE MUST include the start-info parameter in the Content-Type header of the enclosing multipart/related MIME entity body.

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

R1022 A RECEIVER MUST accept a XOP encoded message that has the action parameter, associated with the SOAP message, encoded inside the start-info parameter on the Content-Type header of the enclosing multipart/related MIME entity body.

R1023 A RECEIVER MAY accept a XOP encoded message that has the action parameter, associated with the SOAP message, encoded as a separate parameter on the Content-Type header of the enclosing multipart/related MIME entity body.

INCORRECT:

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
  type="application/xop+xml";
  start="<mymessage.xml@example.org>";
  start-info="application/soap+xml"; action="ProcessData"

--MIME_boundary
Content-Type: application/xop+xml;
  charset=UTF-8;
  type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

[...]

CORRECT:

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
  type="application/xop+xml";
  start="<mymessage.xml@example.org>";
  start-info="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml;
  charset=UTF-8;
  type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

[...]

3.2 SOAP Envelopes

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

SOAP 1.2 defines a structure for composing messages, the envelope. The Profile mandates the use of that structure, and places the following constraints on its use:

3.2.1 SOAP Envelope Structure

R9980 An ENVELOPE MUST conform to the structure specified in SOAP Version 1.2 Part 1, Section 5, "SOAP Envelope" (subject to amendment by the Profile). TESTABLE BP1600

Test Assertion:	BP1600
Description:	The envelope conforms to the structure specified in SOAP 1.2 Part 1, Section 5.
Prerequisite:
Context:	//soap:Envelope
Match:	TBD
Error Message:	The envelope does not conform to the structure specified in SOAP 1.2 Part 1, Section 5
Diagnostic:	SOAP envelope.

R9981 An ENVELOPE MUST have exactly zero or one child elements of the soap:Body element. TESTABLE BP9991

Test Assertion:	BP9991
Description:	The envelope must have exactly zero or one child elements of the soap:Body
Prerequisite:
Context:	//soap:Envelope
Match:	TBD
Error Message:	The envelope does not have exactly zero or one child elements of the soap:Body
Diagnostic:	SOAP envelope.

While the combination of R2201 and R2210 (below) clearly imply that there may be at most one child element of the soap:Body , there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion.

3.2.2 SOAP Body Namespace Qualification

The use of unqualified element names may cause naming conflicts, therefore qualified names must be used for the children of soap:Body .

R1014 The children of the soap:Body element in an ENVELOPE MUST be namespace qualified. TESTABLE BP1202

Test Assertion:	BP1202
Description:	Each child element (if any) of the soap:Body element is namespace qualified (not the grandchildren).
Prerequisite:	BP1701
Context:	For a candidate envelope containing a soap:body with at least one child element
Match:	TBD
Error Message:	A child element of the soap:Body element is not namespace qualified.
Diagnostic:	SOAP envelope.

3.2.3 Disallowed Constructs

XML DTDs and PIs may introduce security vulnerabilities, processing overhead and semantic ambiguity when used in envelopes. As a result, certain XML constructs are disallowed by section 5 of SOAP 1.2.

Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata ) allows the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace" to appear, some older processors considered such a declaration to be an error. These requirements ensure that conformant artifacts have the broadest interoperability possible.

R1008 An ENVELOPE MUST NOT contain a Document Type Declaration. C TESTABLE BP1007

Test Assertion:	BP1007
Description:	DTDs relating to soap:header or soap:body documents, are not present in the envelope: no DOCTYPE element is present.
Prerequisite:	BP1701
Context:	For a candidate envelope
Match:	TBD
Error Message:	The soap:header or soap:body elements in the envelope, were described with an included DTD.
Diagnostic:	SOAP envelope.

R1009 An ENVELOPE MUST NOT contain Processing Instructions. C TESTABLE BP1208

Test Assertion:	BP1208
Description:	The SOAP envelope does not include XML processing instructions.
Prerequisite:	BP1701
Context:	//soap:Envelope
Match:	not(descendant::processing-instruction()
Error Message:	a SOAP envelope contains XML processing instructions.
Diagnostic:	SOAP envelope.

R1033 An ENVELOPE SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". C TESTABLE BP1033

Test Assertion:	BP1033
Description:	The SOAP envelope does not contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Prerequisite:	BP1701
Context:	//soap:Envelope
Match:	not(descendant-or-self::*/namespace::node()[1] = 'xmlns:xml="http://www.w3.org/XML/1998/namespace"')
Error Message:	The SOAP envelope contains the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Diagnostic:	SOAP envelope

3.2.4 xsi:type Attributes

In many cases, senders and receivers will share some form of type information related to the envelopes being exchanged.

R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in envelopes except as required in order to indicate a derived type (see XML Schema Part 1: Structures, Section 2.6.1). NOT_TESTABLE BP3999

3.2.5 SOAP 1.2 attributes on SOAP 1.2 elements

R1032 The soap:Envelope , soap:Header , and soap:Body elements in an ENVELOPE MUST NOT have attributes in the namespace "http://www.w3.org/2003/05/soap-envelope" . TESTABLE BP1032

3.3 SOAP Processing Model

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

Test Assertion:	BP1032
Description:	The soap:Envelope, soap:Header, and soap:Body elements do not have any attributes in the namespace "http://schemas.xmlsoap.org/soap/envelope/"
Prerequisite:	BP1701
Context:	//soap:Envelope
Match:	TBD
Error Message:	A soap:Envelope, soap:Header, or soap:Body element has an attribute in the namespace "http://schemas.xmlsoap.org/soap/envelope/".
Diagnostic:	SOAP envelope

SOAP 1.2 defines a model for the processing of envelopes. In particular, it defines rules for the processing of header blocks and the envelope body. It also defines rules related to generation of faults. The Profile places the following constraints on the processing model:

3.3.1 SOAP Fault Processing

Note that there may be valid reasons (such as security considerations) why a fault might not be transmitted.

When a fault is generated, no further processing should be performed. In request-response exchanges, a fault message will be transmitted to the sender of the request, and some application level error will be flagged to the user.

Both SOAP and this Profile use the term 'generate' to denote the creation of a SOAP Fault. It is important to realize that generation of a Fault is distinct from its transmission, which in some cases is not required.

R1029 Where the normal outcome of processing a SOAP envelope would have resulted in the transmission of a SOAP response, but rather a fault is generated instead, a RECEIVER MUST transmit a fault in place of the response. NOT_TESTABLE feedme

R1030 A RECEIVER that generates a fault SHOULD notify the end user that a fault has been generated when practical, by whatever means is deemed appropriate to the circumstance. NOT_TESTABLE BP3999

Note that there may be valid reasons (such as security considerations) why a fault may not be transmitted.

3.4 SOAP Faults

3.4.1 Identifying SOAP Faults

Some consumer implementations erroneously use only the HTTP status code to determine the presence of a Fault. Because there are situations where the Web infrastructure changes the HTTP status code, and for general reliability, the Profile requires that they examine the envelope. A Fault is an envelope that has a single child element of the soap:Body element, that element being a soap:Fault element.

R1107 A RECEIVER MUST interpret a SOAP message as a Fault when the soap:Body of the message has a single soap:Fault child. TESTABLE BP3999

3.4.2 SOAP Defined Faults Action URI

WS-Addressing provides the URI http://www.w3.org/2005/08/addressing/soap/fault for "SOAP defined faults". However, it only recommends, rather than mandate its use for the SOAP 1.2 defined MustUnderstand and VersionMismatch faults. This Profile mandates the use of the WS-Addressing defined wsa:Action value for SOAP 1.2 defined MustUnderstand and VersionMismatch faults, for interoperability.

R1035 An ENVELOPE MUST use the http://www.w3.org/2005/08/addressing/soap/fault URI as the value for the wsa:Action element when present, for either of the SOAP 1.2 defined VersionMismatch and MustUnderstand faults. TESTABLE BP1035

Test Assertion:	BP1035
Description:	The value of the wsa:Action element is http://www.w3.org/2005/08/addressing/soap/fault
Prerequisite:
Context:	//soap:Envelope[ (soap:Body/soap:Fault/faultcode/namespace::*[ name(.) = substring-before(string(..), ':') ] = "http://schemas.xmlsoap.org/soap/envelope/")and (substring-after(soap:Body/soap:Fault/faultcode, ':') = 'MustUnderstand' or substring-after(soap:Body/soap:Fault/faultcode, ':') = 'VersionMismatch') ]
Match:	count(./soap:Header/wsa:Action) = 0 or normalize-space(string(./soap:Header/wsa:Action)) = 'http://www.w3.org/2005/08/addressing/soap/fault'
Error Message:	A fault response does not contain the expected wsa:Action value of http://www.w3.org/2005/08/addressing/soap/fault.
Diagnostic:	Complete message.

3.4.3 SOAP MustUnderstand or VersionMismatch fault Transmission

WS-Addressing does not violate the SOAP processing model, but in fact plays within the rules defined by the SOAP processing model. Thus, regardless of the value of the wsa:ReplyTo or wsa:FaultTo, should a message generate either a SOAP MustUnderstand or VersionMismatch fault, that fault SHOULD be transmitted to the sender of the message generating such fault on the HTTP response message.

Note that this is a SHOULD requirement, as there may be valid reasons why the fault is not transmitted at all.

R1036 A RECEIVER that receives a SOAP envelope that generates either a SOAP MustUnderstand or VersionMismatch fault SHOULD transmit such a fault on the HTTP response message, regardless of the value of the wsa:ReplyTo or wsa:FaultTo SOAP headers present in the message. TESTABLE BP3999

3.5 Treatment of URIs in SOAP

3.5.1 Comparison of URI values of SOAP Information Items

R1037 A RECEIVER, for the purposes of comparison of URI values of information items defined by the SOAP 1.2 specification, MUST treat the computed absolute URI values as strings (see RFC3986). TESTABLE feedme

3.6 Support for WS-Addressing

WS-Addressing is a part of core Web services infrastructure. To facilitate interoperability and to provide a common baseline, this profile requires compliant clients and services to provide support for WS-Addressing Core, WS-Addressing SOAP Binding and WS-Addressing Metadata.

Support for WS-Addressing by a specific "service" is optional. However, a service may require the use of WS-Addressing, in which case, for successful interaction with that service, a client will need to support it.

3.6.1 Requiring WS-Addressing SOAP headers

R1040 If an endpoint requires use of WS-Addressing by use of a wsam:Addressing policy assertion, an ENVELOPE sent by a SENDER MUST carry all required WS-Addressing SOAP headers. TESTABLE feedme

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

R1041 An ENVELOPE that is a MustUnderstand SOAP fault, sent from an endpoint that has a policy alternative containing the wsam:Addressing assertion attached to its WSDL endpoint subject, MUST NOT contain a NotUnderstood SOAP header block with the qname attribute value that identifies a WS-Addressing defined SOAP header block. TESTABLE feedme

3.7 Use of WS-Addressing MAPs

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

When using WS-Addressing, the Profile requires conformance to WS-Addressing 1.0 - Core, WS-Addressing 1.0 - SOAP Binding and WS-Addressing 1.0 Metadata, Section 5.1 and places the following additional constraints.

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

WS-Addressing 1.0 - Metadata, Section 5.1 defines additional constraints on the cardinality of WS-Adressing Message Addressing Properties defined in WS-Addressing 1.0 - Core. These constraints are defined for every message involved in WSDL 1.1 transmission primitives. The Profile requires conformance to this section when WS-Addressing is used in conjunction with WSDL 1.1 description.

R1142 An ENVELOPE that includes a wsa:Action SOAP header block and which is described using WSDL 1.1 description MUST conform to WS-Addressing 1.0 - Metadata, Section 5.1. C TESTABLE BP1142

Test Assertion:	BP1142
Description:	The envelope must conform to WS-Addressing WSDL Binding, Section 5.1.
Prerequisite:
Context:	//message[@type="one-way"]/messageLog/soap:Envelope/soap:Header[wsa:Action]
Match:	wsa:To or not(//wsdl:definitions/descendant::*[@wsa:UsingAddressing])
Error Message:	An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1.
Diagnostic:	Complete message.

3.7.2 Understanding WS-Addressing SOAP Header Blocks

WS-Addressing 1.0 -- SOAP Binding defines multiple SOAP header blocks (wsa:To, wsa:From, wsa:ReplyTo, wsa:FaultTo, wsa:Action, wsa:MessageID, and wsa:RelatesTo). These SOAP header blocks are part of the same module. A SOAP node that conforms to the Profile understands all of these SOAP header blocks (when it understands WS-Addressing) or none at all (when it does not understand WS-Addressing).

R1143 When a message contains multiple WS-Addressing SOAP header blocks with at least one of those header blocks containing a soap:mustUnderstand='1' attribute, then a RECEIVER MUST understand all the WS-Addressing SOAP header blocks or none of them. C Compat NOT_TESTABLE BP3999

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

There may be some confusion as regards to the range of valid values for the action parameter on the Content-Type MIME header when WS-Addressing is used.

When composed with WS-Addressing, the value of the action parameter, if present, is limited to the absolute URI that matches the value specified for wsa:Action . The action parameter is optional and is therefore not required to be present on the header. This is useful, for example, when the value of wsa:Action is sensitive and is therefore encrypted.

R1144 When wsa:Action MAP is present in an envelope, the value of the action parameter, if present, on the Content-Type MIME header of the MESSAGE MUST be an absolute URI that has the same value as the value of the wsa:Action MAP. TESTABLE BP1144

3.8 Use of SOAP in HTTP

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

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).
Prerequisite:
Context:	//message[messageLog/soap:Envelope/soap:Header/wsa:Action]
Match:	(messageLog/soap:Envelope/soap:Header/wsa:Action/text() = httpHeaders/Content-Type/parameter[@key="action"]/text()) or not(httpHeaders/Content-Type/parameter[@key="action"])
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:	Complete message.

SOAP 1.2 defines a single protocol binding, for HTTP. The Profile mandates the use of that binding, and places the following constraints on its use:

3.8.1 HTTP Protocol Binding

Several versions of HTTP are defined. HTTP/1.1 has performance advantages, and is more clearly specified than HTTP/1.0.

R1141 A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0. TESTABLE BP1002

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>
Prerequisite:
Context:	For a candidate message in the log file, that is either a POST HTTP request, or a response to a POST HTTP request
Match:	TBD
Error Message:	The message is not sent using HTTP/1.1 or HTTP/1.0.
Diagnostic:	All HTTP headers.

R1140 A MESSAGE SHOULD be sent using HTTP/1.1. TESTABLE feedme

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>
Prerequisite:	BP1002
Context:	For a candidate message in the log file, that is either a POST HTTP request, or a response to a POST HTTP request
Match:	TBD
Error Message:	The message is not sent using HTTP/1.1.
Diagnostic:	All HTTP headers.

Note that support for HTTP/1.0 is implied in HTTP/1.1, and that intermediaries may change the version of a message; for more information about HTTP versioning, see RFC2145, "Use and Interpretation of HTTP Version Numbers."

3.8.2 Parameters on the Content-Type MIME Header

Testing has demonstrated that requiring parameters on the Content-Type MIME header field-value to be quoted increases interoperability of implementations. Even though HTTP allows unquoted header field-values, some SOAP implementations require that they be quoted.

R1109 Parameters on the Content-Type MIME header field-value in a request MESSAGE MUST be a quoted string. C TESTABLE BP1006

Test Assertion:	BP1006
Description:	The SOAPAction header contains a quoted string of any value, including "".
Prerequisite:
Context:	For a candidate request message in the message log file, when a SOAPAction header is present
Match:	TBD
Error Message:	SOAPAction HTTP header does not contain a quoted string.
Diagnostic:	All HTTP headers.

R1119 A RECEIVER MAY respond with a fault if the parameters on the Content-Type MIME header field-value in a message is not quoted. C NOT_TESTABLE BP1999

Test Assertion:	BP1999
Description:	Not testable.
Prerequisite:
Context:	not(1)
Match:	TBD
Error Message:
Diagnostic:

R1127 A RECEIVER MUST NOT rely on the value of the action parameter on the Content-Type MIME header field-value to correctly process the message. NOT_TESTABLE BP1999

CORRECT:

A WSDL Description that has:

<wsoap12:operation soapAction="http://example.org/foo"/>

results in a message with an action parameter on the Content-Type MIME header field-value set to:

"http://example.org/foo"

CORRECT:

A WSDL Description that has:

<wsoap12:operation />

<wsoap12:operation soapAction="" />

must not results in a message with an action parameter on the Content-Type MIME header field-value.

3.8.3 HTTP Success Status Codes

HTTP uses the 2xx series of status codes to communicate success. In particular, 200 is the default for successful messages, but 202 can be used to indicate that a message has been submitted for processing. Additionally, other 2xx status codes may be appropriate, depending on the nature of the HTTP interaction.

R1124 An INSTANCE MUST use a 2xx HTTP status code on a response message that indicates the successful outcome of a HTTP request. NOT_TESTABLE BP1999

Test Assertion:	BP1100
Description:	The message uses a "200 OK" HTTP status code.
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope in a response message
Match:	TBD
Error Message:	The envelope of the response message does not contain a soap:Fault and the message does not use a "200 OK" HTTP status code.
Diagnostic:	Complete message.

R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code on a response message that contains an envelope that is not a fault. TESTABLE BP1100

Test Assertion:	BP1100
Description:	The message uses a "200 OK" HTTP status code.
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope in a response message
Match:	TBD
Error Message:	The envelope of the response message does not contain a soap:Fault and the message does not use a "200 OK" HTTP status code.
Diagnostic:	Complete message.

R1112 An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response message that does not contain a SOAP envelope but indicates the successful outcome of a HTTP request. TESTABLE BP1101

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.
Prerequisite:
Context:	For a candidate response message in the log file, that does not contain a SOAP message and that does not contain an HTTP 4xx status code
Match:	TBD
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:	Complete message.

Despite the fact that the HTTP 1.1 assigns different meanings to response status codes "200" and "202", in the context of the Profile they should be considered equivalent by the initiator of the request. The Profile accepts both status codes because some SOAP implementations have little control over the HTTP protocol implementation and cannot control which of these response status codes is sent.

3.8.4 HTTP Redirect Status Codes

There are interoperability problems with using many of the HTTP redirect status codes, generally surrounding whether to use the original method, or GET. The Profile mandates "307 Temporary Redirect", which has the semantic of redirection with the same HTTP method, as the correct status code for redirection. For more information, see the 3xx status code descriptions in RFC2616.

R1130 An INSTANCE MUST use the "307 Temporary Redirect" HTTP status code when redirecting a request to a different endpoint. NOT_TESTABLE BP1999

R1131 A CONSUMER MAY automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response. NOT_TESTABLE BP1999

RFC2616 notes that user-agents should not automatically redirect requests; however, this requirement was aimed at browsers, not automated processes (which many Web services will be). Therefore, the Profile allows, but does not require, consumers to automatically follow redirections.

3.8.5 HTTP Cookies

The HTTP State Management Mechanism ("Cookies") allows the creation of stateful sessions between Web browsers and servers. Being designed for hypertext browsing, Cookies do not have well-defined semantics for Web services, and, because they are external to the envelope, are not accommodated by either SOAP 1.2 or WSDL 1.1. However, there are situations where it may be necessary to use Cookies; e.g., for load balancing between servers, or for integration with legacy systems that use Cookies. For these reasons, the Profile limits the ways in which Cookies can be used, without completely disallowing them.

R1120 An INSTANCE MAY use the HTTP state mechanism ("Cookies"). NOT_TESTABLE BP1999

R1122 An INSTANCE using Cookies SHOULD conform to RFC2965. NOT_TESTABLE BP1999

R1121 An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly. NOT_TESTABLE BP1999

R1123 The value of the cookie MUST be considered to be opaque by the CONSUMER. NOT_TESTABLE BP1999

The Profile recommends that cookies not be required by instances for proper operation; they should be a hint, to be used for optimization, without materially affecting the execution of the Web service. However, they may be required in legacy integration and other exceptional use cases, so requiring them does not make an instance non-conformant. While Cookies thus may have meaning to the instance, they should not be used as an out-of-bound data channel between the instance and the consumer. Therefore, interpretation of Cookies is not allowed at all by the consumer - it is required to treat them as opaque (i.e., have no meaning to the consumer).

3.8.6 Use of Non-Anonymous Reponse EPR in a Request-Response Operation

WS-Addressing response EPR ( wsa:FaultTo and wsa:ReplyTo ) values affect how and where the response message is sent in a Request-Response WSDL transmission primitive. Specifically:

when the response EPR has an anonymous value for the wsa:Address property, the response is sent in the entity body of the HTTP response message.
when the response EPR has a non-anonymous value for the wsa:Address property:
1. MustUnderstand and VersionMismatch faults "when sent", are included in the entity body of the HTTP response message, as specified in SOAP 1.2 part2 section 7.5.2, HTTP binding .
2. All other response messages are sent in a separate HTTP connection to the destination specified by the appropriate ( wsa:FaultTo for faults and wsa:ReplyTo for non-fault messages) response EPR. Both the HTTP connections, for the request message and response message as described by the WSDL Request-Response operation, use the SOAP 1.2 Request-Response MEP and the SOAP HTTP binding. SOAP 1.2 Request-Response MEP does not require that the SOAP MEP Response be a SOAP envelope, it can be a binding-specific message. Such an optional response is indicated in the SOAP HTTP binding using the HTTP status 202. The HTTP response in this case may or may not contain a SOAP envelope. If an envelope is present in the HTTP response with a status code of 202, it is not considered to be the WSDL-level response. The request message and the response message, as described by the WSDL Request-Response operation, are sent in the entity-body of the HTTP request in two separate connections.

R1150 If an INSTANCE sends a MustUnderstand or VersionMismatch fault generated as a result of an invocation of a Request-Response WSDL operation, it MUST send that fault in the entity body of HTTP response using the same HTTP connection as the request message of that operation. TESTABLE BP1150

Test Assertion:	BP1150
Description:	The message must be a response sent in the entity body of the HTTP response using the same HTTP connection as the request message of that operation.
Prerequisite:
Context:	For a candidate message whose envelope contains a soap:Fault element that contains a faultcode element equal to either VersionMismatch or MustUnderstand, and that was generated as a result of an invocation of a Request-Response WSDL operation.
Match:	TBD
Error Message:	A response message was not sent in the entity body of the HTTP response using the same HTTP connection as the request message of that operation.
Diagnostic:	Complete message

R1151 If an INSTANCE sends a response which is neither a MustUnderstand nor VersionMismatch fault as a result of an invocation of a Request-Response WSDL operation and the response EPR has a non-anonymous wsa:Address value, then the response 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.2 HTTP binding. TESTABLE BP1151

3.9 Use of URIs in SOAP

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

Test Assertion:	BP1151
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.
Prerequisite:
Context:	For a candidate message that is neither a MustUnderstand nor VersionMismatch fault, that is sent as the result of a Request-Response WSDL opertaion, and that contains a response EPR with a non-anonymous wsa:Address value.
Match:	TBD
Error Message:	A message was not 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.
Diagnostic:	Complete message

SOAP 1.2 uses URIs as identifiers. For example, the role attribute value is a URI that identify the SOAP node to which a particular header block is targeted. The Profile places the following constraints on the use of such URI values:

3.9.1 Use of SOAP-defined URIs

A SOAP 1.2 defined URI, such as the role value "http://www.w3.org/2003/05/soap-envelope/role/next", in SOAP 1.2, is a simple formatted string.

R1160 A RECEIVER, for the purposes of comparison of URI values of information items defined by the SOAP 1.2 specification, MUST treat the computed absolute URI values as strings (see RFC3986). NOT_TESTABLE BP1999

4. Service Description

The Profile uses Web Services Description Language (WSDL) to enable the description of services as sets of endpoints operating on messages.

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

4.1 Required Description

An instance of a Web service is required to make the contract that it operates under available in some fashion.

R0001 Either an INSTANCE's WSDL 1.1 description, its UDDI binding template, or both MUST be available to an authorized consumer upon request. TESTABLE_NOT_XPATH BP2703

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/.
Prerequisite:
Context:	//wsdl:definitions
Match:	. instance of schema-element(wsdl:definitions)
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:	Error message from the XML parser

This means that if an authorized consumer requests a service description of a conformant service instance, then the service instance provider must make the WSDL document, the UDDI binding template, or both available to that consumer. A service instance may provide run-time access to WSDL documents from a server, but is not required to do so in order to be considered conformant. Similarly, a service instance provider may register the instance provider in a UDDI registry, but is not required to do so to be considered conformant. In all of these scenarios, the WSDL contract must exist, but might be made available through a variety of mechanisms, depending on the circumstances.

4.2 Document Structure

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

WSDL 1.1 defines an XML-based structure for describing Web services. The Profile mandates the use of that structure, and places the following constraints on its use:

4.2.1 WSDL Schema Definitions

The normative schemas for WSDL appearing in Appendix 4 of the WSDL 1.1 specification have inconsistencies with the normative text of the specification. The Profile references new schema documents that have incorporated fixes for known errors.

R2028 A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at " http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd ". TESTABLE BP2703

Test Assertion:	BP2704
Description:	The wsdl:definitions is a well-formed XML 1.0 document. The wsdl:definitions namespace has value: http://schemas.xmlsoap.org/wsdl/.
Prerequisite:
Context:	//wsdl:definitions/descendant::*[namespace='http://schemas.xmlsoap.org/wsdl/soap/']
Match:	every $soap-binding in //[namespace='http://schemas.xmlsoap.org/wsdl/soap12/' and parent::[namespace='http://schemas.xmlsoap.org/wsdl/']] satisfies $soap-binding instance of schema-element(wsoap12:operation) or $soap-binding instance of schema-element(wsoap12:binding) or $soap-binding instance of schema-element(wsoap12:body) or $soap-binding instance of schema-element(wsoap12:fault) or $soap-binding instance of schema-element(wsoap12:header) or $soap-binding instance of schema-element(wsoap12:address)
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:	Error message from the XML parser

R2029 A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) MUST be valid according to the XML Schema found at " http://ws-i.org/profiles/basic/1.1/wsdlsoap-2004-08-24.xsd ". TESTABLE BP2704

Test Assertion:	BP2704
Description:	The wsdl:definitions is a well-formed XML 1.0 document. The wsdl:definitions namespace has value: http://schemas.xmlsoap.org/wsdl/.
Prerequisite:
Context:	//wsdl:definitions/descendant::*[namespace='http://schemas.xmlsoap.org/wsdl/soap/']
Match:	every $soap-binding in //[namespace='http://schemas.xmlsoap.org/wsdl/soap12/' and parent::[namespace='http://schemas.xmlsoap.org/wsdl/']] satisfies $soap-binding instance of schema-element(wsoap12:operation) or $soap-binding instance of schema-element(wsoap12:binding) or $soap-binding instance of schema-element(wsoap12:body) or $soap-binding instance of schema-element(wsoap12:fault) or $soap-binding instance of schema-element(wsoap12:header) or $soap-binding instance of schema-element(wsoap12:address)
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:	Error message from the XML parser

Although the Profile requires WSDL descriptions to be Schema valid, it does not require consumers to validate WSDL documents. It is the responsibility of a WSDL document's author to assure that it is Schema valid.

4.2.2 WSDL and Schema Import

Some examples in WSDL 1.1 incorrectly show the WSDL import statement being used to import XML Schema definitions. The Profile clarifies use of the import mechanisms to keep them consistent and confined to their respective domains. Imported schema documents are also constrained by XML version and encoding requirements consistent to those of the importing WSDL documents.

R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description. TESTABLE BP2101

Test Assertion:	BP2101
Description:	Each wsdl:import statement is only used to import another WSDL description.
Prerequisite:	BP2703
Context:	//wsdl:definitions/wsdl:import
Match:	fn:doc(@location) instance of schema-element(wsdl:definitions)
Error Message:	A wsdl:import element does not contain a reference to another WSDL description.
Diagnostic:	wsdl:import element(s) that does not reference a WSDL description.

R2803 In a DESCRIPTION, the namespace attribute of the wsdl:import MUST NOT be a relative URI. TESTABLE BP2803

Test Assertion:	BP2803
Description:	The "namespace" attribute's value is not a relative URI.
Prerequisite:	BP2703
Context:	//wsdl:definitions/wsdl:import
Match:	starts-with(@location, 'http://') or starts-with(@location, 'HTTP://') or starts-with(@location, 'urn:') or starts-with(@location, 'URN:') or starts-with(@location, 'ftp:') or starts-with(@location, 'FTP:')
Error Message:	The wsdl:import element's "namespace" attribute value is a relative URI.
Diagnostic:	Defective wsdl:import element.

R2002 To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement. TESTABLE BP2102

Test Assertion:	BP2102
Description:	Each XML schema import statement (xsd:import) is only used to directly reference an XML schema definition, which has "schema" from XML namespace "http://www.w3.org/2001/XMLSchema" as root element. It does not contain a reference to another document embedding the XML schema definition (e.g. WSDL).
Prerequisite:
Context:	//wsdl:definitions/wsdl:types/xsd:schema/xsd:import
Match:	fn:doc(@schemaLocation) instance of schema-element(xsd:schema)
Error Message:	An XML schema import element references something other than an XML schema definition: the referenced element does not have "schema" from XML namespace "http://www.w3.org/2001/XMLSchema" as root element.
Diagnostic:	Defective XML schema import element.

R2003 A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section. TESTABLE BP2103

Test Assertion:	BP2103
Description:	For the referenced definitions as well as all imported descriptions, The XML schema import statement is only used within an xsd:schema element.
Prerequisite:
Context:	//wsdl:definitions/descendant::xsd:import
Match:	parent::xsd:schema[parent::wsdl:types and ancestor::wsdl:types]
Error Message:	A XML schema import element was found outside of an xsd:schema element.
Diagnostic:	Defective XML schema import element.

R2004 In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema". TESTABLE BP2102

Test Assertion:	BP2999
Description:	Not testable.
Prerequisite:
Context:	not(1)
Match:	TBD
Error Message:
Diagnostic:

R2009 An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode Byte Order Mark (BOM). NOT_TESTABLE BP2999

Test Assertion:	BP2999
Description:	Not testable.
Prerequisite:
Context:	not(1)
Match:	TBD
Error Message:
Diagnostic:

R2010 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8 or UTF-16 encoding. TESTABLE_NOT_XPATH BP2202

Test Assertion:	BP2202
Description:	The imported schema uses UTF-8 or UTF-16 for the encoding.
Prerequisite:
Context:	For a candidate wsdl:types element within a WSDL document which imports an XML schema directly or indirectly.
Match:	TBD
Error Message:	The XML declaration statement within the imported XML Schema does not use expected encoding (UTF-8 or UTF-16).
Diagnostic:	XML declaration statement.

R2011 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation. TESTABLE BP2011

Test Assertion:	BP2011
Description:	The imported XML schema is a well-formed XML 1.0 document and if it contains an XML declaration, it is version 1.0.
Prerequisite:	BP2102
Context:	For a candidate wsdl:types element within a WSDL document, which imports an XML schema directly or indirectly
Match:	TBD
Error Message:	The imported XML schema is not a well-formed XML 1.0 document.
Diagnostic:	{Error message from the XML parser}{imported XML schema}

INCORRECT:

            <definitions name="StockQuote"
            targetNamespace="http://example.com/stockquote/definitions"
            xmlns:xsd1="http://example.com/stockquote/schemas" ...
            xmlns="http://schemas.xmlsoap.org/wsdl/"> <import
            namespace="http://example.com/stockquote/schemas"
            location="http://example.com/stockquote/stockquote.xsd"/>
            <message name="GetLastTradePriceInput"> <part
            name="body" element="xsd1:TradePriceRequest"/>
            </message> ... </definitions>

CORRECT:

            <definitions name="StockQuote"
            targetNamespace="http://example.com/stockquote/definitions"
            ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <import
            namespace="http://example.com/stockquote/definitions"
            location="http://example.com/stockquote/stockquote.wsdl"/>
            <message name="GetLastTradePriceInput"> <part
            name="body" element="..."/> </message> ...
            </definitions>

CORRECT:

            <definitions name="StockQuote"
            targetNamespace="http://example.com/stockquote/"
            xmlns:xsd1="http://example.com/stockquote/schemas" ...
            xmlns="http://schemas.xmlsoap.org/wsdl/"> <import
            namespace="http://example.com/stockquote/definitions"
            location="http://example.com/stockquote/stockquote.wsdl"/>
            <message name="GetLastTradePriceInput"> <part
            name="body" element="xsd1:TradePriceRequest"/>
            </message> ... </definitions>

4.2.3 WSDL Import location Attribute Structure

WSDL 1.1 is not clear about whether the location attribute of the wsdl:import statement is required, or what its content is required to be.

R2007 A DESCRIPTION MUST specify a non-empty location attribute on the wsdl:import element. TESTABLE BP2098

Test Assertion:	BP2098
Description:	The "location" attribute is specified for the wsdl:import element, and has a non-empty value.
Prerequisite:
Context:	//wsdl:definitions[wsdl:import]
Match:	wsdl:import[@location[not(text() = '')]]
Error Message:	A wsdl:import element does not have a "location" attribute, or has an empty value for the location attribute.
Diagnostic:	Defective wsdl:import element.

Although the wsdl:import statement is modeled after the xsd:import statement, the location attribute is required by wsdl:import while the corresponding attribute on xsd:import , schemaLocation is optional. Consistent with location being required, its content is not intended to be empty.

4.2.4 WSDL Import location Attribute Semantics

WSDL 1.1 is unclear about whether WSDL processors must actually retrieve and process the WSDL document from the URI specified in the location attribute on the wsdl:import statements it encounters.

R2008 A CONSUMER MAY, but need not, retrieve a WSDL description from the URI specified in the location attribute on a wsdl:import element. C NOT_TESTABLE BP2999

The value of the location attribute of a wsdl:import element is a hint. A WSDL processor may have other ways of locating a WSDL description for a given namespace.

4.2.5 Placement of WSDL import Elements

Example 3 in WSDL 1.1 Section 3.1 causes confusion regarding the placement of wsdl:import .

R2022 When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements from the WSDL namespace except wsdl:documentation . TESTABLE BP2105

Test Assertion:	BP2105
Description:	wsdl:import elements occur either as first children elements in the WSDL namespace of the wsdl:defintitions element, or they are only preceded by wsdl:documentation elements.
Prerequisite:
Context:	//wsdl:definitions[wsdl:import/preceding-sibling::wsdl:*]
Match:	not(wsdl:import/preceding-sibling::wsdl:*[not(local-name(.) = 'documentation' or local-name(.) = 'import')])
Error Message:	A wsdl:import element in the WSDL namespace under the wsdl:definitions element, is preceded by child elements other than wsdl:documentation elements.
Diagnostic:	Display the WSDL import element(s) that failed the assertion.

R2023 When they appear in a DESCRIPTION, wsdl:types elements MUST precede all other elements from the WSDL namespace except wsdl:documentation and wsdl:import . TESTABLE BP2018

Test Assertion:	BP2018
Description:	The wsdl:types elements occur either as first children in the WSDL namespace of the wsdl:definitions element, or they are only preceded by wsdl:documentation element(s) and/or wsdl:import(s) element(s).
Prerequisite:	BP2703
Context:	//wsdl:definitions[wsdl:types/preceding-sibling::wsdl:*]
Match:	not(wsdl:types/preceding-sibling::wsdl:*[not(local-name(.) = 'documentation' or local-name(.) = 'import' or local-name(.) = 'types')])
Error Message:	wsdl:types element(s) in the WSDL namespace of the wsdl:definitions element were preceded by child elements other than wsdl:documentation or wsdl:import elements.
Diagnostic:

INCORRECT:

            <definitions name="StockQuote" ...
            xmlns="http://schemas.xmlsoap.org/wsdl/"> <import
            namespace="http://example.com/stockquote/definitions"
            location="http://example.com/stockquote/stockquote.wsdl"/>
            <message name="GetLastTradePriceInput"> <part
            name="body" type="tns:TradePriceRequest"/>
            </message> ... <service
            name="StockQuoteService"> <port name="StockQuotePort"
            binding="tns:StockQuoteSoap"> .... </port>
            </service> <types> <schema
            targetNamespace="http://example.com/stockquote/schemas"
            xmlns="http://www.w3.org/2001/XMLSchema"> .......
            </schema> </types> </definitions>

CORRECT:

            <definitions name="StockQuote"
            targetNamespace="http://example.com/stockquote/definitions">
            <import namespace="http://example.com/stockquote/base"
            location="http://example.com/stockquote/stockquote.wsdl"/>
            <message name="GetLastTradePriceInput"> <part
            name="body" element="..."/> </message> ...
            </definitions>

CORRECT:

            <definitions name="StockQuote" ...
            xmlns="http://schemas.xmlsoap.org/wsdl/"> <types>
            <schema
            targetNamespace="http://example.com/stockquote/schemas"
            xmlns="http://www.w3.org/2001/XMLSchema"> .......
            </schema> </types> <message
            name="GetLastTradePriceInput"> <part name="body"
            element="tns:TradePriceRequest"/> </message> ...
            <service name="StockQuoteService"> <port
            name="StockQuotePort" binding="tns:StockQuoteSoap"> ....
            </port> </service> </definitions>

4.2.6 XML Version Requirements

Neither WSDL 1.1 nor XML Schema 1.0 mandate a particular version of XML. For interoperability, WSDL documents and the schemas they import expressed in XML must use version 1.0.

R4004 A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation. TESTABLE_NOT_XPATH BP2700

Test Assertion:	BP2700
Description:	The wsdl:definitions is a well-formed XML 1.0 document.
Prerequisite:
Context:	For a candidate wsdl:definitions element within a WSDL document.
Match:	TBD
Error Message:	The wsdl:definitions is not a well-formed XML 1.0 document.
Diagnostic:	Error message from the XML parser

4.2.7 XML Namespace Declarations

Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata) allows this namespace declaration to appear, some older processors considered such a declaration to be an error. This requirement ensures that conformant artifacts have the broadest interoperability possible.

R4005 A DESCRIPTION SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". C TESTABLE BP2034

Test Assertion:	BP2034
Description:	The candidate description does not contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Prerequisite:	BP2703
Context:	//wsdl:definitions
Match:	not(descendant-or-self::*/namespace::node()[1] = 'xmlns:xml="http://www.w3.org/XML/1998/namespace"')
Error Message:	The candidate description contains the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Diagnostic:

4.2.8 WSDL and the Unicode BOM

XML 1.0 allows documents that use the UTF-8 character encoding to include a BOM; therefore, description processors must be prepared to accept them.

R4002 A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM). C NOT_TESTABLE BP2999

4.2.9 Acceptable WSDL Character Encodings

The Profile consistently requires either UTF-8 or UTF-16 encoding for both SOAP and WSDL.

R4003 A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding. TESTABLE_NOT_XPATH BP2201

Test Assertion:	BP2201
Description:	The XML declaration statement uses UTF-8 or UTF-16 for the encoding.
Prerequisite:
Context:	For a candidate Web service definition within a WSDL document with a XML declaration statement.
Match:	TBD
Error Message:	XML declaration statement within WSDL document does not use expected encoding (UTF-8 or UTF-16).
Diagnostic:	XML declaration statement.

4.2.10 Namespace Coercion

Namespace coercion on wsdl:import is disallowed by the Profile.

R2005 The targetNamespace attribute on the wsdl:definitions element of a description that is being imported MUST have same the value as the namespace attribute on the wsdl:import element in the importing DESCRIPTION. TESTABLE BP2104

Test Assertion:	BP2104
Description:	The targetNamespace attribute on the wsdl:definitions element for the imported WSDL description has the same value as the namespace attribute on the wsdl:import element that imported the WSDL description.
Prerequisite:	BP2101
Context:	//wsdl:definitions/wsdl:import
Match:	fn:doc(@location)/@targetNamespace = @targetNamespace
Error Message:	The targetNamespace attribute on the wsdl:definitions element for an imported WSDL description does not have the same value as the namespace attribute on the wsdl:import element that imported the WSDL description.
Diagnostic:	wsdl:import element.

4.2.11 WSDL documentation Element

The WSDL 1.1 schema and the WSDL 1.1 specification are inconsistent with respect to where wsdl:documentation elements may be placed.

R2030 In a DESCRIPTION the wsdl:documentation element MAY be present as the first child element of wsdl:import , wsdl:part and wsdl:definitions in addition to the elements cited in the WSDL 1.1 specification. WSDL20 NOT_TESTABLE BP2999

4.2.12 WSDL Extensions

Requiring support for WSDL extensions that are not explicitly specified by this or another WS-I Profile can lead to interoperability problems with development tools that have not been instrumented to understand those extensions.

R2025 A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile. NOT_TESTABLE BP2999

Test Assertion:	BP2123
Description:	Contained WSDL extension elements do not use the wsdl:required attribute value of "true".
Prerequisite:
Context:	//wsdl:definitions/descendant::*[namespace-uri(.) != 'http://schemas.xmlsoap.org/wsdl/' and (./ancestor::wsdlortType or ./ancestor::wsdl:binding or ./ancestor::wsdl:message or ./ancestor::wsdl:types or ./ancestor::wsdl:import)]
Match:	not(@wsdl:required = 'true')
Error Message:	An extension element within a WSDL element that claims conformance to the Basic Profile has a wsdl:required attribute with a value of "true".
Diagnostic:	Display the extension element that failed the assertion.

R2026 A DESCRIPTION SHOULD NOT include extension elements with a wsdl:required attribute value of "true" on any WSDL construct ( wsdl:binding , wsdl:portType , wsdl:message , wsdl:types or wsdl:import ) that claims conformance to the Profile. TESTABLE BP2123

Test Assertion:	BP2123
Description:	Contained WSDL extension elements do not use the wsdl:required attribute value of "true".
Prerequisite:
Context:	//wsdl:definitions/descendant::*[namespace-uri(.) != 'http://schemas.xmlsoap.org/wsdl/' and (./ancestor::wsdlortType or ./ancestor::wsdl:binding or ./ancestor::wsdl:message or ./ancestor::wsdl:types or ./ancestor::wsdl:import)]
Match:	not(@wsdl:required = 'true')
Error Message:	An extension element within a WSDL element that claims conformance to the Basic Profile has a wsdl:required attribute with a value of "true".
Diagnostic:	Display the extension element that failed the assertion.

R2027 If during the processing of a description, a consumer encounters a WSDL extension element that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing. NOT_TESTABLE BP2999

Development tools that consume a WSDL description and generate software for a Web service instance might not have built-in understanding of an unknown WSDL extension. Hence, use of required WSDL extensions should be avoided. Use of a required WSDL extension that does not have an available specification for its use and semantics imposes potentially insurmountable interoperability concerns for all but the author of the extension. Use of a required WSDL extension that has an available specification for its use and semantics reduces, but does not eliminate the interoperability concerns that lead to this refinement.

For the purposes of the Profile, all elements in the "http://schemas.xmlsoap.org/wsdl/" namespace are extensible via element as well as attributes. As a convenience, WS-I has published a version of the WSDL 1.1 schema that reflects this capability at: http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd

4.3 Types

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

The wsdl:types element of WSDL 1.1 encloses data type definitions that are relevant to the Web service described. The Profile places the following constraints pertinent to those portions of the content of the wsdl:types element that are referred to by WSDL elements that make Profile conformance claims:

4.3.1 QName References

XML Schema requires each QName reference to use either the target namespace, or an imported namespace (one marked explicitly with an xsd:import element). QName references to namespaces represented only by nested imports are not allowed.

WSDL 1.1 is unclear as to which schema target namespaces are suitable for QName references from a WSDL element. The Profile allows QName references from WSDL elements both to the target namespace defined by the xsd:schema element, and to imported namespaces. QName references to namespaces that are only defined through a nested import are not allowed.

R2101 A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document. TESTABLE feedme

Test Assertion:	BP2416
Description:	Every QName in the WSDL document that is not referring to a schema component, is either using the target namespace of this WSDL or the target namespace of a directly imported WSDL component.
Prerequisite:
Context:	//wsdl:part
Match:	((string-length(substring-before(@element, ':')) = 0) or (namespace::[name(.) = substring-before(../@element, ':')] = ancestor::wsdl:definitions//xs:schema/@targetNamespace) or (namespace::[name(.) = substring-before(../@element, ':')] = ancestor::wsdl:definitions//wsdl:import/@namespace) or (namespace::[name(.) = substring-before(../@element, ':')] = ancestor::wsdl:definitions//@targetNamespace) or (namespace::[name(.) = substring-before(../@element, ':')] = ancestor::wsdl:definitions//xs:import/@namespace) ) and (string-length(substring-before(@type, ':')) = 0) or (namespace::[name(.) = substring-before(../@type, ':')] = ancestor::wsdl:definitions//xs:schema/@targetNamespace) or (namespace::[name(.) = substring-before(../@type, ':')] = ancestor::wsdl:definitions//wsdl:import/@namespace) or (namespace::[name(.) = substring-before(../@type, ':')] = ancestor::wsdl:definitions//@targetNamespace) or (namespace::[name(.) = substring-before(../@type, ':')] = ancestor::wsdl:definitions//xs:import/@namespace) ) )
Error Message:	A QName reference that does not refer to a schema component, is using neither the target namespace of this WSDL nor the target namespace of a directly imported WSDL component.
Diagnostic:	Defective QName(s).

R2102 A QName reference to a Schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element. TESTABLE BP2416

4.3.2 Schema targetNamespace Structure

Requiring a targetNamespace on all xsd:schema elements that are children of wsdl:types is a good practice, places a minimal burden on authors of WSDL documents, and avoids the cases that are not as clearly defined as they might be.

R2105 All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s). TESTABLE BP2107

Test Assertion:	BP2107
Description:	The xsd:schema element contains a targetNamespace attribute with a valid and non-null value unless the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).
Prerequisite:
Context:	//wsdl:definitions[wsdl:types/xsd:schema]
Match:	wsdl:types/xsd:schema[@targetNamespace[string-length(text()) != 0] or (count(xsd:import) + count(xsd:annotation)) = count(child::*)]
Error Message:	A xsd:schema element contained in a wsdl:types element does not have a targetNamespace attribute with a valid and non-null value, while having child element(s) other than xsd:import or xsd:annotation.
Diagnostic:	Defective xsd:schema element(s).

4.3.3 soapenc:Array

The recommendations in WSDL 1.1 Section 2.2 for declaration of array types have been interpreted in various ways, leading to interoperability problems. Further, there are other clearer ways to declare arrays.

R2110 In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array type. TESTABLE BP2108

Test Assertion:	BP2108
Description:	The type soapenc:Array does not appear in these declarations, and the wsdl:arrayType attribute is not used in the type declaration.
Prerequisite:
Context:	//wsdl:definitions/[wsdl:types/xsd:schema[descendant::xsd:extension or descendant::xsd:restriction]]
Match:	not (wsdl:types/xsd:schema[descendant::xsd:extension/@base="soapenc:Array" or descendant::xsd:restriction/@base="soapenc:Array"])
Error Message:	An Array declaration uses - restricts or extends - the soapenc:Array type, or the wsdl:arrayType attribute is used in the type declaration.
Diagnostic:	Defective declaration(s).

R2111 In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration. TESTABLE BP2108a

Test Assertion:	BP2108a
Description:	The type soapenc:Array does not appear in these declarations, and the wsdl:arrayType attribute is not used in the type declaration.
Prerequisite:
Context:	//wsdl:definitions[wsdl:types/xsd:schema]
Match:	not (wsdl:types/xsd:schema/descendant::*/@wsdl:arrayType)
Error Message:	An Array declaration uses - restricts or extends - the soapenc:Array type, or the wsdl:arrayType attribute is used in the type declaration.
Diagnostic:	Defective declaration(s).

R2112 In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX. TESTABLE BP2110

Test Assertion:	BP2110
Description:	The declaration does not use the naming convention ArrayOfXXX.
Prerequisite:
Context:	//wsdl:definitions[wsdl:types/xsd:schema]
Match:	not (wsdl:types/xsd:schema/descendant::xsd:element[substring-starts-with(@name, "ArrayOf")])
Error Message:	A declaration is using the convention ArrayOfXXX.
Diagnostic:	Defective declaration(s).

R2113 An ENVELOPE MUST NOT include the soapenc:arrayType attribute. TESTABLE BP1204

Test Assertion:	BP1204
Description:	The soap:body of the envelope does not contain the soapenc:arrayType attribute.
Prerequisite:	BP1701
Context:	//soap:Envelope
Match:	not (descendant::*[@soapenc:arrayType])
Error Message:	The soap:body of an envelope contains the soapenc:arrayType attribute.
Diagnostic:	SOAP envelope.

INCORRECT:

Given the WSDL Description:


              <xsd:element name="MyArray2"
              type="tns:MyArray2Type"/> <xsd:complexType
              name="MyArray2Type"
              xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
              xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
              <xsd:complexContent> <xsd:restriction
              base="soapenc:Array"> <xsd:sequence>
              <xsd:element name="x" type="xsd:string" minOccurs="0"
              maxOccurs="unbounded"/> </xsd:sequence>
              <xsd:attribute ref="soapenc:arrayType"
              wsdl:arrayType="tns:MyArray2Type[]"/>
              </xsd:restriction> </xsd:complexContent>
              </xsd:complexType>

The envelope would serialize as (omitting namespace declarations for clarity):


              <MyArray2 soapenc:arrayType="tns:MyArray2Type[]" >
              <x>abcd</x> <x>efgh</x>
              </MyArray2>

CORRECT:

Given the WSDL Description:


              <xsd:element name="MyArray1"
              type="tns:MyArray1Type"/> <xsd:complexType
              name="MyArray1Type"> <xsd:sequence>
              <xsd:element name="x" type="xsd:string" minOccurs="0"
              maxOccurs="unbounded"/> </xsd:sequence>
              </xsd:complexType>

The envelope would serialize as (omitting namespace declarations for clarity):


              <MyArray1> <x>abcd</x>
              <x>efgh</x> </MyArray1>

4.3.4 WSDL and Schema Definition Target Namespaces

The names defined by schemas and the names assigned to WSDL definitions are in separate symbol spaces.

R2114 The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same. WSDL20 NOT_TESTABLE BP2999

4.3.5 Multiple GED Definitions with the same QName

The schema components of all the xs:schema children, and their imports and includes, of the wsdl:types element comprise a single symbol space containing all the global element declarations. Thus, when global element declarations share a qualified name, a single component will be represented in the symbol space. If two declarations are identical, there is no ambiguity in the structure of the component, but if the declarations differ, it is indeterminate as to which of the declarations will be represented, which may lead to interoperability problems. Because defining an equivalence algorithm is impractical, this requirement warns against any appearance of declarations with the same qualified name. However, duplicate declarations are not strictly prohibited, as user inspection may determine that two declarations are actually identical (e.g. they were imported from the same set of components) and thus are unlikely to cause interoperability problems.

R2115 A DESCRIPTION SHOULD NOT contain multiple global element declarations that share the same qualified name. TESTABLE_PARTIALLY BP2124

Test Assertion:	BP2124
Description:	No two global element declarations share the same qualified name.
Prerequisite:
Context:	//wsdl:definitions/wsdl:types/xsd:schema
Match:	count (xsd:element[@name = preceding-sibling::element/@name)]) = 0
Error Message:	Two or more global element declarations share the same qualified name.
Diagnostic:	The wsdl:operation elements containing the repeated global element declarations.

4.3.6 Multiple Type Definitions with the same QName

The schema components of all the xs:schema children, and their imports and includes, of the wsdl:types element comprise single symbol spaces containing all the type definitions. Thus, when type definitions share a qualified name, a single component will be represented in the symbol space. If two definitions are identical, there is no ambiguity in the structure of the component, but if the definitions differ, it is indeterminate as to which of the definitions will be represented, which may lead to interoperability problems. Because defining an equivalence algorithm is impractical, this requirement warns against any appearance of definitions with the same qualified name. However, duplicate definitions are not strictly prohibited, as user inspection may determine that two definitions are actually identical (e.g. they were imported from the same set of components) and thus are unlikely to cause interoperability problems.

R2116 A DESCRIPTION SHOULD NOT contain multiple type definitions that share the same qualified name. TESTABLE_PARTIALLY BP2125

4.4 Messages

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

Test Assertion:	BP2125
Description:	No two type definitions share the same qualified name.
Prerequisite:
Context:	//wsdl:definitions/wsdl:types/xsd:schema
Match:	(count (xsd:ComplexType[@name = preceding-sibling::ComplexType/@name)]) = 0) And (count (xsd:SimpleType[@name = preceding-sibling::SimpleType/@name)]) = 0)
Error Message:	Two or more type definitions share the same qualified name.
Diagnostic:	The elements containing the repeated qualified name.

In WSDL 1.1, wsdl:message elements are used to represent abstract definitions of the data being transmitted. It uses wsdl:binding elements to define how the abstract definitions are bound to a specific message serialization. The Profile places the following constraints on wsdl:message elements and on how conformant wsdl:binding elements may use wsdl:message element(s).

In this section the following definitions are used to make the requirements more compact and easier to understand.

4.4.1 Bindings and Parts

There are various interpretations about how many wsdl:part elements are permitted or required for document-literal and rpc-literal bindings and how they must be defined.

R2201 A document-literal binding in a DESCRIPTION MUST, in each of its wsoap12:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified. TESTABLE BP2111

R2210 If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a wsoap12:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl:part s. TESTABLE_NOT_XPATH BP2119

R2202 A wsdl:binding in a DESCRIPTION MAY contain wsoap12:body element(s) that specify that zero parts form the soap:Body . NOT_TESTABLE BP2999

R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its wsoap12:body element(s), only to wsdl:part element(s) that have been defined using the type attribute. TESTABLE feedme

R2211 An ENVELOPE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of "1" or "true" on the part accessors. TESTABLE_NOT_XPATH BP1211

R2207 A wsdl:message in a DESCRIPTION MAY contain wsdl:part s that use the elements attribute provided those wsdl:part s are not referred to by a wsoap12:body in an rpc-literal binding. TESTABLE_NOT_XPATH BP2112

R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its wsoap12:body element(s), only to wsdl:part element(s) that have been defined using the element attribute. TESTABLE_NOT_XPATH BP2012

R2208 A binding in a DESCRIPTION MAY contain wsoap12:header element(s) that refer to wsdl:part s in the same wsdl:message that are referred to by its wsoap12:body element(s). NOT_TESTABLE BP2999

R2212 An ENVELOPE MUST contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. TESTABLE_NOT_XPATH BP1212

R2213 In a doc-literal description where the value of the parts attribute of wsoap12:body is an empty string, the corresponding ENVELOPE MUST have no element content in the soap:Body element. TESTABLE_NOT_XPATH BP1213

R2214 In a rpc-literal description where the value of the parts attribute of wsoap12:body is an empty string, the corresponding ENVELOPE MUST have no part accessor elements. TESTABLE_NOT_XPATH BP1214

Use of wsdl:message elements with zero parts is permitted in Document styles to permit operations that can send or receive envelopes with empty soap:Body s. Use of wsdl:message elements with zero parts is permitted in RPC styles to permit operations that have no (zero) parameters and/or a return value.

For document-literal bindings, the Profile requires that at most one part, abstractly defined with the element attribute, be serialized into the soap:Body element.

When a wsdl:part element is defined using the type attribute, the serialization of that part in a message is equivalent to an implicit (XML Schema) qualification of a minOccurs attribute with the value "1", a maxOccurs attribute with the value "1" and a nillable attribute with the value "false".

It is necessary to specify the equivalent implicit qualification because the wsdl:part element does not allow one to specify the cardinality and nillability rules. Specifying the cardinality and the nillability rules facilitates interoperability between implementations. The equivalent implicit qualification for nillable attribute has a value of "false" because if it is specified to be "true" one cannot design a part whereby the client is always required to send a value. For applications that want to allow the wsdl:part to to be nillable, it is expected that applications will generate a complexType wrapper and specify the nillability rules for the contained elements of such a wrapper.

4.4.2 Bindings and Faults

There are several interpretations for how wsdl:part elements that describe wsoap12:fault , wsoap12:header , and wsoap12:headerfault may be defined.

R2205 A wsdl:binding in a DESCRIPTION MUST refer, in each of its wsoap12:header , wsoap12:headerfault and wsoap12:fault elements, only to wsdl:part element(s) that have been defined using the element attribute. TESTABLE_NOT_XPATH BP2113

Because faults and headers do not contain parameters, wsoap12:fault , wsoap12:header and wsoap12:headerfault assume, per WSDL 1.1, that the value of the style attribute is "document". R2204 requires that all wsdl:part elements with a style attribute whose value is "document" that are bound to wsoap12:body be defined using the element attribute. This requirement does the same for wsoap12:fault , wsoap12:header and wsoap12:headerfault elements.

4.4.3 Unbound portType Element Contents

WSDL 1.1 is not explicit about whether it is permissible for a wsdl:binding to leave the binding for portions of the content defined by a wsdl:portType unspecified.

R2209 A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of wsoap12:body , wsoap12:header , wsoap12:fault or wsoap12:headerfault . TESTABLE BP2114

A portType defines an abstract contract with a named set of operations and associated abstract messages. Although not disallowed, it is expected that every part of the abstract input, output and fault messages specified in a portType is bound to wsoap12:body or wsoap12:header (and so forth) as appropriate when using the SOAP binding as defined in WSDL 1.1 Section 3. Un-bound wsdl:parts should be ignored.

4.4.4 Declaration of part Elements

Examples 4 and 5 in WSDL 1.1 Section 3.1 incorrectly show the use of XML Schema types (e.g. "xsd:string") as a valid value for the element attribute of a wsdl:part element.

R2206 A wsdl:message in a DESCRIPTION containing a wsdl:part that uses the element attribute MUST refer, in that attribute, to a global element declaration. TESTABLE BP2115

INCORRECT:

            <message name="GetTradePriceInput"> <part
            name="tickerSymbol" element="xsd:string"/> <part
            name="time" element="xsd:timeInstant"/> </message>

INCORRECT:

            <message name="GetTradePriceInput"> <part
            name="tickerSymbol" element="xsd:string"/>
            </message>

CORRECT:

            <message name="GetTradePriceInput"> <part
            name="body" element="tns:SubscribeToQuotes"/>
            </message>

4.5 Port Types

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

In WSDL 1.1, wsdl:portType elements are used to group a set of abstract operations. The Profile places the following constraints on conformant wsdl:portType element(s):

4.5.1 Ordering of part Elements

Permitting the use of parameterOrder helps code generators in mapping between method signatures and messages on the wire.

R2301 The order of the elements in the soap:Body of an ENVELOPE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. TESTABLE_NOT_XPATH BP1011

Test Assertion:	BP1011
Description:	The content of the envelope matches the definition in the WSDL document. In case of a doc-lit binding, the child element of soap:body is an instance of the global element declaration referenced by the corresponding wsdl:part. If the message has "parts", the order of the part elements in the soap:body of the wired message, is same as that of the wsdl:partS, in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element. still TODO: This assumes the message is an input message. This ignores namespaces.
Prerequisite:	BP1701 BP1308
Context:	//soap:Envelope
Match:	every $bodyEl in ./soap:Body/* satisfies for $arg in $bodyEl/* return for $messageName in substring-after(string( //wsdl:portType/wsdl:operation[@name=local-name-from-QName(node-name($bodyEl))] /wsdl:input/@message), ":") return for $wsdlMessage in //wsdl:message[@name=$messageName] return for $argIndex in index-of($arg/../*, $arg) return for $partsList in //wsdl:binding/wsdl:operation[@name=local-name-from-QName(node-name($bodyEl))] /wsdl:input/soapbind:body/@parts return for $partName in tokenize(string($partsList), "\s+")[$argIndex] return for $elementName in substring-after($wsdlMessage/wsdl:part[@name=$partName]/@element, ":") return $arg instance of schema-element($elementName)
Error Message:	The content of the envelope does not match the wsdl:message definition. The order of parts in soap:body does not match the order of wsdl:partS in wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element; or the child element of soap:body is not an instance of the global element declaration referenced by the corresponding wsdl:part.
Diagnostic:	Non-matching WSDL operation and envelope.

R2302 A DESCRIPTION MAY use the parameterOrder attribute of an wsdl:operation element to indicate the return value and method signatures as a hint to code generators. NOT_TESTABLE BP2999

4.5.2 Allowed Operations

Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them.

R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition. TESTABLE BP2208

4.5.3 Distinctive Operations

Operation name overloading in a wsdl:portType is disallowed by the Profile.

R2304 A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes. TESTABLE BP2010

Note that this requirement applies only to the wsdl:operation s within a given wsdl:portType . A wsdl:portType may have wsdl:operation s with names that are the same as those found in other wsdl:portType s.

4.5.4 parameterOrder Attribute Construction

WSDL 1.1 does not clearly state how the parameterOrder attribute of the wsdl:operation element (which is the child of the wsdl:portType element) should be constructed.

R2305 A wsdl:operation element child of a wsdl:portType element in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message. TESTABLE_NOT_XPATH BP2014

If a wsdl:part from the output message is omitted from the list of wsdl:part s that is the value of the parameterOrder attribute, the single omitted wsdl:part is the return value. There are no restrictions on the type of the return value. If no part is omitted, there is no return value.

4.5.5 Exclusivity of type and element Attributes

WSDL 1.1 does not clearly state that both type and element attributes cannot be specified to define a wsdl:part in a wsdl:message .

R2306 A wsdl:message in a DESCRIPTION MUST NOT specify both type and element attributes on the same wsdl:part . TESTABLE BP2116

4.6 Bindings

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

In WSDL 1.1, the wsdl:binding element supplies the concrete protocol and data format specifications for the operations and messages defined by a particular wsdl:portType . The Profile places the following constraints on conformant binding specifications:

4.6.1 Use of SOAP Binding

The Profile limits the choice of bindings to the well-defined and most commonly used SOAP 1.2 binding.

R2401 A wsdl:binding element in a DESCRIPTION MUST use the SOAP 1.2 binding as defined in the WSDL 1.1 Binding extension for SOAP 1.2. TESTABLE BP2402

Note that this places a requirement on the construction of conformant wsdl:binding elements. It does not place a requirement on descriptions as a whole; in particular, it does not preclude WSDL documents from containing non-conformant wsdl:binding elements. Also, a binding may have WSDL extensibility elements present which change how messages are serialized.

4.7 SOAP Binding

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

WSDL 1.1 Binding Extension for SOAP 1.2 defines a binding for SOAP 1.2 endpoints. The Profile mandates the use of the SOAP 1.2 binding as defined in WSDL 1.1 Binding Extension for SOAP 1.2, and places the following constraints on its use:

4.7.1 Specifying the transport Attribute

There is an inconsistency between the WSDL 1.1 specification and the WSDL 1.1 schema regarding the transport attribute. The WSDL 1.1 specification requires it; however, the schema shows it to be optional.

R2701 The wsdl:binding element in a DESCRIPTION MUST be constructed so that its wsoap12:binding child element specifies the transport attribute. TESTABLE feedme

4.7.2 HTTP Transport

The profile limits the underlying transport protocol to HTTP.

R2702 A wsdl:binding element in a DESCRIPTION MUST specify the HTTP transport protocol with SOAP binding. Specifically, the transport attribute of its wsoap12:binding child MUST have the value "http://schemas.xmlsoap.org/soap/http". TESTABLE BP2404

Note that this requirement does not prohibit the use of HTTPS; See R5000.

4.7.3 Consistency of style Attribute

The style , "document" or "rpc", of an interaction is specified at the wsdl:operation level, permitting wsdl:binding s whose wsdl:operation s have different style s. This has led to interoperability problems. Additionally, use of document-literal binding, which generally allows for simpler implementations than the rpc-literal binding, is encouraged.. This hint is not always appropriate, especially in the case of some existing implementations, which continue to be supported by this profile.

R2705 A wsdl:binding in a DESCRIPTION MUST either be a rpc-literal binding or a document-literal binding. TESTABLE BP2017

4.7.4 Encodings and the use Attribute

The Profile prohibits the use of encodings, including the SOAP encoding.

R2706 A wsdl:binding in a DESCRIPTION MUST use the value of "literal" for the use attribute in all wsoap12:body , wsoap12:fault , wsoap12:header and wsoap12:headerfault elements. TESTABLE BP2406

4.7.5 Multiple Bindings for portType Elements

The Profile explicitly permits multiple bindings for the same portType.

R2709 A wsdl:portType in a DESCRIPTION MAY have zero or more wsdl:binding s that refer to it, defined in the same or other WSDL documents. NOT_TESTABLE BP2998

4.7.6 Operation Signatures

Definition: operation signature

The Profile defines the "operation signature" to be the fully qualified name of the child element of SOAP body of the SOAP input message described by an operation in a WSDL binding and the URI value of the wsa:Action SOAP header block, if present. Compat

In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement.

An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique operation signature.

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another. Compat TESTABLE_NOT_XPATH BP2120

4.7.7 Multiple Ports on an Endpoint

When input messages destined for two different wsdl:port s at the same network endpoint are indistinguishable on the wire, it may not be possible to determine the wsdl:port being invoked by them. This may cause interoperability problems. However, there may be situations (e.g., SOAP versioning, application versioning, conformance to different profiles) where it is desirable to locate more than one port on an endpoint; therefore, the Profile allows this.

R2711 A DESCRIPTION SHOULD NOT have more than one wsdl:port with the same value for the location attribute of the wsoap12:address element. TESTABLE BP9992

4.7.8 Child Element for Document-Literal Bindings

WSDL 1.1 is not completely clear what, in document-literal style bindings, the child element of soap:Body is.

R2712 A document-literal binding MUST be serialized as an ENVELOPE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part. TESTABLE_NOT_XPATH BP1011

4.7.9 One-Way Operations

There are differing interpretations of how HTTP is to be used when performing one-way operations. The SOAP 1.2 Request-Response SOAP MEP specifies the expectations for the SOAP/HTTP binding.

R2714 For one-way operations, an HTTP response MESSAGE MAY contain an envelope. Compat NOT_TESTABLE BP2999

R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it. NOT_TESTABLE BP2999

One-way operations typically do not produce SOAP responses. However, in order to support advanced protocol extensions such as WS-Reliable Messaging, the Basic Profile 1.1 requirement that the HTTP response message not contain a SOAP envelope has been relaxed.

The HTTP response to a one-way operation indicates the success or failure of the transmission of the message. Based on the semantics of the different response status codes supported by the HTTP protocol, the Profile specifies that "200" and "202" are the preferred status codes that the sender should expect, signifying that the one-way message was received. A successful transmission does not indicate that the SOAP processing layer and the application logic has had a chance to validate the envelope or have committed to processing it.

4.7.10 Namespaces for wsoap12 Elements

There is confusion about what namespace is associated with the child elements of various children of soap:Envelope , which has led to interoperability difficulties. The Profile defines these.

R2716 A document-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained wsoap12:body , wsoap12:header , wsoap12:headerfault and wsoap12:fault elements. TESTABLE BP2019

R2717 An rpc-literal binding in a DESCRIPTION MUST have the namespace attribute specified, the value of which MUST be an absolute URI, on contained wsoap12:body elements. TESTABLE BP2020

R2726 An rpc-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained wsoap12:header , wsoap12:headerfault and wsoap12:fault elements. TESTABLE BP2117

In a document-literal SOAP binding, the serialized element child of the soap:Body gets its namespace from the targetNamespace of the schema that defines the element. Use of the namespace attribute of the wsoap12:body element would override the element's namespace. This is not allowed by the Profile.

Conversely, in a rpc-literal SOAP binding, the serialized child element of the soap:Body element consists of a wrapper element, whose namespace is the value of the namespace attribute of the wsoap12:body element and whose local name is either the name of the operation or the name of the operation suffixed with "Response". The namespace attribute is required, as opposed to being optional, to ensure that the children of the soap:Body element are namespace-qualified.

4.7.11 Consistency of portType and binding Elements

The WSDL description must be consistent at both wsdl:portType and wsdl:binding levels.

R2718 A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operation s as the wsdl:portType to which it refers. C TESTABLE_NOT_XPATH BP2118

4.7.12 Enumeration of Faults

A Web service description should include all faults known at the time the service is defined. There is also need to permit generation of new faults that had not been identified when the Web service was defined.

R2740 A wsdl:binding in a DESCRIPTION SHOULD contain a wsoap12:fault describing each known fault. NOT_TESTABLE BP1107

R2741 A wsdl:binding in a DESCRIPTION SHOULD contain a wsoap12:headerfault describing each known header fault. NOT_TESTABLE BP2999

R2742 An ENVELOPE MAY contain fault with a detail element that is not described by a wsoap12:fault element in the corresponding WSDL description. NOT_TESTABLE BP2999

R2743 An ENVELOPE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a wsoap12:headerfault element in the corresponding WSDL description. NOT_TESTABLE BP2999

4.7.13 Type and Name of SOAP Binding Elements

The WSDL 1.1 schema disagrees with the WSDL 1.1 specification about the name and type of an attribute of the wsoap12:header and wsoap12:headerfault elements.

R2720 A wsdl:binding in a DESCRIPTION MUST use the part attribute with a schema type of "NMTOKEN" on all contained wsoap12:header and wsoap12:headerfault elements. TESTABLE BP2021

R2749 A wsdl:binding in a DESCRIPTION MUST NOT use the parts attribute on contained wsoap12:header and wsoap12:headerfault elements. TESTABLE BP2021a

The WSDL Schema gives the attribute's name as "parts" and its type as "NMTOKENS". The schema is incorrect since each wsoap12:header and wsoap12:headerfault element references a single wsdl:part .

CORRECT:

            <binding name="StockQuoteSoap"
            type="tns:StockQuotePortType"> <wsoap12:binding
            style="document"
            transport="http://schemas.xmlsoap.org/soap/http"/>
            <operation name="SubscribeToQuotes"> <input
            message="tns:SubscribeToQuotes"> <wsoap12:body
            parts="body" use="literal"/> <wsoap12:header
            message="tns:SubscribeToQuotes" part="subscribeheader"
            use="literal"/> </input> </operation>
            </binding>

4.7.14 name Attribute on Faults

There is inconsistency between the WSDL 1.1 specification and the WSDL 1.1 schema, which does not list the name attribute.

R2721 A wsdl:binding in a DESCRIPTION MUST have the name attribute specified on all contained wsoap12:fault elements. TESTABLE feedme

R2754 In a DESCRIPTION, the value of the name attribute on a wsoap12:fault element MUST match the value of the name attribute on its parent wsdl:fault element. TESTABLE BP2032

4.7.15 Omission of the use Attribute

There is inconsistency between the WSDL 1.1 specification and the WSDL 1.1 schema regarding the use attribute.

R2722 A wsdl:binding in a DESCRIPTION MAY specify the use attribute on contained wsoap12:fault elements. C NOT_TESTABLE BP2999

R2723 If in a wsdl:binding in a DESCRIPTION the use attribute on a contained wsoap12:fault element is present, its value MUST be "literal". TESTABLE BP2406

WSDL 1.1 Section 3.6 indicates that the use attribute of wsoap12:fault is required while in the schema the use attribute is defined as optional. The Profile defines it as optional, to be consistent with wsoap12:body .

Since the use attribute is optional, the Profile identifies the default value for the attribute when omitted.

Finally, to assure that the Profile is self-consistent, the only permitted value for the use attribute is "literal".

4.7.16 Default for use Attribute

There is an inconsistency between the WSDL 1.1 specification and the WSDL 1.1 schema regarding whether the use attribute is optional on wsoap12:body , wsoap12:header , and wsoap12:headerfault , and if so, what omitting the attribute means.

R2707 A wsdl:binding in a DESCRIPTION that contains one or more wsoap12:body , wsoap12:fault , wsoap12:header or wsoap12:headerfault elements that do not specify the use attribute MUST be interpreted as though the value "literal" had been specified in each case. NOT_TESTABLE BP2999

4.7.17 Consistency of Envelopes with Descriptions

These requirements specify that when an instance receives an envelope that does not conform to the WSDL description, a fault should be generated unless the instance takes it upon itself to process the envelope regardless of this.

As specified by the SOAP processing model, (a) a "VersionMismatch" faultcode must be generated if the namespace of the "Envelope" element is incorrect, (b) a "MustUnderstand" fault must be generated if the instance does not understand a SOAP header block with a value of "1" for the soap:mustUnderstand attribute. In all other cases where an envelope is inconsistent with its WSDL description, a fault with a "Client" faultcode should be generated.

R2724 If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of "Client", unless a "MustUnderstand" or "VersionMismatch" fault is generated. NOT_TESTABLE BP2999

R2725 If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it MUST check for "VersionMismatch", "MustUnderstand" and "Client" fault conditions in that order. NOT_TESTABLE BP2999

4.7.18 Response Wrappers

WSDL 1.1 Section 3.5 could be interpreted to mean the RPC response wrapper element must be named identical to the name of the wsdl:operation .

R2729 An ENVELOPE described with an rpc-literal binding that is a response MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string "Response". TESTABLE_NOT_XPATH BP1005

4.7.19 Part Accessors

For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the accessor elements for parameters and return value are a part of. Different implementations make different choices, leading to interoperability problems.

R2735 An ENVELOPE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace. TESTABLE BP1008

R2755 The part accessor elements in a MESSAGE described with an rpc-literal binding MUST have a local name of the same value as the name attribute of the corresponding wsdl:part element . TESTABLE_NOT_XPATH BP1755

Settling on one alternative is crucial to achieving interoperability. The Profile places the part accessor elements in no namespace as doing so is simple, covers all cases, and does not lead to logical inconsistency.

4.7.20 Namespaces for Children of Part Accessors

For rpc-literal envelopes, WSDL 1.1 is not clear on what the correct namespace qualification is for the child elements of the part accessor elements when the corresponding abstract parts are defined to be of types from a different namespace than the targetNamespace of the WSDL description for the abstract parts.

R2737 An ENVELOPE described with an rpc-literal binding MUST namespace qualify the descendents of part accessor elements for the parameters and the return value, as defined by the schema in which the part accessor types are defined. TESTABLE_NOT_XPATH BP1008

WSDL 1.1 Section 3.5 states: "The part names, types and value of the namespace attribute are all inputs to the encoding, although the namespace attribute only applies to content not explicitly defined by the abstract types."

However, it does not explicitly state that the element and attribute content of the abstract (complexType) types is namespace qualified to the targetNamespace in which those elements and attributes were defined. WSDL 1.1 was intended to function in much the same manner as XML Schema. Hence, implementations must follow the same rules as for XML Schema. If a complexType defined in targetNamespace "A" were imported and referenced in an element declaration in a schema with targetNamespace "B", the element and attribute content of the child elements of that complexType would be qualified to namespace "A" and the element would be qualified to namespace "B".

CORRECT:

Given this WSDL, which defines some schema in the "http://example.org/foo/" namespace in the wsdl:types section contained within a wsdl:definitions that has a targetNamespace attribute with the value "http://example.org/bar/" (thus, having a type declared in one namespace and the containing element defined in another);


              <definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
              xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
              xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap/"
              xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              xmlns:bar="http://example.org/bar/"
              targetNamespace="http://example.org/bar/"
              xmlns:foo="http://example.org/foo/"> <types>
              <xsd:schema targetNamespace="http://example.org/foo/"
              xmlns:tns="http://example.org/foo/"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"> <xsd:complexType
              name="fooType"> <xsd:sequence> <xsd:element
              ref="tns:bar"/> <xsd:element ref="tns:baf"/>
              </xsd:sequence> </xsd:complexType>
              <xsd:element name="bar" type="xsd:string"/>
              <xsd:element name="baf" type="xsd:integer"/>
              </xsd:schema> </types> <message
              name="BarMsg"> <part name="BarAccessor"
              type="foo:fooType"/> </message> <portType
              name="BarPortType"> <operation
              name="BarOperation"> <input
              message="bar:BarMsg"/> </operation>
              </portType> <binding name="Barwsoap12ing"
              type="bar:BarPortType"> <wsoap12:binding
              transport="http://schemas.xmlsoap.org/soap/http"
              style="rpc"/> <operation name="BarOperation">
              <input> <wsoap12:body use="literal"
              namespace="http://example.org/bar/"/> </input>
              </operation> </binding> <service
              name="serviceName"> <port name="BarSOAPPort"
              binding="bar:Barwsoap12ing"> <wsoap12:address
              location="http://example.org/myBarSOAPPort"/>
              </port> </service> </definitions>

The resulting envelope for BarOperation is:


              <s:Envelope
              xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              xmlns:foo="http://example.org/foo/"> <s:Header/>
              <s:Body> <m:BarOperation
              xmlns:m="http://example.org/bar/"> <BarAccessor>
              <foo:bar>String</foo:bar>
              <foo:baf>0</foo:baf> </BarAccessor>
              </m:BarOperation> </s:Body>
              </s:Envelope>

4.7.21 Required Headers

WSDL 1.1 does not clearly specify whether all wsoap12:header s specified on the wsdl:input or wsdl:output elements of a wsdl:operation element in the SOAP binding section of a WSDL description must be included in the resultant envelopes when they are transmitted. The Profile makes all such headers mandatory, as there is no way in WSDL 1.1 to mark a header optional.

R2738 An ENVELOPE MUST include all wsoap12:header s specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it. TESTABLE BP1009

4.7.22 Allowing Undescribed Headers

Headers are SOAP's extensibility mechanism. Headers that are not defined in the WSDL description may need to be included in the envelopes for various reasons.

R2739 An ENVELOPE MAY contain SOAP header blocks that are not described in the wsdl:binding that describes it. NOT_TESTABLE BP2999

R2753 An ENVELOPE containing SOAP header blocks that are not described in the appropriate wsdl:binding MAY have the mustUnderstand attribute on such SOAP header blocks set to '1'. NOT_TESTABLE BP3999

4.7.23 Ordering Headers

There is no correlation between the order of wsoap12:header s in the description and the order of SOAP header blocks in the envelope. Similarly, more than one instance of each specified SOAP header block may occur in the envelope.

R2751 The order of wsoap12:header elements in wsoap12:binding sections of a DESCRIPTION MUST be considered independent of the order of SOAP header blocks in the envelope. NOT_TESTABLE BP2999

R2752 An ENVELOPE MAY contain more than one instance of each SOAP header block for each wsoap12:header element in the appropriate child of wsoap12:binding in the corresponding description. NOT_TESTABLE BP2999

4.7.24 Describing action Parameter on the Content-Type MIME Header

See Section 3.6.3 Parameters on the Content-Type MIME Header

R2744 If the action parameter on the Content-Type header is present in a HTTP MESSAGE, its value MUST be equal to the value of the corresponding soapAction attribute of wsoap12:operation. TESTABLE BP1116

See also R1119 and related requirements for more discussion of action parameter on the Content-Type MIME header.

4.7.25 SOAPAction HTTP Header

Unlike SOAP 1.1, SOAP 1.2 HTTP binding does not use the SOAPAction HTTP header in the HTTP request messages. Relying on the presence of SOAPAction HTTP header or the value of SOAPAction HTTP header may result in interoperability problems.

R2760 A RECEIVER MUST NOT rely on the presence of SOAPAction HTTP header to correctly process the message. TESTABLE feedme

R2761 A SENDER SHOULD NOT include the SOAPAction HTTP header. NOT_TESTABLE BP2999

4.7.26 SOAP Binding Extensions

The wsdl:required attribute has been widely misunderstood and used by WSDL authors sometimes to incorrectly indicate the optionality of wsoap12:header s. The wsdl:required attribute, as specified in WSDL 1.1, is an extensibility mechanism aimed at WSDL processors. It allows new WSDL extension elements to be introduced in a graceful manner. The intent of wsdl:required is to signal to the WSDL processor whether the extension element needs to be recognized and understood by the WSDL processor in order that the WSDL description be correctly processed. It is not meant to signal conditionality or optionality of some construct that is included in the envelopes. For example, a wsdl:required attribute with the value "false" on a wsoap12:header element must not be interpreted to signal to the WSDL processor that the described SOAP header block is conditional or optional in the envelopes generated from the WSDL description. It is meant to be interpreted as "in order to send a envelope to the endpoint that includes in its description the wsoap12:header element, the WSDL processor MUST understand the semantic implied by the wsoap12:header element."

The default value for the wsdl:required attribute for WSDL 1.1 SOAP Binding extension elements is "false". Most WSDL descriptions in practice do not specify the wsdl:required attribute on the SOAP Binding extension elements, which could be interpreted by WSDL processors to mean that the extension elements may be ignored. The Profile requires that all WSDL 1.1 extensions be understood and processed by the consumer, irrespective of the presence or the value of the wsdl:required attribute on an extension element.

R2747 A CONSUMER MUST understand and process all WSDL 1.1 SOAP Binding extension elements, irrespective of the presence or absence of the wsdl:required attribute on an extension element; and irrespective of the value of the wsdl:required attribute, when present. NOT_TESTABLE BP2999

R2748 A CONSUMER MUST NOT interpret the presence of the wsdl:required attribute on a wsoap12 extension element with a value of "false" to mean the extension element is optional in the envelopes generated from the WSDL description. NOT_TESTABLE BP2999

4.8 Use of @soapActionRequired in WSDL 1.1 SOAP 1.2 Binding

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

The WSDL 1.1 Binding Extension for SOAP 1.2 incorporates an attribute called wsoap12:soapActionRequired that has a default value of 'true'. This has the effect that in order to have the action parameter omitted from the Content-Type HTTP header field, one would need to explicitly include the attribute in a description with a value of 'false'. The action parameter is defined by SOAP 1.2 to be OPTIONAL so as to enable use cases in which the sender of a SOAP message wishes to disallow casual inspection of the clear-text part of the message to infer its purpose or intent. Additionally, implementations are cautioned that they SHOULD NOT require the parameter's presence in a message in order to process the message.

The Profile WG believes that the wsoap12:soapActionRequired attribute runs counter to the SOAP 1.2 specification's intent. Therefore, the attribute has been profiled such that it MUST NOT be used, as it would tend to eliminate the very use cases that lead to the design of the SOAP 1.2 action parameter.

R2756 A DESCRIPTION MUST NOT include the wsoap12:soapActionRequired attribute. TESTABLE feedme

R2757 A RECEIVER MUST NOT require the presence of the action parameter on the Content-Type HTTP header field. TESTABLE feedme

R2758 A MESSAGE MAY omit the action parameter from the Content-Type HTTP header field. TESTABLE feedme

4.9 Use of XML Schema

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

WSDL 1.1 uses XML Schema as one of its type systems. The Profile mandates the use of XML Schema as the type system for WSDL descriptions of Web Services.

R2800 A DESCRIPTION MAY use any construct from XML Schema 1.0. NOT_TESTABLE BP2999

R2801 A DESCRIPTION MUST use XML Schema 1.0 Recommendation as the basis of user defined datatypes and structures. TESTABLE BP2122

4.10 WS-Addresing 1.0 - Metadata

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

WS-Addressing MAPs can be specified in a WSDL document. The Profile adds restrictions to such properties specified in WSDL.

The wsaw:Action attribute is used in WSDL to specify the value of the wsa:Action MAP in the envelope. A default value computation algorithm is specified for the case where an explicit wsaw:Action attribute is not specified. The value of wsa:Action specified in the envelope must match the value of the action parameter of the Content-Type MIME header, if present

R2900 The value of wsa:Action MAP in an ENVELOPE MUST equal the value (either actual or computed) of wsaw:Action attribute for the corresponding WSDL element ( wsdl:input , wsdl:output , or wsdl:fault ) contained in the target wsdl:operation of the wsdl:portType . TESTABLE feedme

R2901 The value (either actual or computed) of wsaw:Action attribute for the wsdl:input element contained in the target wsdl:operation of the wsdl portType MUST equal the value of soapAction attribute, if present, inside the wsoap:operation ( soap12:operation ) element contained in the target wsdl:operation of the wsdl:binding . TESTABLE feedme

5. Service Publication and Discovery

When publication or discovery of Web services is required, UDDI is the mechanism the Profile has adopted to describe Web service providers and the Web services they provide. Business, intended use, and Web service type descriptions are made in UDDI terms; detailed technical descriptions are made in WSDL terms. Where the two specifications define overlapping descriptive data and both forms of description are used, the Profile specifies that the descriptions must not conflict.

Registration of Web service instances in UDDI registries is optional. By no means do all usage scenarios require the kind of metadata and discovery UDDI provides, but where such capability is needed, UDDI is the sanctioned mechanism.

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages whose envelopes are encoded in either UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) That there should be such a discrepancy is hardly surprising given that UDDI V2 was designed and, in many cases, implemented before the Profile was developed. UDDI's designers are aware of UDDI V2's nonconformance and will take it into consideration in their future work.

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

5.1 bindingTemplates

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

UDDI represents Web service instances as uddi:bindingTemplate elements. The uddi:bindingTemplate plays a role that is the rough analog of the wsdl:port , but provides options that are not expressible in WSDL. To keep the WSDL description of an instance and its UDDI description consistent, the Profile places the following constraints on how uddi:bindingTemplate elements may be constructed.

WSDL's wsoap12:address element requires the network address of the instance to be directly specified. In contrast, UDDI V2 provides two alternatives for specifying the network address of instances it represents. One, the uddi:accessPoint , mirrors the WSDL mechanism by directly specifying the address. The other, the uddi:hostingRedirector , provides a Web service-based indirection mechanism for resolving the address, and is inconsistent with the WSDL mechanism.

R3100 REGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element. TESTABLE BP3002

INCORRECT:

            <bindingTemplate bindingKey="..."> <description
            xml:lang="EN">BarSOAPPort</description>
            <hostingRedirector bindingKey="..."/>
            <tModelInstanceDetails> ...
            </tModelInstanceDetails> </bindingTemplate>

CORRECT:

            <bindingTemplate bindingKey="..."> <description
            xml:lang="EN">BarSOAPPort</description>
            <accessPoint>http://example.org/myBarSOAPPort</accessPoint>
            <tModelInstanceDetails> ...
            </tModelInstanceDetails> </bindingTemplate>

5.2 tModels

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

UDDI represents Web service types as uddi:tModel elements. (See UDDI Data Structures section 8.1.1 .) These may, but need not, point (using a URI) to the document that contains the actual description. Further, UDDI is agnostic with respect to the mechanisms used to describe Web service types. The Profile cannot be agnostic about this because interoperation is very much complicated if Web service types do not have descriptions or if the descriptions can take arbitrary forms.

The UDDI API Specification, appendix I.1.2.1.1 allows but does not require uddi:tModel elements that use WSDL to describe the Web service type they represent to state that they use WSDL as the description language. Not doing so leads to interoperability problems because it is then ambiguous what description language is being used.

Therefore the Profile places the following constraints on how uddi:tModel elements that describe Web service types may be constructed:

The Profile chooses WSDL as the description language because it is by far the most widely used such language.

R3002 REGDATA of type uddi:tModel representing a conformant Web service type MUST use WSDL as the description language. TESTABLE BP3001

To specify that conformant Web service types use WSDL, the Profile adopts the UDDI categorization for making this assertion.

R3003 REGDATA of type uddi:tModel representing a conformant Web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec". TESTABLE BP3003

For the uddi:overviewURL in a uddi:tModel to resolve to a wsdl:binding , the Profile must adopt a convention for distinguishing among multiple wsdl:binding s in a WSDL document. The UDDI Best Practice for Using WSDL in a UDDI Registry specifies the most widely recognized such convention.

R3010 REGDATA of type uddi:tModel representing a conformant Web service type MUST follow V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry . TESTABLE BP3001

It would be inconsistent if the wsdl:binding that is referenced by the uddi:tModel does not conform to the Profile.

R3011 The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST itself conform to the Profile. TESTABLE BP3001

6. Security

As is true of all network-oriented information technologies, the subject of security is a crucial one for Web services. For Web services, as for other information technologies, security consists of understanding the potential threats an attacker may mount and applying operational, physical, and technological countermeasures to reduce the risk of a successful attack to an acceptable level. Because an "acceptable level of risk" varies hugely depending on the application, and because costs of implementing countermeasures is also highly variable, there can be no universal "right answer" for securing Web services. Choosing the absolutely correct balance of countermeasures and acceptable risk can only be done on a case by case basis.

That said, there are common patterns of countermeasures that experience shows reduce the risks to acceptable levels for many Web services. The Profile adopts, but does not mandate use of, the most widely used of these: HTTP secured with either TLS 1.0 or SSL 3.0 (HTTPS). That is, conformant Web services may use HTTPS; they may also use other countermeasure technologies or none at all.

HTTPS is widely regarded as a mature standard for encrypted transport connections to provide a basic level of confidentiality. HTTPS thus forms the first and simplest means of achieving some basic security features that are required by many real-world Web service applications. HTTPS may also be used to provide client authentication through the use of client-side certificates.

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

6.1 Use of HTTPS

HTTPS is such a useful, widely understood basic security mechanism that the Profile needs to allow it.

R5000 An INSTANCE MAY require the use of HTTPS. NOT_TESTABLE BP1999

R5001 If an INSTANCE requires the use of HTTPS, the location attribute of the wsoap12:address element in its wsdl:port description MUST be a URI whose scheme is "https"; otherwise it MUST be a URI whose scheme is "http". NOT_TESTABLE BP1999

Simple HTTPS provides authentication of the Web service instance by the consumer but not authentication of the consumer by the instance. For many instances this leaves the risk too high to permit interoperation. Including the mutual authentication facility of HTTPS in the Profile permits instances to use the countermeasure of authenticating the consumer. In cases in which authentication of the instance by the consumer is insufficient, this often reduces the risk sufficiently to permit interoperation.

R5010 An INSTANCE MAY require the use of HTTPS with mutual authentication. NOT_TESTABLE BP1999

Appendix A: Referenced Specifications

The following specifications' requirements are incorporated into the Profile by reference, except where superseded by the Profile:

Appendix B: Extensibility Points

This section identifies extensibility points, as defined in "Scope of the Profile," for the Profile's component specifications.

These mechanisms are out of the scope of the Profile; their use may affect interoperability, and may require private agreement between the parties to a Web service.

Appendix C: Normative References

In addition to all of the profiled specifications listed in Appendix A, the following specifications are normatively referenced:

RFC2119 http://ietf.org/rfc/rfc2119 Key words for use in RFCs to Indicate Requirement Levels, S. Bradner March 1997

Appendix D: Defined Terms

The following list of terms have specific definitions that are authoritative for this profile:

Appendix E: Acknowledgements

This document is the work of the WS-I Basic Profile Working Group, whose members have included:

Mark Allerton (Crystal Decisions Corp), Steve Anderson (OpenNetwork), George Arriola (Talking Blocks, Inc.), Siddharth Bajaj (Verisign), Keith Ballinger (Microsoft Corp.), David Baum (Kantega AS), Ilya Beyer (KANA), Rich Bonneau (IONA Technologies), Don Box (Microsoft Corp.), Andrew Brown (Verisign), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Luis Felipe Cabrera (Microsoft Corp.), Maud Cahuzac (France Telecom), Mike Chadwick (Kaiser Permanente), Martin Chapman (Oracle Corporation), Richard Chennault (Kaiser Permanente), Roberto Chinnici (Sun Microsystems), Dipak Chopra (SAP AG), Jamie Clark (OASIS), David Cohen (Merrill Lynch), Ugo Corda (SeeBeyond Tech), Paul Cotton (Microsoft Corp.), Joseph Curran (Accenture), Alex Deacon (Verisign), Mike DeNicola (Fujitsu Limited), Rohit Dewan (Westbridge Technology), Paul Downey (BT Group), Jacques Durand (Fujitsu Limited), Aladin Eajani (Hummingbird, Ltd.), Michael Eder (Nokia), Dave Ehnebuske (IBM), Mark Ericson (Mindreef Inc), Colleen Evans (Microsoft Corp.), Tim Ewald (Microsoft Corp.), Chuck Fay (FileNET Corp.), Leonid Felikson (Freddie Mac), Chris Ferris (IBM), Daniel Foody (Actional Corporation), Satoru Fujita (NEC Corporation), Shishir Garg (France Telecom), Yaron Goland (BEA Systems Inc), Marc Goodner (Microsoft Corp.), Pierre Goyette (Hummingbird, Ltd.), Hans Granqvist (Verisign), Marc Graveline (Cognos), Martin Gudgin (Microsoft Corp.), Arun Gupta (Sun Microsystems), Marc Hadley (Sun Microsystems), Norma Hale (Webify Solutions Inc), Bob Hall (Unisys Corporation), Scott Hanselman (Corillian), Muir Harding (Autodesk Inc.), Loren Hart (Verisign), Andrew Hately (IBM), Harry Holstrom (Accenture), Lawrence Hsiung (Quovadx), Hemant Jain (Tata Consultancy), Steve Jenisch (SAS Institute), Ram Jeyaraman (Microsoft Corp.), Lei Jin (BEA Systems Inc), Erik Johnson (Epicor Software), Bill Jones (Oracle Corporation), Anish Karmarkar (Oracle Corporation), Dana Kaufman (Forum Systems), Takahiro Kawamura (Toshiba), Oldre Kepka (Systinet), Bhushan Khanal (WRQ Inc.), Sandy Khaund (Microsoft Corp.), Doug Kohlert (Sun Microsystems), Jacek Kopecky (Systinet), Jitendra Kotamraju (Sun Microsystems), Vince Kowalski (BMC Software, Inc.), Sanjay Krishnamurthi (Informatica), Sundar Krishnamurthy (Verisign), Eva Kuiper (Hewlett-Packard), Sunil Kunisetty (Oracle Corporation), Christopher Kurt (Microsoft Corp.), Si La (DISA), Lars Laakes (Microsoft Corp.), Charles Lavey (IBM), Canyang Kevin Liu (SAP AG), Ted Liu (webMethods Inc.), Donna Locke (Oracle Corporation), Brad Lund (Intel), Eduardo MacIver (CGI Group), Michael Mahan (Nokia), Ron Marchi (EDS), Jonathan Marsh (Microsoft Corp.), Eric Matland (Hummingbird, Ltd.), Barbara McKee (IBM), Derek Medland (Hummingbird, Ltd.), David Meyer (Plumtree Software Inc.), Jeff Mischkinsky (Oracle Corporation), Ray Modeen (MITRE Corp.), Tom Moog (Sarvega Inc.), Gilles Mousseau (Hummingbird, Ltd.), Greg Mumford (MCI), Jim Murphy (Mindreef Inc), Pat Murphy (Motorcycle Industry Council), Bryan Murray (Hewlett-Packard), Richard Nikula (BMC Software, Inc.), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems Inc), David Orchard (BEA Systems Inc), Vivek Pandey (Sun Microsystems), Jesse Pangburn (Quovadx), Mike Parsons (Epicor Software), Eduardo Pelegri-Llopart (Sun Microsystems), Mike Perham (Webify Solutions Inc), Saju Puthankalam (webMethods Inc.), Martin Raepple (SAP AG), Eric Rajkovic (Oracle Corporation), Shaan Razvi (MITRE Corp.), Rimas Rekasius (IBM), Mark Richards (Fidelity), Graeme Riddell (Bowstreet), Ian Robinson (IBM), Sam Ruby (IBM), Tom Rutt (Fujitsu Limited), Saikat Saha (Commerce One, Inc.), Roger Sanborn (Crystal Decisions Corp), Matt Sanchez (Webify Solutions Inc), Krishna Sankar (Cisco Systems Inc.), Jeffrey Schlimmer (Microsoft Corp.), Don Schricker (Micro Focus), Dave Seidel (Mindreef Inc), Darren Self (Micro Focus), AKIRA SHIMAYA (NTT), David Shoaf (Hewlett-Packard), Yasser Shohoud (Microsoft Corp.), David Smiley (Ascential Software), Skip Snow (Citigroup), Seumas Soltysik (IONA Technologies), Joseph Stanko (Plumtree Software Inc.), Andrew Stone (Accenture), Shankaran Subramanian (Citigroup), Julie Surer (MITRE Corp.), YASUO TAKEMOTO (NTT), Nobuyoshi Tanaka (NEC Corporation), Jorgen Thelin (Microsoft Corp.), Sameer Vaidya (Talking Blocks, Inc.), William Vambenepe (Hewlett-Packard), Claus von Riegen (SAP AG), Shrikant Wagh (Hewlett-Packard), Shrikant Wagh (Optimyz), Faisal Waris (Ford Motor Systems), Rick Weil (Eastman Kodak Company), Scott Werden (WRQ Inc.), Ajamu Wesley (IBM), Ian White (Micro Focus), Dave Wilkinson (Vignette), Mark Wood (Eastman Kodak Company), Prasad Yendluri (Software AG), and Brandon Zhu (NetManage Inc).

Test Assertion:	BP2111
Description:	If the "parts" attribute is present, then the soapbind:body element(s) have at most one part listed in the parts attribute.
Prerequisite:
Context:	//wsdl:definitions/wsdl:binding[not(descendant::soapbind:body/@use != 'literal') and (count(descendant::soapbind:body) = count(descendant::soapbind:body/@use)) and not(descendant::soapbind:*/@style != 'document')]
Match:	not(descendant::soapbind:body[@parts and contains(@parts," ")])
Error Message:	One or more soapbind:body element(s) in a document-literal soap:binding does not have at most one part listed in the parts attribute.
Diagnostic:	Defective soapbind:body element(s).

Test Assertion:	BP2119
Description:	If it does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message defines zero or one wsdl:part.
Prerequisite:	BP2404
Context:	For a candidate wsdl:binding, which is of type document-literal
Match:	TBD
Error Message:	A document-literal binding which does not specify the parts attribute, has more than one wsdl:part in the associated wsdl:message element.
Diagnostic:	Defective wsdl:binding element.

Test Assertion:	BP2013
Description:	The binding (in soapbind:body elements) only refers to part elements that have been defined using the "type" attribute
Prerequisite:
Context:	//wsdl:definitions/wsdl:binding[not(descendant::soapbind:body/@use != 'literal') and (count(descendant:;soapbind:body) = count(descendant::soapbind:body/@use)) and not(descendant::soapbind:*/@style != 'rpc')]
Match:	//wsdl:definitions/wsdl:binding[every $op in ./wsdl:operation satisfies (every $bo in $op/descendant::soapbind:body satisfies $bo/@use = "literal") and (soapbind:binding/@style = "rpc" or $op/soapbind:operation/@style = "rpc")]
Error Message:	soap:binding (in soapbind:body elements) refers to part(s) that do not have the "type" attribute.
Diagnostic:	{binding}{message with failed part}

Test Assertion:	BP1211
Description:	Part accessor elements in the envelope do not have an xsi:nil attribute with a value of "1" or "true".
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope containing a soap:body with at least one element, and that is referred by a binding style rpc-literal
Match:	TBD
Error Message:	Envelope referenced by an rpc-literal binding has part accessor elements with an xsi:nil attribute with a value of "1" or "true".
Diagnostic:

Test Assertion:	BP2112
Description:	No wsdl:part referred by such a soapbind:body element is defined using the "element" attribute.
Prerequisite:
Context:	For a candidate wsdl:binding, with a style "rpc" attribute and containing at least a soapbind:body element
Match:	TBD
Error Message:	The referred wsdl:part element uses the "element" attribute in an rpc-literal soapbind:body.
Diagnostic:	{soapbind:body}{wsdl:part element(s)}

Test Assertion:	BP1212
Description:	The envelope contains exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element.
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope containing a soap:body with at least one element
Match:	TBD
Error Message:	The content of the soap:Body element is inconsistent with its description. The envelope does not contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element.
Diagnostic:

Test Assertion:	BP1213
Description:	The envelope has no element content in the soap:Body element if the value of the parts attribute of the soapbind:body is an empty string in the corresponding doc-literal description.
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope containing a soap:Body element, and is referred by a doc-literal binding
Match:	TBD
Error Message:	The soap:Body element must be empty when, in the corresponding doc-literal description, the value of the parts attribute of soapbind:body is an empty string.
Diagnostic:	SOAP envelope

Test Assertion:	BP1214
Description:	The envelope does not contain any part accessor elements if the value of the parts attribute of the soapbind:body is an empty string in the corresponding rpc-literal description.
Prerequisite:	BP1701
Context:	For a candidate non-fault envelope containing a soap:Body element, and is referred by a rpc-literal binding
Match:	TBD
Error Message:	The content of the soap:Body element is inconsistent with its description. The envelope must not have any part accessor elements when, in the corresponding rpc-literal description, the value of the parts attribute of soapbind:body is an empty string.
Diagnostic:	SOAP envelope

Test Assertion:	BP2113
Description:	When they contain references to message parts, the soapbind:header, soapbind:headerfault and soapbind:fault elements only refer to wsdl:part element(s) that have been defined using the "element" attribute.
Prerequisite:
Context:	For a candidate wsdl:binding element
Match:	TBD
Error Message:	The soapbind:header, soapbind:headerfault or soapbind:fault elements refer to wsd:part element(s) that are not defined using only the "element" attribute.
Diagnostic:	Defective wsdl:binding and wsdl:part elements.

Test Assertion:	BP2114
Description:	Every wsdl:part from each wsdl:message in the associated wsdl:portType is referenced either by the soapbind:body, soapbind:header, soapbind:fault, or soapbind:headerfault.
Prerequisite:	BP2118
Context:	For a candidate wsdl:binding element
Match:	TBD
Error Message:	A wsdl:binding does not bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault.
Diagnostic:	{Defective wsdl:binding element}{message with part(s) unbound}

Test Assertion:	BP2115
Description:	An "element" attribute on any wsdl:part element refers to a global element declaration.
Prerequisite:
Context:	For a candidate wsdl:message
Match:	TBD
Error Message:	A wsdl:message element containing a wsdl:part element that uses the "element" attribute does not refer, via that attribute, to a global element declaration.
Diagnostic:	Defective wsdl:message element.

Test Assertion:	BP2208
Description:	The wsdl:operation element is either a WSDL request/response or a one-way operation (no Notification or Sollicit-Response).
Prerequisite:	BP2703
Context:	//wsdl:definitions/wsdl:portType/wsdl:operation
Match:	wsdl:output[position() != 1]
Error Message:	wsdl:operation was not a request/response or one-way operation.
Diagnostic:	Operation.

Test Assertion:	BP2010
Description:	name attributes of Operations are unique in the wsdl:portType definition
Prerequisite:	BP2703
Context:	//wsdl:definitions/wsdl:portType
Match:	not(wsdl:operation/@name = preceding::wsdl:portType/wsdl:operation/@name) and not(wsdl:operation/@name = following::wsdl:portType/wsdl:operation/@name)
Error Message:	name attributes are not unique within the portType definition.
Diagnostic:	list of duplicate name(s) and of elements that use them.

Test Assertion:	BP2014
Description:	The parameterOrder attribute omits at most 1 part from an output wsdl:message.
Prerequisite:
Context:	For a candidate wsdl:operation with a parameterOrder attribute, if referred to by a candidate rpc-literal wsdl:binding element
Match:	TBD
Error Message:	An operation associated with an rpc-literal binding has a parameterOrder attribute that omits more than 1 part.
Diagnostic:	{defective portType}{output wsdl:message}

Test Assertion:	BP2116
Description:	The wsdl:message element does not contain part elements that use both "type" and "element" attributes.
Prerequisite:
Context:	//wsdl:definitions/wsdl:message/wsdl:part
Match:	not(@type and @element)
Error Message:	A wsdl:message element has at least one wsdl:part element that contains both type and element attributes.
Diagnostic:	Defective wsdl:message element.

Test Assertion:	BP2402
Description:	The wsdl:binding element has a soapbind:binding child element.
Prerequisite:	BP2703
Context:	//wsdl:definitons
Match:	wsdl:binding[child::wsoap12:binding]
Error Message:	The wsdl:binding element does not use a soapbind:binding element as defined in section "3 SOAP Binding." of the WSDL 1.1 specification.
Diagnostic:	wsdl:binding.

Test Assertion:	BP2404
Description:	The contained soap:binding element has a "transport" attribute, which has value: http://schemas.xmlsoap.org/soap/http.
Prerequisite:	BP2703 BP2402
Context:	//wsdl:binding/wsoap12:binding
Match:	@transport
Error Message:	Transport attribute of the soap:binding does not contain http://schemas.xmlsoap.org/soap/http.
Diagnostic:	soap:binding element.

Test Assertion:	BP2017
Description:	The "style" attribute of each operation in the contained soap:binding has the same value of "document" or "rpc", for all operations of the wsdl:binding.
Prerequisite:	BP2404
Context:	//wsdl:binding/wsoap12:binding
Match:	@style="document" or @style="rpc"
Error Message:	The "style" attribute of an operation in soap:binding, does not have the same value of "document" or "rpc", as other operations of the binding.
Diagnostic:	defective soap:binding element.

Test Assertion:	BP2406
Description:	The use attribute has a value of "literal".
Prerequisite:	BP2703
Context:	/wsdl:binding//wsoap12:body \| //wsdl:binding//wsoap12:fault \| //wsdl:binding//wsoap12:header \| //wsdl:binding//wsoap12:headerfault
Match:	@use="literal"
Error Message:	The use attribute of a soapbind:body, soapbind:fault, soapbind:header and soapbind:headerfault does not have value of "literal".
Diagnostic:	Defective soapbind:body, soapbind:fault, soapbind:header, or soapbind:headerfault elements.

Test Assertion:	BP2998
Description:	Driver testable.
Prerequisite:
Context:	not(1)
Match:	TBD
Error Message:
Diagnostic:

Basic Profile Version 2.0

Working Group Draft

2007-10-25

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Relationships to Other Profiles

1.2 Guiding Principles

1.3 Compatibility with Basic Profile 1.1 and 1.2

1.4 Notational Conventions

1.5 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.4.2 SOAP Defined Faults Action URI

3.4.3 SOAP MustUnderstand or VersionMismatch fault Transmission

3.5 Treatment of URIs in SOAP

3.5.1 Comparison of URI values of SOAP Information Items

3.6 Support for WS-Addressing

3.6.1 Requiring WS-Addressing SOAP headers

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

3.7 Use of WS-Addressing MAPs

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

3.7.2 Understanding WS-Addressing SOAP Header Blocks

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

3.8 Use of SOAP in HTTP

3.8.1 HTTP Protocol Binding

3.8.2 Parameters on the Content-Type MIME Header

3.8.3 HTTP Success Status Codes

3.8.4 HTTP Redirect Status Codes

3.8.5 HTTP Cookies

3.8.6 Use of Non-Anonymous Reponse EPR in a Request-Response Operation

3.9 Use of URIs in SOAP

3.9.1 Use of SOAP-defined URIs

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

Test Assertion:	BP2120
Description:	Each operation referenced by the binding results in a unique wire signature.
Prerequisite:
Context:	For a candidate wsdl:binding
Match:	TBD
Error Message:	A binding has operations that are not unique.
Diagnostic:	Defective wsdl:operation element(s).

Test Assertion:	BP9992
Description:	don't know why this is listed as Not testable.
Prerequisite:
Context:	//wsdl:port
Match:	not(wsoap12:address/@location = preceding::wsdl:port/wsoap12:address/@location) and not(wsoap12:address/@location = following::wsdl:port/wsoap12:address/@location)
Error Message:
Diagnostic:

Test Assertion:	BP2019
Description:	The "namespace" attribute is not specified in any contained soapbind:body, soapbind:header, soapbind::headerfault, soapbind:fault elements
Prerequisite:	BP2406
Context:	//wsdl:binding[wsoap12:binding[@style="document"]]// wsoap12:body[@use="literal"] \| //wsdl:binding[wsoap12:binding[@style="document"]]// wsoap12:fault[@use="literal"] \| //wsdl:binding[wsoap12:binding[@style="document"]]// wsoap12:header[@use="literal"] \| //wsdl:binding[wsoap12:binding[@style="document"]]// wsoap12:headerfault[@use="literal"]
Match:	not(@namespace)
Error Message:	The binding is of style "document" and use "literal", and the "namespace" attribute is specified in some soapbind:body, soapbind:header, soapbind::headerfault, soapbind:fault element
Diagnostic:	Contained element with namespace attribute.

Test Assertion:	BP2020
Description:	The namespace attribute is specified on all soapbind:body elements and the value of the namespace attribute is an absolute URI.
Prerequisite:
Context:	//wsdl:binding[wsoap12:binding[@style="rpc"]]//wsoap12:body[@use="literal"]
Match:	@namespace
Error Message:	A soapbind:body element does not have a namespace attribute, or the namespace attribute value is not an absolute URI.
Diagnostic:	soapbind:body elements that failed the assertion

Test Assertion:	BP2117
Description:	The rpc-literal binding does not have a namespace attribute specified on a contained soapbind:header, soapbind:headerfault, and soapbind:fault element.
Prerequisite:	BP2017 BP2406
Context:	//wsdl:binding[wsoap12:binding[@style="rpc"]]// wsoap12:fault[@use="literal"] \| //wsdl:binding[wsoap12:binding[@style="rpc"]]// wsoap12:header[@use="literal"] \| //wsdl:binding[wsoap12:binding[@style="rpc"]]// wsoap12:headerfault[@use="literal"]
Match:	not(@namespace)
Error Message:	An rpc-literal binding has the namespace attribute specified on contained soapbind:header, soapbind:headerfault and soapbind:fault elements.
Diagnostic:	{Defective wsdl:binding}{defective soapbind:header, soapbind:headerfault, or soapbind:fault element}

Test Assertion:	BP2118
Description:	The list (or set) of wsdl:operation elements for the contained wsdl:binding is the same as the list of wsdl:operations for the referred wsdl:portType.
Prerequisite:
Context:	For a candidate wsdl:binding element
Match:	TBD
Error Message:	A wsdl:binding does not have the same list of wsdl:operations as the wsdl:portType to which it refers.
Diagnostic:	{unmatching wsdl:binding element}{unmatching portType element}

Test Assertion:	BP1107
Description:	The contained soap:Fault element is defined in the wsdl:binding.
Prerequisite:
Context:	For a candidate response envelope containing a soap:Fault element
Match:	TBD
Error Message:	The response envelope contained soap:Fault element(s), but they were not defined in the WSDL description.
Diagnostic:	Undefined soap:Fault element(s).

Test Assertion:	BP2021
Description:	The wsdl:input element and wsdl:output element of each operation uses the attribute name "part" with a Schema type of "NMTOKEN" and does not use "parts", for both soapbind:header elements and soapbind:headerfault elements.
Prerequisite:	BP2703
Context:	//wsdl:binding//wsoap12:header \| //wsdl:binding//wsoap12:headerfault
Match:	@part
Error Message:	The wsdl:input element or wsdl:output element of an operation does not use the attribute name "part" with a Schema type of "NMTOKEN" for soapbind:header elements or soapbind:headerfault elements, or it uses "parts".
Diagnostic:	wsdl:input element or wsdl:output element of the defective operation.

Test Assertion:	BP2022
Description:	the name attribute is specified on the soapbind:fault element.
Prerequisite:
Context:	//wsdl:binding//wsoap12:fault
Match:	@name
Error Message:	Defective soapbind:fault element: the name attribute is not specified on the soapbind:fault element.
Diagnostic:	Defective soapbind:fault element

Test Assertion:	BP2032
Description:	the name attribute that is specified on the soapbind:fault element matches the value specified on the parent element wsdl:fault.
Prerequisite:
Context:	//wsdl:binding//wsoap12:fault
Match:	@name=../@name
Error Message:	Defective soapbind:fault element: the "name" attribute value does not match the value of the "name" attribute on the parent element wsdl:fault.
Diagnostic:	Defective soapbind:fault element