Basic Profile Version 1.1

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

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

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

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

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>

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.

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

In many cases, senders and receivers will share some form of type information related to the envelopes 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".

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

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.

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

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.

A fault is an envelope 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.

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>

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

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>

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.

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

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.

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>

Some consumer implementations 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.

Several versions of HTTP are defined. HTTP/1.1 has performance advantages, and is more clearly specified than 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."

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.

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.

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.

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

or

<soapbind:operation soapAction="" />

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

SOAPAction: ""

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

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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.

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.

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.

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>

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.

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.

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.

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.

Example 3 in WSDL 1.1 Section 3.1 causes confusion regarding the placement of 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>

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.

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.

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

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

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

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.

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

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.

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.

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.

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>

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

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.

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

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

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.

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.

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.

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.

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>

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

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

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

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.

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

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.

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.

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

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.

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.

The profile limits the underlying transport protocol to HTTP.

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

The style, "document" or "rpc", of an interaction is specified at the wsdl:operation level, permitting wsdl:bindings whose wsdl:operations have different styles. This has led to interoperability problems.

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

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

The Profile explicitly permits multiple bindings for the same portType.

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

The Profile defines the "wire signature" of an operation in a wsdl:binding to be the fully qualified name of the child element of the soap:Body of the SOAP input message it describes. For the case of an empty soap:Body this name is an empty string.

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.

When input messages destined for two different wsdl:ports 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.

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

There are differing interpretations of how HTTP is to be used when performing one-way operations.

One-way operations do not produce SOAP responses. Therefore, the Profile prohibits sending a SOAP envelope in response to a one-way operation. This means that transmission of one-way operations can not result in processing level responses or errors. For example, a "500 Internal Server Error" HTTP response that contains a fault can not be returned in this situation.

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.

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.

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.

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 soapbind: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 soapbind: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.

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

There is inconsistency between WSDL specification text and the WSDL schema regarding soapbind:headerfaults.

The WSDL 1.1 schema makes the specification of soapbind:headerfault element mandatory on wsdl:input and wsdl:output elements of an operation, whereas the WSDL 1.1 specification marks them optional. The specification is correct.

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.

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

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

CORRECT:

<binding name="StockQuoteSoap" type="tns:StockQuotePortType">

  <soapbind:binding style="document"

                transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="SubscribeToQuotes">

      <input message="tns:SubscribeToQuotes">

        <soapbind:body parts="body" use="literal"/>

        <soapbind:header message="tns:SubscribeToQuotes"

                       part="subscribeheader" use="literal"/>

     </input>

   </operation>

</binding>

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

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

WSDL 1.1 Section 3.6 indicates that the use attribute of soapbind:fault is required while in the schema the use attribute is defined as optional. The Profile defines it as optional, to be consistent with soapbind: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".

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.

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.

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.

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.

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.

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:soapbind="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="BarSOAPBinding" type="bar:BarPortType">

   <soapbind:binding

    transport="http://schemas.xmlsoap.org/soap/http/"

    style="rpc"/>

   <operation name="BarOperation">

     <input message="bar:BarMsg">

       <soapbind:body use="literal" namespace="http://example.org/bar/"/>

     </input>

   </operation>

</binding>

<service name="serviceName">

  <port name="BarSOAPPort" binding="bar:BarSOAPBinding">

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

WSDL 1.1 does not clearly specify whether all soapbind:headers 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.

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.

There is no correlation between the order of soapbind:headers 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.

Interoperability testing has demonstrated that requiring the SOAPAction HTTP header field-value to be quoted increases interoperability of implementations. Even though HTTP allows for header field-values to be unquoted, some implementations require that the value be quoted.

The SOAPAction header is purely a hint to processors. All vital information regarding the intent of a message is carried in the envelope.

See also R1119 and related requirements for more discussion of SOAPAction.

CORRECT:

A WSDL Description that has:

<soapbind:operation soapAction="foo" />

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

SOAPAction: "foo"

CORRECT:

A WSDL Description that has:

<soapbind:operation />

or

<soapbind:operation soapAction="" />

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

SOAPAction: ""

The wsdl:required attribute has been widely misunderstood and used by WSDL authors sometimes to incorrectly indicate the optionality of soapbind:headers. The wsdl:required attribute, as specified in WSDL1.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 soapbind: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 soapbind:header element, the WSDL processor MUST understand the semantic implied by the soapbind: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 SOAP 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.

WSDL's soapbind: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.

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>

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

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

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:bindings in a WSDL document. The UDDI Best Practice for Using WSDL in a UDDI Registry specifies the most widely recognized such convention.

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

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

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.