Basic Profile - Version 1.0 (BdAD)

This document defines the WS-I Basic Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.

Status of this Document

This is a final specification. Readers should refer to the WS-I.org web site for errata and updates..

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

If there are areas in this specification that could be clearer, or if errors or omissions are identified, WS-I would like to be notified in order to provide the best possible interoperability guidance.

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 1.0 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications which promote interoperability.

Section 1 introduces the Profile, and relates the philosophy that it takes with regard to interoperability.

Section 2, "Scope of the Profile," delimits the areas where the Profile improves interoperability.

Section 3, "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 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.2 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 in the Profile (i.e., those impacting conformance, as outlined in "Profile Conformance") are presented in the following manner:

where "nnnn" is replaced by the statement number. Each statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE").

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

Some statements 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., "SOAP12" for SOAP Version 1.2, currently under development). Note that because such work is not complete, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

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.

2. Scope of the Profile

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. Initially, the Profile's scope is bounded by the specifications referenced by it; for a complete list of the Profile's referenced specifications, see Appendix I.

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 as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use is not subject to claims of conformance to this 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.

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

3. Profile Conformance

Conformance to the Profile is defined by adherence to the set of requirements for a specific target, within the scope of the Profile.

The scope of the Profile is defined above ("Scope of the Profile"); conformance to the Profile is dependent upon conformance to those referenced specifications that are in-scope, except when in conflict with the Profile's Requirements, which take precedence for purposes of conformance.

Requirements state the criteria for conformance to the Profile within its stated scope. They embody refinements, interpretations and clarifications that improve interoperability therein. 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.

Additional text may be included in the Profile to illuminate requirements (e.g., rationale and examples); however, requirement statements alone should be considered in determining conformance.

Targets allow for the description of conformance in different contexts, to allow conformance testing and certification of artifacts (such as SOAP messages and WSDL descriptions), Web service instances, and Web service consumers. The sections below describe the Profile's conformance targets.

To allow services to advertise conformance to the Profile, messages, descriptions and registry data can be annotated with conformance claims, which use a URI to assert conformance with a particular profile.

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

3.1 Conformance of Artifacts

The most basic level of conformance is that of an artifact. The Profile makes requirement statements about three kinds of artifacts:

An instance of an artifact is considered conformant when all of the requirements associated with it are met.

3.2 Conformance of Services, Consumers and Registries

A deployed instance of a Web service (as specified by wsdl:port or uddi:bindingTemplate) is considered conformant if it produces only conformant artifacts, and is capable of consuming conformant artifacts, as appropriate. Note that this means that where multiple conformant artifacts are possible, a conformant service must be able to consume them all (e.g., while a sender might choose whether to encode XML in UTF-8 or UTF-16 when sending a message, a receiver must be capable of using either).

Similarly, a consumer of a service instance is considered conformant if it produces only conformant artifacts and is capable of consuming conformant artifacts, as appropriate.

Finally, a registry is considered conformant if it satisfies the profile requirements for the target REGISTRY.

Conformant Web service instances must comply with all requirement statements associated with INSTANCE.

Likewise, conformant consumers must comply with all requirements statements associated with CONSUMER.

Both conformant Web service instances and consumers must comply, as appropriate, with all of the requirement statements associated with:

Note that conformance does not apply to a service as a whole; only ports are considered when determining conformance of instances. Therefore, the Profile places no constraints on wsdl:service definitions. In particular, they can contain multiple


					wsdl:port

elements, each of which may or may not be conformant.

Types of Web services (as described by wsdl:binding and wsdl:portType) are considered conformant if, when properly implemented and deployed in the environment in which they were intended to operate, they result in conformant instances.

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

R0001 An INSTANCE MUST be described by a WSDL 1.1 service description, by a UDDI binding template, or both.

"described," in this context, 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.

3.3 Conformance Annotation in Descriptions

Conformance claims can be associated with a particular WSDL element (e.g., wsdl:portType) to scope them to that construct.

R0002 A DESCRIPTION MAY contain conformance claims regarding instances, as specified in the conformance claim schema.

R0003 A DESCRIPTION's conformance claims MUST be children of the wsdl:documentation element of each of the elements: wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation (as a child element of wsdl:portType but not of wsdl:binding) and wsdl:message.

A conformance claim on an element means that the element (and the instance it represents, in the case of a port) is conformant to the requirements of the Profile it claims to obey that are relevant for this type of element.

A conformance claim on an element also implies that the same claim is made for all the elements that it uses, based on the following transitivity rules, applied recursively:

A claim on a wsdl:port is inherited by the referenced wsdl:binding
A claim on a wsdl:binding is inherited by the referenced wsdl:portType
A claim on a wsdl:portType is inherited by the referenced wsdl:operations
A claim on a wsdl:operation is inherited by the referenced wsdl:messages of its child wsdl:output and/or wsdl:input

The conformance claim schema is:

<?xml version="1.0" encoding="UTF-8" ?> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  targetNamespace="http://ws-i.org/schemas/conformanceClaim/"
  xmlns:tns="http://ws-i.org/schemas/conformanceClaim/" 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
  elementFormDefault="qualified" 
  attributeFormDefault="unqualified" > 

  <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" 
    schemaLocation="http://schemas.xmlsoap.org/soap/envelope/" />

  <xsd:element name="Claim" > 
    <xsd:complexType> 
      <xsd:sequence> 
        <xsd:any namespace="##any" processContents="lax" 
         minOccurs="0" maxOccurs="unbounded" /> 
      </xsd:sequence> 
      <xsd:attribute name="conformsTo" type="xsd:anyURI" use="required"/> 
      <xsd:attribute ref="soap:mustUnderstand" use="prohibited" />
      <xsd:anyAttribute namespace="##any" processContents="lax"/> 
    </xsd:complexType> 
  </xsd:element> 

</xsd:schema>

CORRECT:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" 
  xmlns:tns="http://example.org/myservice"
  xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
  xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
  targetNamespace="http://example.org/myservice"> 
  <wsdl:portType name="MyPortType"> 
      ... 
  </wsdl:portType> 
  <wsdl:binding name="MyBinding" portType="MyPortType" > 
      ... 
  </wsdl:binding> 
  <wsdl:service name="MyService" > 
    <wsdl:port name="MyPort" binding="tns:MyBinding" > 
      <wsdl:documentation>
        <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
      </wsdl:documentation>
      <soapbind:address location="http://example.org/myservice/myport" />
    </wsdl:port> 
  </wsdl:service> 
</wsdl:definitions>

3.4 Conformance Annotation in Messages

As new versions of the Profile as well as other profiles are released, it is possible for a service to support multiple profiles. When receiving a message, the service may want to be able to determine the profile to which this message conforms. To allow SOAP messages to indicate the profiles they conform to, WS-I prescribes use of the wsi:Claim element as a SOAP header.

R0004 A MESSAGE MAY contain conformance claims, as specified in the conformance claim schema.

R0005 A MESSAGE's conformance claims MUST be carried as SOAP header blocks.

R0006 A MESSAGE MAY contain conformance claims for more than one profile.

R0007 A SENDER MUST NOT use the soap:mustUnderstand attribute when sending a SOAP header block containing a conformance claim.

A SOAP message may contain conformance claims, carried as SOAP header blocks, indicating to the recipient that the sender claims that the message conforms to one or more profiles. Absence of a conformance claim in a message must not be construed as implying that the message does or does not conform to one or more profiles. Also, conformance claim header blocks are considered informative and therefore must not be mandatory header blocks. The Profile therefore prevents the use of soap:mustUnderstand attribute on the conformance claim header block.

CORRECT:

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
  <soap:Header>
    <!-- other headers -->
    <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" 
     xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
    <!-- other headers -->
  </soap:Header>
  <soap:Body>
    <!-- body content -->
  </soap:Body>
</soap:Envelope>

3.5 Conformance Annotation in Registry Data

In the same way that it is useful to annotate various elements of descriptions with profile conformance claims, is it useful to do so for uddi:tModel elements. The natural mechanism in UDDI for adding attributes to a uddi:tModel is to define and use a category system. The Profile adopts this mechanism to add the ability for uddi:tModels to assert conformance with WS-I Profiles, and with the Profile in particular.

R3020 REGDATA of type uddi:tModel claiming conformance with a Profile MUST be categorized using the ws-i-org:conformsTo:2002_12 taxonomy.

R3030 REGDATA of type uddi:tModel claiming conformance with a Profile MUST use the ws-i-org:conformsTo:2002_12 categorization value corresponding to the conformance claim URI for that Profile.

R3021 A REGISTRY MUST support the WS-I Conformance category system by adding the ws-i-org:conformsTo:2002_12 tModel definition to its registry content.

The content of the tModel for the ws-i-org:conformsTo:2002_12 tModel is as follows:

<tModel tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0"> 
  <name>ws-i-org:conformsTo:2002_12</name> 
  <description xml:lang="EN">Category system used for UDDI entities 
  to point to the WS-I concept to which they conform to</description> 
  <overviewDoc> 
    <overviewURL>http://ws-i.org/schemas/conformanceClaim/</overviewURL> 
  </overviewDoc> 
  <categoryBag> 
  <keyedReference 
    keyName="uddi-org:types:categorization" 
    keyValue="categorization"
    tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" /> 
  </categoryBag> 
</tModel>

CORRECT:

<tModel tModelKey="...">
   <name>BarSOAPService</name>
   <description xml:lang="EN">Bar's SOAP Service</description>
   <overviewDoc>...</overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0"
         keyName="ws-I_conformance:BasicProfile1.0"
         keyValue="http://ws-i.org/profiles/basic/1.0" />
   </categoryBag>

Since wsdl:service elements are not necessarily mapped to a single uddi:businessService and are also not subject to conformance claims, it would be unclear what it meant if a uddi:businessEntity or a uddi:businessService element were to claim conformance with the Profile. Also, uddi:bindingTemplate elements can't be categorized because the UDDI V2 XML Schema does not provide a uddi:categoryBag for them. Hence, the conformance claim made by wsdl:port elements can't be documented in the corresponding uddi:bindingTemplate.

R3005 REGDATA other than uddi:tModel elements representing conformant Web service types MUST NOT be categorized using the ws-i-org:conformsTo:2002_12 taxonomy and a categorization of "http://ws-i.org/profiles/basic/1.0".

It would be ambiguous if the conformance claim a uddi:tModel made were not consistent with the claim made by the wsdl:binding it uses.

R3004 REGDATA of type uddi:tModel MUST be constructed so that the conformance claim it makes is consistent with the conformance claim made by the wsdl:binding to which it refers.

4. Messaging

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

4.1 XML Representation of SOAP Messages

The following specifications (or sections thereof) are referred to in this section of the Profile;

SOAP 1.1 defines an XML-based structure for transmitting messages. The Profile mandates the use of that structure, and places the following constraints on its use:

4.1.1 SOAP Messages and the Unicode BOM

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

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

4.1.2 SOAP Fault Syntax

A SOAP Fault is a SOAP message that has a single child element of the soap:Body element, that element being a soap:Fault element. The Profile restricts the content of the soap:Fault element to those elements explicitly described in SOAP 1.1.

R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor and detail.

INCORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the message 
  that I did not understand
  </detail>
  <m:Exception xmlns:m='http://example.org/faults/exceptions' >
    <m:ExceptionType>Severe</m:ExceptionType>
  </m:Exception>
</soap:Fault>

CORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
     <m:msg xmlns:m='http://example.org/faults/exceptions'>
         There were <b>lots</b> of elements in the message that I did not understand
     </m:msg>
     <m:Exception xmlns:m='http://example.org/faults/exceptions'>
       <m:ExceptionType>Severe</m:ExceptionType>
     </m:Exception>
   </detail>
</soap:Fault>

4.1.3 SOAP Faults and Namespaces

The children of the soap:Fault element are local to that element, therefore namespace qualification is unnecessary.

R1001 When a MESSAGE contains a soap:Fault element its element children MUST be unqualified.

INCORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:faultcode>soap:Client</soap:faultcode>
  <soap:faultstring>Invalid message format</soap:faultstring>
  <soap:faultactor>http://example.org/someactor</soap:faultactor>
  <soap:detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that 
          I did not understand
      </m:msg>
  </soap:detail>
</soap:Fault>

CORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' 
			xmlns='' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that 
          I did not understand
      </m:msg>
  </detail>
</soap:Fault>

4.1.4 SOAP Fault Extensibility

For extensibility, additional attributes are allowed to appear on the detail element and additional elements are allowed to appear as children of the detail element.

R1002 A RECEIVER MUST accept fault messages that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified.

R1003 A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than "http://schemas.xmlsoap.org/soap/envelope/".

4.1.5 SOAP Fault Language

Faultstrings are human-readable indications of the nature of a Fault. As such, they may not be in a particular language, and therefore xml:lang can be used to indicate the language of the faultstring.

R1016 A RECEIVER MUST accept fault messages that carry an xml:lang attribute on the faultstring element.

4.1.6 SOAP Custom Fault Codes

SOAP 1.1 allows custom fault codes to appear inside the faultcode element, through the use of the "dot" notation.

Use of this mechanism to extend the meaning of the SOAP 1.1-defined fault codes can lead to namespace collision. Therefore, its use should be avoided, as doing so may cause interoperability issues when the same names are used in the right-hand side of the "." (dot) to convey different meaning.

Instead, the Profile encourages the use of the fault codes defined in SOAP 1.1, along with additional information in the detail element to convey the nature of the Fault.

Alternatively, it is acceptable to define custom fault codes in a namespace controlled by the specifying authority.

A number of specifications have already defined custom fault codes using the "." (dot) notation. Despite this, their use in future specifications is discouraged.

R1004 When a MESSAGE contains a faultcode element the content of that element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace qualified fault code.

R1031 When a MESSAGE contains a faultcode element the content of that element SHOULD NOT use of the SOAP 1.1 "dot" notation to refine the meaning of the Fault.

It is recommended that applications that require custom fault codes either use the SOAP1.1 defined fault codes and supply additional information in the detail element, or that they define these codes in a namespace that is controlled by the specifying authority.

INCORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>soap:Server.ProcessingError</faultcode>
  <faultstring>An error occurred while processing the message
  </faultstring>
</soap:Fault>

CORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

CORRECT:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Server</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

4.1.7 SOAP encodingStyle Attribute

The soap:encodingStyle attribute is used to indicate the use of a particular scheme in the encoding of data into XML. However, this introduces complexity, as this function can also be served by the use of XML Namespaces. As a result, the Profile prefers the use of literal, non-encoded XML.

R1005 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/envelope/".

R1006 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.

R1007 A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements are grandchildren of soap:Body.

4.1.8 SOAP's use of XML

XML DTDs and PIs may introduce security vulnerabilities, processing overhead and ambiguity in message semantics when used in SOAP messages. As a result, these XML constructs are disallowed by section 3 of SOAP 1.1.

R1008 A MESSAGE MUST NOT contain a Document Type Declaration. C

R1009 A MESSAGE MUST NOT contain Processing Instructions. C

4.1.9 SOAP and 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 that contain an XML Declaration. C

4.1.10 SOAP Trailers

The interpretation of sibling elements following the soap:Body element is unclear. Therefore, such elements are disallowed.

R1011 A MESSAGE MUST NOT have any element children of soap:Envelope following the soap:Body element.

This requirement clarifies a mismatch between the SOAP 1.1 specification and the SOAP 1.1 XML Schema.

INCORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' />
  </soap:Body>
  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
  </m:Data>
</soap:Envelope>

CORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' >
	  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
      </m:Data>
    </p:Process>
  </soap:Body>
</soap:Envelope>

4.1.11 Acceptable SOAP Character Encodings

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

As a consequence of this, in conjunction with SOAP 1.1's requirement to use the text/xml media type (which has a default character encoding of "us-ascii"), the charset parameter must always be present on the SOAP envelope's media type. A further consequence of this is that the encoding pseudo-attribute of XML declaration within the message is always ignored, in accordance with the requirements of both XML 1.0 and RFC3023, "XML Media Types".

R1012 A MESSAGE MUST be serialized as either UTF-8 or UTF-16.

R1018 The media type of a MESSAGE's envelope MUST indicate the correct character encoding, using the charset parameter. C

When SOAP is used with the HTTP binding, the media type is carried in the Content-Type HTTP header field.

4.1.12 SOAP mustUnderstand Attribute

The soap:mustUnderstand attribute has a restricted type of "xsd:boolean" that takes only "0" or "1". Therefore, only those two values are allowed.

R1013 A MESSAGE containing a soap:mustUnderstand attribute MUST only use the lexical forms "0" and "1". C

4.1.13 SOAP Body and Namespaces

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 a MESSAGE MUST be namespace qualified.

4.1.14 SOAP Envelope Namespace

SOAP 1.1 states that a message with an Envelope element with a namespace name other than "http://schemas.xmlsoap.org/soap/envelope/" should be discarded. The Profile requires that a Fault be generated instead, to assure unambiguous operation.

R1015 A RECEIVER MUST generate a fault if they encounter a message whose document element has a local name of "Envelope" but a namespace name that is not "http://schemas.xmlsoap.org/soap/envelope/".

4.1.15 Use of xsi:type Attributes

In many cases, senders and receivers will share some form of type information related to the messages being exchanged. The xsi:type attribute is only needed where no such schema exists, that is where both sides are assuming that all exchanged items are "xsd:anyType".

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

4.2 SOAP Processing Model

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

4.2.1 Mandatory Headers

SOAP 1.1's processing model is underspecified with respect to the processing of mandatory header blocks. Mandatory header blocks are those children of the soap:Header element bearing a soap:mustUnderstand attribute with a value of "1".

R1025 A RECEIVER MUST handle messages in such a way that it appears that all checking of mandatory header blocks is performed before any actual processing. SOAP12

This requirement guarantees that no undesirable side effects will occur as a result of noticing a mandatory header block after processing other parts of the message.

4.2.2 Generating mustUnderstand Faults

The Profile requires that receivers generate a Fault when they encounter header blocks that they do not understand targeted at them.

R1027 A RECEIVER MUST generate a "soap:MustUnderstand" fault when a message contains a mandatory header block (i.e., one that has a soap:mustUnderstand attribute with the value "1") targeted at the receiver (via soap:actor) that the receiver does not understand.

4.2.3 SOAP Fault Processing

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 message, and some application level error will be flagged to the user.

R1028 When a Fault is generated by a RECEIVER, further processing SHOULD NOT be performed on the SOAP message aside from that which is necessary to rollback, or compensate for, any effects of processing the message prior to the generation of the Fault.

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

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

4.3 Use of SOAP in HTTP

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

4.3.1 HTTP Versions

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

R1140 A MESSAGE SHOULD be sent using HTTP/1.1.

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

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

4.3.2 Identifying SOAP Faults

Some consumer implementations use only the HTTP status code to determine the presence of a SOAP 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.

R1107 A RECEIVER MUST interpret SOAP messages containing only a soap:Fault element as a Fault.

4.3.3 HTTP Methods and Extensions

The SOAP1.1 specification defined its HTTP binding such that two possible methods could be used, the HTTP POST method and the HTTP Extension Framework's M-POST method. The Profile requires that only the HTTP POST method be used and precludes use of the HTTP Extension Framework.

R1132 A HTTP request MESSAGE MUST use the HTTP POST method.

R1108 A MESSAGE MUST NOT use the HTTP Extension Framework (RFC2774).

The HTTP Extension Framework is an experimental mechanism for extending HTTP in a modular fashion. Because it is not deployed widely and also because its benefits to the use of SOAP are questionable, the Profile does not allow its use.

4.3.4 SOAPAction Header Syntax

Testing has demonstrated that requiring the SOAPAction HTTP 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.

SOAPAction is purely a hint to processors. All vital information regarding the intent of a message is carried in soap:Envelope.

R1109 The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string. C

R1119 A RECEIVER MAY respond with a Fault if the value of the SOAPAction HTTP header field is not quoted. C

CORRECT:

A WSDL Description that has:

<soapbind:operation soapAction="foo" />

results in a message with a SOAPAction HTTP header field of:

SOAPAction: "foo"

CORRECT:

A WSDL Description that has:

<soapbind:operation />

<soapbind:operation soapAction="" />

results in a message with a corresponding SOAPAction HTTP header field as follows:

SOAPAction: ""

4.3.5 HTTP and TCP Ports

SOAP is designed to take advantage of the HTTP infrastructure. However, there are some situations (e.g., involving proxies, firewalls and other intermediaries) where there may be harmful side effects. As a result, instances may find it advisable to use ports other than the default for HTTP (port 80).

R1110 An INSTANCE MAY accept connections on TCP port 80 (HTTP). C

There has been considerable debate within the W3C and IETF regarding the propriety of the use of port 80 for SOAP messages bound to HTTP. It has been concluded that this is an acceptable practice.

4.3.6 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 for responses that indicate a successful outcome of a request.

R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code for responses that contain a SOAP message that is not a SOAP fault.

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

4.3.7 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 HTTP status code "307 Temporary Redirect" when redirecting a request to a different endpoint.

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

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.

4.3.8 HTTP Client Error Status Codes

HTTP uses the 4xx series of status codes to indicate failure due to a client error. Although there are a number of situations that may result in one of these codes, the Profile highlights those when the payload of the HTTP request is not the proper media type (i.e., "text/xml", as required by the SOAP/HTTP binding), and when the anticipated method ("POST") is not used.

R1125 An INSTANCE MUST use a 4xx HTTP status code for responses that indicate a problem with the format of the request.

R1113 An INSTANCE SHOULD use a "400 Bad Request "HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

R1114 An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST".

R1115 An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if the Content-Type HTTP request header did not have a value consistent with the value specified for the corresponding binding of the input message.

Note that these requirements do not force an instance to respond to requests. In some cases, such as Denial of Service attacks, an instance may choose to ignore requests.

4.3.9 HTTP Server Error Status Codes

HTTP uses the 5xx series of status codes to indicate failure due to a server error.

R1126 An INSTANCE MUST use a "500 Internal Server Error" HTTP status code if the response message is a SOAP Fault.

4.3.10 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 SOAP Envelope, are not accommodated by either SOAP 1.1 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").

R1122 An INSTANCE using Cookies SHOULD conform to RFC2965.

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

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

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

5. 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;

5.1 Document Structure

The following specifications (or sections thereof) are referred to in this section of the Profile;

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:

5.1.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://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".

R2029 A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at "http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

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.

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

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

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

R2004 A DESCRIPTION MUST NOT use the XML Schema "import" statement to import a Schema from any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema".

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

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

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

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">
      <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>

5.1.3 WSDL Import location Attribute Syntax

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.

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.

5.1.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 In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint. C

This means that WSDL processor may, but need not, retrieve a WSDL description from the URI specified in the location attribute on a wsdl:import element because a WSDL processor may have other ways of locating a WSDL description for a given namespace. For example, it may already have a cached or built-in representation, or it may retrieve a representation from a metadata repository or UDDI server.

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

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.

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>

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

5.1.7 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

5.1.8 Acceptable WSDL Character Encodings

The Profile consistently requires either UTF-8 or UTF-16 encoding for both SOAP and WSDL (see also R1012).

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

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

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

R2020 The wsdl:documentation element MAY occur as a child of the wsdl:import element in a DESCRIPTION. WSDL12

R2021 The wsdl:documentation element MAY occur as a child of the wsdl:part element in a DESCRIPTION. WSDL12

R2024 The wsdl:documentation element MAY occur as a first child of the wsdl:definitions element in a DESCRIPTION. WSDL12

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

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.

R2027 If during the processing of an element in the WSDL namespace in a description, a consumer encounters a WSDL extension element amongst its element children, 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 of that element in the WSDL namespace.

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.

The following elements are extensible via attributes only:

wsdl:import
wsdl:part
wsdl:portType
wsdl:input (in portType operation)
wsdl:output (in portType operation)
wsdl:fault (in portType operation)

The following elements are extensible via elements as well as attributes:

wsdl:definitions
wsdl:types
wsdl:message
wsdl:operation
wsdl:binding
wsdl:input (in binding operation)
wsdl:output (in binding operation)
wsdl:fault (in binding operation)
wsdl:service
wsdl:port

5.2 Types

The following specifications (or sections thereof) are referred to in this section of the Profile;

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:

5.2.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. Similar to XML Schema, namespaces not referenced directly within the WSDL file (through the targetNamespace attribute on xsd:schema, or through the namespace attribute on xsd:import) are available for use in QName reference. QName references to namespaces that are only defined through a nested import are not allowed.

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

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.

5.2.2 Schema targetNamespace Syntax

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

5.2.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, array declarations MUST NOT extend or restrict the soapenc:Array type.

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

R2112 In a DESCRIPTION, array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX.

R2113 A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute.

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 SOAP message 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 SOAP message would serialize as (omitting namespace declarations for clarity):

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

5.2.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.WSDL12

5.3 Messages

The following specifications (or sections thereof) are referred to in this section of the Profile;

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 wire format. 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.

An "rpc-literal binding" is a wsdl:binding element whose child wsdl:operation elements are all rpc-literal operations.

An "rpc-literal operation" is a wsdl:operation child element of wsdl:binding each of whose soapbind:body descendant elements specifies the use attribute with the value "literal" and each of which either:

A "document-literal binding" is a wsdl:binding element whose child wsdl:operation elements are all document-literal operations.

A "document-literal operation" is a wsdl:operation child element of wsdl:binding each of whose soapbind:body descendent elements specifies the use attribute with the value "literal" and each of which either:

5.3.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 soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

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

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

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

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

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

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

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

Use of wsdl:message elements with zero parts is permitted in Document styles to permit operations that can send or receive messages with empty soap:Bodys. 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 wire representation of that part 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".

5.3.2 Bindings and Faults

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

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

Because faults and headers do not contain parameters, soapbind:fault, soapbind:header and soapbind: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 soapbind:body be defined using the element attribute. This requirement does the same for soapbind:fault, soapbind:header and soapbind:headerfault elements.

5.3.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 soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault.

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 soapbind:body or soapbind:header (and so forth) as appropriate when using the SOAP binding as defined in WSDL 1.1 Section 3.

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

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>

5.4 Port Types

The following specifications (or sections thereof) are referred to in this section of the Profile;

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):

5.4.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 a MESSAGE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it.

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.

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

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

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

5.4.4 parameterOrder Attribute Construction

WSDL 1.1 does not clearly state how the parameterOrder attribute of the wsdl:portType should be constructed.

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

If a wsdl:part from the output message is omitted from the list of wsdl:parts 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.

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

5.5 Bindings

The following specifications (or sections thereof) are referred to in this section of the Profile;

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:

5.5.1 Use of SOAP Binding

The Profile limits the choice of bindings to the well defined and most commonly used SOAP binding. MIME and HTTP GET/POST bindings are not permitted by the Profile.

R2401 A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

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.

5.6 SOAP Binding

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

Basic Profile Version 1.0a

Final Specification

Date: 2003/08/08 17:00:01

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Guiding Principles

1.2 Notational Conventions

2. Scope of the Profile

3. Profile Conformance

3.1 Conformance of Artifacts

3.2 Conformance of Services, Consumers and Registries

3.3 Conformance Annotation in Descriptions

3.4 Conformance Annotation in Messages

3.5 Conformance Annotation in Registry Data

4. Messaging

4.1 XML Representation of SOAP Messages

4.1.1 SOAP Messages and the Unicode BOM

4.1.2 SOAP Fault Syntax

4.1.3 SOAP Faults and Namespaces

4.1.4 SOAP Fault Extensibility

4.1.5 SOAP Fault Language

4.1.6 SOAP Custom Fault Codes

4.1.7 SOAP encodingStyle Attribute

4.1.8 SOAP's use of XML

4.1.9 SOAP and XML Declarations

4.1.10 SOAP Trailers

4.1.11 Acceptable SOAP Character Encodings

4.1.12 SOAP mustUnderstand Attribute

4.1.13 SOAP Body and Namespaces

4.1.14 SOAP Envelope Namespace

4.1.15 Use of xsi:type Attributes

4.2 SOAP Processing Model

4.2.1 Mandatory Headers

4.2.2 Generating mustUnderstand Faults

4.2.3 SOAP Fault Processing

4.3 Use of SOAP in HTTP

4.3.1 HTTP Versions

4.3.2 Identifying SOAP Faults

4.3.3 HTTP Methods and Extensions

4.3.4 SOAPAction Header Syntax

4.3.5 HTTP and TCP Ports

4.3.6 HTTP Success Status Codes

4.3.7 HTTP Redirect Status Codes

4.3.8 HTTP Client Error Status Codes

4.3.9 HTTP Server Error Status Codes

4.3.10 HTTP Cookies

5. Service Description

5.1 Document Structure

5.1.1 WSDL Schema Definitions

5.1.2 WSDL and Schema Import

5.1.3 WSDL Import location Attribute Syntax

5.1.4 WSDL Import location Attribute Semantics

5.1.5 Placement of WSDL import Elements

5.1.6 XML Version Requirements

5.1.7 WSDL and the Unicode BOM

5.1.8 Acceptable WSDL Character Encodings

5.1.9 Namespace Coercion

5.1.10 WSDL documentation Element

5.1.11 WSDL Extensions

5.2 Types

5.2.1 QName References

5.2.2 Schema targetNamespace Syntax

5.2.3 soapenc:Array

5.2.4 WSDL and Schema Definition Target Namespaces

5.3 Messages

5.3.1 Bindings and Parts

5.3.2 Bindings and Faults

5.3.3 Unbound portType Element Contents

5.3.4 Declaration of part Elements

5.4 Port Types

5.4.1 Ordering of part Elements

5.4.2 Allowed Operations

5.4.3 Distinctive Operations

5.4.4 parameterOrder Attribute Construction

5.4.5 Exclusivity of type and element Attributes

5.5 Bindings