Web Services Description Language (WSDL) Version 1.2

1.1 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 RFC 2119 [IETF RFC 2119].

This specification uses namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML Information Set]).

Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [IETF RFC 2396].

All parts of this specification are normative, with the exception of examples and sections explicitly marked as "Non-Normative".

2.1 Type Description Component

The type description component is where data types are defined. WSDL does not define its own data typing language. Instead, it defers that task to existing type languages such as XML Schema [XML Schema: Datatypes] and provides a mechanism to "host" any number of type definitions from such languages. A type description component MUST contain at least one set of type definitions so that those can be referred to from other parts of WSDL.

WSDL recognizes that using XML Schema [XML Schema: Datatypes] as the type system language will result in maximal interoperability of Web services described in WSDL. Thus, it is RECOMMENDED that the XML Schema type system be used to describe messages exchanged between Web services whenever possible.

2.2 Message Description Components

A message description component is used to model messages exchanged between Web services. A message description component defines logically a "type" of a message which MAY be used to define the input, output or fault message of an operation of a portType description component (see 2.3 PortType Description Component).

A message description component has a REQUIRED "name" property which must be unique across all message description components defined in the same target namespace as this message description component. Thus, the qualified name formed by the value of the targetNamespace property and the name property uniquely identifies the message description component.

A message description component contains zero or more descriptions of "parts" of messages, where a message part is considered an atomic entity from WSDL's point of view. A part has a REQUIRED "name" property which must be unique within the message description component only. Additionally, the "type" of data that the part represents MUST be described using a mechanism specific to the type system in use (see 2.1 Type Description Component).

Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format. However, in some cases, the abstract definition may match the concrete representation very closely or exactly for one or more bindings, so those binding(s) will supply little or no mapping information. However, another binding of the same message definition may require extensive mapping information. For this reason, it is not until the binding is inspected that one can determine "how abstract" the message really is.

WSDL makes special recognition of the XML Schema language as a RECOMMENDED type specification language (see 2.1 Type Description Component). A part MAY indicate its XML Schema nature using either the "type" or "element" property of a part description. The value of the "type" property MUST be a qualified name referring to a complex or simple type defined in some namespace. Similarly, the value of the "element" property MUST be a qualified name referring to a global element declaration in some namespace.

If a type system other than XML Schema is used, then a new property MUST be introduced to the part description to refer to types from that type system.

2.3 PortType Description Component

A portType description component adheres to the semantics commonly associated with an "interface." A portType description component contains one or more descriptions of operations offered by the service.

A portType description component has a REQUIRED "name" property which, along with its targetNamespace property uniquely identifies the portType description component.

An operation description has a REQUIRED "name" property, which must be unique within the names of all operations in this portType description component only.

An operation description has an OPTIONAL "documentation" property. The value of this property is arbitrary and SHOULD be used to provide human or machine processable documentation about the operation.

An operation MAY have an input message property, which refers to the qualified name of a message description component.

An operation MAY have an output message property, which similarly refers to the qualified name of a message description component.

An operation MAY have zero or more fault message properties, each of refers to the qualified name of a message description component.

An operation MUST have an input message property, an output message property or both. The input property represents the "input" message for the operation (if any), the output property the "output" message from the completion of the operation (if any) and the fault properties the fault messages that may be generated instead of the output message.

The various combinations of input and output messages of operations give rise to four kinds of operations:

• Input-Output Operations: Operations which have both input and output messages listed in that order. The semantics are that when the input message is sent to the service, one of the following MUST happen: the output message is generated; or one of the fault messages listed is generated instead. It is an error for both an output message and a fault message to be generated in response to the same input message.

• Input-Only Operations: Operations which have only an input message. The semantics are that when a message is sent to the service, the service consumes it but does not produce any output message. There MUST NOT be any fault messages indicated in this case.

• Output-Input Operations: Operations which have both output and input messages listed in that order. The semantics are that the service will generate the output message and in return the input message MUST be received or one of the fault messages listed MUST be received.

  Issue (issue-remove-solicit-response-operations): Should we remove solicit-response operations? Source: Sanjiva Weerawarana Solicit-response operations are not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

  
  
  

• Output-Only Operations: Operations which have only an output message. The semantics are that the service will generate the output message but does not expect to receive any response message or fault messages. There MUST NOT be any fault messages indicated in this case.

  Issue (issue-remove-notification-operations): Should we remove notification operations? Source: Sanjiva Weerawarana Notification operations are also not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

  
  
  

2.4 ServiceType Description Component

A serviceType description component defines a grouping of a set of portTypes. A service description component (see 2.6 Service Description Component) refers to a serviceType description to indicate the abstract functionality offered by that service.

A serviceType description component has a REQUIRED "name" property which, along with its targetNamespace property uniquely identifies the serviceType description component.

A serviceType description component identifies one or more portType description components as being members of itself. PortType description components are identified by their QName and the same portType description component (as identified by its QName) MUST NOT appear more than once in a single serviceType description component.

2.5 Binding Description Component

A binding description component provides a framework for indicating binding details for a portType description component. Binding details SHOULD be used to indicate how messages MUST be formatted when they are sent to or from the service. They SHOULD also be used to indicate the transport protocol to be used to send the messages. A given binding description component MUST NOT indicate more than one protocol.

No concrete binding details are given in this specification. The companion specification, WSDL (Version 1.2): Bindings [WSDL 1.2 Bindings] defines such bindings for SOAP 1.1 [SOAP 1.1], SOAP 1.2 [SOAP 1.2: Messaging Framework], HTTP [IETF RFC 2616] and MIME [IETF RFC 2045]. Other specifications MAY define additional binding details.

A binding description component has a REQUIRED "name" property which, along with its targetNamespace property uniquely identifies the binding description component.

A binding description component has a REQUIRED "type" property which MUST be the qualified name of a portType description component.

A binding description component MUST contain one or more binding detail properties. Binding detail properties MAY be specified as being applicable for all operations of the portType or on a per-operation basis. They MAY be further constrained as being applicable only for the input, output or faults of a given operation.

2.6 Service Description Component

A service description component defines a Web service. A service is a collection of ports. A port is a bound portType, including a specific end-point (address) at which the service is available.

A service description component has a REQUIRED "name" property which, along with its targetNamespace property uniquely identifies the service description component.

A service description component has a REQUIRED "serviceType" property which MUST be the qualified name of a serviceType description component.

A service description component MUST contain one or more port description components. Properties of port description components are given below:

• A port description component has a REQUIRED "name" property, which is used to identify this port. This name property MUST be unique across the entire descriptions group in which the containing service description component resides. Note that while the name property is of type NCName, it SHALL NOT be used as the localPart of a qualified name with the targetNamespace of the containing descriptions group as the namespace name.

  Issue (issue-port-name-uniqueness): Should portName uniqueness be restricted to be across the containing service only? Source: Sanjiva Weerawarana Since ports are within <service> elements, it seems much more natural to say that the port name must be unique across the containing service element only. Requiring them to be unique across all ports defined in the enclosing document is rather weird, especially in light of imports and such. I propose relaxing this requirement to say it must be unique within the enclosing service element.

  
  
  

• A port description component has a REQUIRED "binding" property, which MUST be the name of a binding description component which indicates how messages sent to/from this port MUST be formatted.

• A port description component MUST specify the end-point (address) to which messages MUST be sent to reach the operations of the portType description component referred to in the binding description component referred to be the "binding" property.

• A port description component has an OPTIONAL "documentation" property. The value of this property is arbitrary and SHOULD be used to provide human or machine processable documentation about the port.

A service description component MAY contain one or more binding detail properties in addition to the port properties. The semantics of those binding details are defined by the specific binding detail.

3.1 Definitions

The definitions element information item has:

• A [local name] of definitions .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• Zero or more namespace qualified attribute information items amongst its [attributes] property.

• One or more element information items in its [children] property from amongst the following:

  1. An OPTIONAL documentation element information item (see 3.2 Documentation).

  2. Zero or more import element information items (see 3.3 Importing Documents).

  3. At most one types element information item (see 3.4 Types).

  4. Zero or more message element information items (see 3.5 Messages).

  5. Zero or more portType element information items (see 3.6 Port Types).

  6. Zero or more serviceType element information items (see 3.7 Service Types).

  7. Zero or more binding element information items (see 3.8 Bindings).

  8. Zero or more service element information items (see 3.10 Services).

  The definitions element information item MUST contain at least one of the above element information items in its [children] property. If it contains more than one of the above element information items, then the following order MUST be observed: all import element information items (if any), followed by the types element information item (if present), followed by any number of message , portType , serviceType , binding and service element information items in any order.

3.2 Documentation

WSDL uses the optional documentation element as a container for human readable documentation. The content of the element is arbitrary text and elements ("mixed" in XML Schema[XML Schema: Structures]). The documentation element is allowed inside any WSDL language element.

The documentation element information item has:

• A [local name] of documentation .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• Zero or more attribute information items in its [attributes] property.

• Zero or more child element information items in its [children] property.

3.3 Importing Documents

The WSDL import element information item allows the separation of the different elements of a service definition into independent documents, which can be imported as needed. This technique helps writing clearer service definitions, by separation the definitions according to their level of abstraction, and maximizes reusability. The WSDL import element information item is modeled after the XML Schema import element information item (see [XML Schema: Structures], section 4.2.3 "References to schema components across namespaces").

The import element information item has:

• A [local name] of import .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• A REQUIRED attribute information item which has:

  • A [local name] of namespace .

  • A [namespace name] which has no value.

  The namespace attribute information item is of type anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". Its actual value indicates that the containing WSDL document can contain qualified references to WSDL definitions in that namespace (via one or more prefixes declared with namespace declarations in the normal way). This value MUST NOT match the actual value of the enclosing WSDL document targetNamespace attribute information item. It MUST be identical to the actual value of the referred WSDL document's targetNamespace attribute information item.

  Issue (issue-importing-documents-in-same-namespace): Should imports of documents in the same namespace be possible? Source: Sanjiva Weerawarana WSDL 1.1 allows imports to documents in the same namespace. The above text does not.

  
  
  

• A REQUIRED attribute information item which has:

  • A [local name] of location .

  • A [namespace name] which has no value.

  A location attribute information item is of type anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". Its actual value is the location of some information for the namespace identified by the targetNamespace attribute information item.
  
  

3.4 Types

The wsdl:types element encloses data type definitions that are relevant for the exchanged messages.

The types element information item has:

• A [local name] of types .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• An OPTIONAL documentation element information item (see 3.2 Documentation) in its [children] property.

• Zero or more attribute information items in its [attributes] property.

• Zero or more child element information items in its [children] property.

3.5 Messages

The message element information item is used to define a message description component (2.2 Message Description Components) and has:

• A [local name] of message .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• A REQUIRED attribute information item which has:

  • A [local name] of name .

  • A [namespace name] which has no value.

• One or more child element information items in its [children] property where each has:

  • A [local name] of part .

  • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

  • A REQUIRED attribute information item which has:

    • A [local name] of name .

    • A [namespace name] which has no value.

    The value of this attribute information item MUST be unique within this message description component.
    
    

  • An OPTIONAL attribute information item which has:

    • A [local name] of type .

    • A [namespace name] which has no value.

    
    
    

  • An OPTIONAL attribute information item which has:

    • A [local name] of element .

    • A [namespace name] which has no value.

    
    
    

  • It MUST be the case that either the type attribute information item is present or the element attribute information item is present or some other attribute information item which indicates the type of this message part is present.

  
  
  

3.6 Port Types

A portType is a named set of operations offered by the Web service, where an operation itself is a name given to a correlated exchange of messages. Thus, an operation is defined by its name, the data or fault messages received by the service for this operation (if any) and the data or fault messages sent by the service for this operation (if any).

The portType element information item is used to define a portType component description (2.3 PortType Description Component) and has:

• A [local name] of portType .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• A REQUIRED attribute information item which has:

  • A [local name] of name .

  • A [namespace name] which has no value.

• One or more child element information items in its [children] property where each has:

  • A [local name] of operation .

  • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

  • A REQUIRED attribute information item which has:

    • A [local name] of name .

    • A [namespace name] which has no value.

    [CLOSED] Issue (issue-operation-overloading): Should operation overloading be disallowed? Source: Joyce Yang WSDL 1.1 allows overloaded operations- operations with the same name but different messages. If they are to be disallowed then we must require the operation name to be unique within a portType. Resolution: Do not allow operation overloading. See minutes for telecon on June 27, 2002 and follow-on email discussion.

    
    
    

  • An OPTIONAL element information item in its [children] property which has:

    • A [local name] of input .

    • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

    • A REQUIRED attribute information item which has:

      • A [local name] of message .

      • A [namespace name] which has no value.

      The value of this attribute information item MUST be a qualified name which identifies a message description component.
      
      
    
    
    

  • An OPTIONAL element information item in its [children] property which has:

    • A [local name] of output .

    • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

    • A REQUIRED attribute information item which has:

      • A [local name] of message .

      • A [namespace name] which has no value.

      The value of this attribute information item MUST be a qualified name which identifies a message description component.
      
      
    
    
    

  • Zero or more element information items in its [children] property where each has:

    • A [local name] of fault .

    • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

    • A REQUIRED attribute information item which has:

      • A [local name] of name .

      • A [namespace name] which has no value.

      The value of this attribute information item MUST be unique across all fault element information items in this operation element information item.

      Issue (issue-fault-name-uniqueness): Should faults be named with QNames? Source: Sanjiva Weerawarana In WSDL 1.1 fault names are ncname which are not unique within portType even. This leads to a cumbersome mechanism to uniquely identify a fault.

      
      
      

    • A REQUIRED attribute information item which has:

      • A [local name] of message .

      • A [namespace name] which has no value.

      The value of this attribute information item MUST be a qualified name which identifies a message description component.
      
      
    
    
    
  An operation element information item MUST have at least an input or output element information item in its [children] property. The combinations of input and output element information items give rise to the different kinds of operations identified in 2.3 PortType Description Component.
  
  

3.7 Service Types

The serviceType element information item is used to define a serviceType component description and has:

• A [local name] of serviceType .

• A [namespace name] of "http://www.w3.org/2002/07/wsdl".

• A REQUIRED attribute information item which has:

  • A [local name] of name .

  • A [namespace name] which has no value.

• One or more child element information items in its [children] property where each has:

  • A [local name] of portType .

  • A [namespace name] of "http://www.w3.org/2002/07/wsdl".

  • A REQUIRED attribute information item which has:

    • A [local name] of name .

    • A [namespace name] which has no value.

    
    
    
  
  
  

3.8 Bindings

A binding defines message format and protocol details for operations and messages defined by a particular portType. There may be any number of bindings for a given portType. The grammar for a binding is as follows:

<wsdl:definitions .... >
   <wsdl:binding name="ncname" type="qname"> *
       <-- extensibility element (1) --> *
       <wsdl:operation name="ncname"> *
          <-- extensibility element (2) --> *
          <wsdl:input name="ncname"? > ?
              <-- extensibility element (3) --> 
          </wsdl:input>
          <wsdl:output name="ncname"? > ?
              <-- extensibility element (4) --> *
          </wsdl:output>
          <wsdl:fault name="ncname"> *
              <-- extensibility element (5) --> *
          </wsdl:fault>
       </wsdl:operation>
   </wsdl:binding>
</wsdl:definitions>

The name attribute provides a unique name among all bindings defined within in the enclosing WSDL document.

A binding references the portType that it binds using the type attribute. This QName value follows the linking rules defined by WSDL.

Binding extensibility elements are used to specify the concrete grammar for the input (3), output (4), and fault messages (5). Per-operation binding information (2) as well as per-binding information (1) may also be specified.

An operation element within a binding specifies binding information for the operation with the same name within the binding's portType. Since operation names are not required to be unique (for example, in the case of overloading of method names), the name attribute in the operation binding element might not be enough to uniquely identify an operation. In that case, the correct operation should be identified by providing the name attributes of the corresponding wsdl:input and wsdl:output elements.

A binding MUST specify exactly one protocol.

A binding MUST NOT specify address information.

3.9 Ports

A port defines an individual endpoint by specifying a single address for a binding.

<wsdl:definitions .... >
    <wsdl:service .... > *
       <wsdl:port name="ncname" binding="qname"> +
          <-- extensibility element (1) -->
       </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

The name attribute provides a unique name among all ports defined within in the enclosing WSDL document.

The binding attribute (of type QName) refers to the binding using the linking rules defined by WSDL.

Binding extensibility elements (1) are used to specify the address information for the port.

A port MUST NOT specify more than one address.

A port MUST NOT specify any binding information other than address information.

3.10 Services

A service groups a set of related ports together and which is defined as implementing a certain serviceType:

<wsdl:definitions .... >
    <wsdl:service name="ncname" serviceType="qname"> *
       <wsdl:port .... />*
    </wsdl:service>
</wsdl:definitions>

The name attribute provides a unique name among all services defined within in the enclosing WSDL document. The serviceType attribute allows one to indicate the serviceType of this service by referring to a previously defined serviceType.

Ports within a service have the following relationship:

• None of the ports communicate with each other (i.e. the output of one port is not the input of another).

  [CLOSED] Issue (issue-intra-port-relationship): Should intra-port relationships be allowed? Source: Prasad Yendluri The above restrictions seems to be unnecessary. What is the justification? Resolution: Decided to retain this restriction as no one could figure out what one would want with having this feature. See Wed PM minutes for June '02 F2F.

  
  
  

• If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. Each port provides semantically equivalent behavior (within the transport and message format limitations imposed by each binding). This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).

  Issue (issue-multiple-ports-in-service-semantics): What are the semantics of multiple ports of same portType appearing in a <service>? Source: Sanjiva Weerawarana During the June F2F discussions of this topic we agreed to leave the question of precise semantics for this as an open issue. Hence this issue.

  
  
  

• By examining it's ports, we can determine a service's port types. This allows a consumer of a WSDL document to determine if it wishes to communicate to a particular service based whether or not it supports several port types. This is useful if there is some implied relationship between the operations of the port types, and that the entire set of port types must be present in order to accomplish a particular task.

3.11 WSDL Document Structure

This section is non-normative.

This section uses the following informal grammar syntax to provide a preview of the overall syntactic structure of a WSDL 1.2 document:

• The syntax appears as an XML instance, but the values indicate the data types instead of values.

• Characters are appended to elements and attributes as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more).

• Elements names ending in "…" (such as <element…/> or <element…>) indicate that elements/attributes irrelevant to the context are being omitted.

• The XML namespace prefixes (defined above) are used to indicate the namespace of the element being defined.

<wsdl:definitions name="nmtoken"? targetNamespace="uri">
    <import namespace="uri" location="uri"/> *

    <wsdl:documentation .... /> ?

    <wsdl:types> ?
        <wsdl:documentation .... /> ?
        <xsd:schema .... /> *
    </wsdl:types>

    <wsdl:message name="ncname"> *
        <wsdl:documentation .... /> ?
        <part name="ncname" element="qname"? type="qname"?/> *
    </wsdl:message>

    <wsdl:portType name="ncname"> *
        <wsdl:documentation .... /> ?
        <wsdl:operation name="ncname"> *
            <wsdl:documentation .... /> ?
            <wsdl:input message="qname"> ?
                <wsdl:documentation .... /> ?
            </wsdl:input>
            <wsdl:output message="qname"> ?
                <wsdl:documentation .... /> ?
            </wsdl:output>
            <wsdl:fault name="ncname" message="qname"> *
                <wsdl:documentation .... /> ?
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:serviceType name="ncname"> *
        <wsdl:portType name="qname"/> +
    </wsdl:serviceType>

    <wsdl:binding name="ncname" type="qname"> *
        <wsdl:documentation .... /> ?
        <-- binding details --> *
        <wsdl:operation name="ncname"> *
            <wsdl:documentation .... /> ?
            <-- binding details --> *
            <wsdl:input> ?
                <wsdl:documentation .... /> ?
                <-- binding details -->
            </wsdl:input>
            <wsdl:output> ?
                <wsdl:documentation .... /> ?
                <-- binding details --> *
            </wsdl:output>
            <wsdl:fault name="ncname"> *
                <wsdl:documentation .... /> ?
                <-- binding details --> *
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="ncname" serviceType="qname"> *
        <wsdl:documentation .... /> ?
        <wsdl:port name="ncname" binding="qname"> *
            <wsdl:documentation .... /> ?
            <-- address details -->
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

WSDL 1.2 allows one to insert elements and attributes from other namespaces to any WSDL 1.2 defined element (see 4. Language Extensibility and Binding). Only specific locations where such elements are required to make WSDL 1.2 complete are indicated above. These are given by the indicated by the XML comments "<-- binding details -->" and "<-- address details -->".

6.1 Normative References

[IETF RFC 2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.

[IETF RFC 2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, Authors. Internet Engineering Task Force, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt.

[XML 1.0]

Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 6 October 2000. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2000/REC-xml-20001006. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.

[XML Information Set]

XML Information Set, J. Cowan and R. Tobin, Editors. World Wide Web Consortium, 24 October 2001. This version of the XML Information Set Recommendation is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The latest version of XML Information Set is available at http://www.w3.org/TR/xml-infoset.

[XML Namespaces]

Namespaces in XML, T. Bray, D. Hollander, and A. Layman, Editors. World Wide Web Consortium, 14 January 1999. This version of the XML Information Set Recommendation is http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.

[XML Schema: Structures]

XML Schema Part 1: Structures, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2001/REC-xmlschema-1-20010502. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.

[XML Schema: Datatypes]

XML Schema Part 2: Datatypes, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.

[WSDL 1.2 Bindings]

Web Services Description (WSDL) Version 1.2: Bindings, J-J. Moreau, J. Schlimmer, Editors. World Wide Web Consortium, 9 July 2002. This version of the Web Services Description Version 1.2: Bindings Specification is available is available at http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709. The latest version of Web Services Description Version 1.2: Bindings is available at http://www.w3.org/TR/wsdl12-bindings.

6.2 Informative References

[IETF RFC 2045]

Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, N. Borenstein, Authors. Internet Engineering Task Force, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.

[IETF RFC 2616]

Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Authors. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.

[SOAP 1.1]

Simple Object Access Protocol (SOAP) 1.1, D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer, Editors. World Wide Web Consortium, 8 May 2000. This version of the Simple Object Access Protocol 1.1 Note is http://www.w3.org/TR/2000/NOTE-SOAP-20000508. The latest version of Simple Object Access Protocol 1.1 is available at http://www.w3.org/TR/SOAP.

[SOAP 1.2: Messaging Framework]

SOAP Version 1.2 Part 1: Messaging Framework, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web Consortium, 26 June 2002. This version of the SOAP Version 1.2 Part 1 Specification is http://www.w3.org/TR/2002/WD-soap12-part1-20020626. The latest version of SOAP Version 1.2 Part 1 is available at http://www.w3.org/TR/soap12-part1.

[XML Linking]

XML Linking Language (XLink) Version 1.0, S. DeRose, E. Maler, D. Orchard, Editors. World Wide Web Consortium, 27 June 2001. This version of the XML Linking Language 1.0 Recommendation is http://www.w3.org/TR/2000/REC-xlink-20010627. The latest version of XML Linking Language 1.0 is available at http://www.w3.org/TR/xlink.

[WSDL 1.1]

Web Services Description Language (WSDL) 1.1, E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, Authors. World Wide Web Consortium, 15 March 2002. This version of the Web Services Description Language Note is http://www.w3.org/TR/2001/NOTE-wsdl-20010315. The latest version of Web Services Description Language is available at http://www.w3.org/TR/wsdl.

[WSDL 1.2 Primer]

Web Services Description (WSDL) Version 1.2: Primer, K. Sankar, K. Liu, D. Booth, Editors. World Wide Web Consortium, 9 July 2002. The editors' version of the Web Services Description Version 1.2: Primer document is available from http://www.w3.org/2002/ws/desc/.

[WSD Requirements]

Web Services Description Requirements, J. Schlimmer, Editor. World Wide Web Consortium, 29 April 2002. This version of the Web Services Description Requirements document is http://www.w3.org/TR/2002/WD-ws-desc-reqs-20020429. The latest version of Web Services Description Requirements is available at http://www.w3.org/TR/ws-desc-reqs.