Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts

2.1.1 Pattern Name

This pattern consists of [number] message[s, in order] as follows:

[enumeration, specifying, for each message] A[n optional] message:

1. indicated by an Interface Message Reference component whose {message label} is "[label]" and {direction} is "[direction]"

2. [received from|sent to] ['some' if first mention] node [node identifier]

This pattern uses the rule [fault ruleset reference].

An Interface Operation using this message exchange pattern has a {message exchange pattern} property with the value "[pattern IRI]".

Note: In the template, the bracketed items indicate a replacement operation. Substitute the correct terms for each bracketed item.

Note: the "received from" and "sent to" are always from the point of view of the service, and participating nodes other than the service are implicitly identified as the originators of or destinations for messages in the exchange.

2.2.1 Fault Replaces Message propagation rule

When the Fault Replaces Message propagation rule is in effect, any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical direction. ^† The fault message MUST be delivered to the same target node as the message it replaces, unless otherwise specified by an extension or binding extension. If there is no path to this node, the fault MUST be discarded.^†

The Fault Replaces Message propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/fault-replaces-message

2.2.2 Message Triggers Fault propagation rule

When the Message Triggers Fault propagation rule is in effect, any message, including the first in the pattern, MAY trigger a fault message, which MUST have opposite direction. ^† The fault message MUST be delivered to the originator of the triggering message, unless otherwise specified by an extension or binding extension. Any node MAY propagate a fault message, and MUST NOT do so more than once for each triggering message. If there is no path to the originator, the fault MUST be discarded.^†

The Message Triggers Fault propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/message-triggers-fault

2.2.3 No Faults propagation rule

When the No Faults propagation rule is in effect, faults MUST NOT be propagated. ^†

The No Faults propagation rule is identified by the following URI: http://www.w3.org/ns/wsdl/no-faults

2.3.1 In-Only message exchange pattern

The in-only message exchange pattern consists of exactly one message as follows:^†

1. A message:

   • indicated by a Interface Message Reference component whose {message label} is "In" and {direction} is "in"

   • received from some node N

The in-only message exchange pattern uses the rule 2.2.3 No Faults propagation rule.^†

An operation using this message exchange pattern has a {message exchange pattern} property with the value "http://www.w3.org/ns/wsdl/in-only".

2.3.2 Robust In-Only message exchange pattern

The robust-in-only message exchange pattern consists of exactly one message as follows:^†

1. A message:

   • indicated by a Interface Message Reference component whose {message label} is "In" and {direction} is "in"

   • received from some node N

The robust in-only message exchange pattern uses the rule 2.2.2 Message Triggers Fault propagation rule.^†

An operation using this message exchange pattern has a {message exchange pattern} property with the value "http://www.w3.org/ns/wsdl/robust-in-only".

2.3.3 In-Out message exchange pattern

The in-out message exchange pattern consists of exactly two messages, in order, as follows:^†

1. A message:

   • indicated by a Interface Message Reference component whose {message label} is "In" and {direction} is "in"

   • received from some node N

2. A message:

   • indicated by a Interface Message Reference component whose {message label} is "Out" and {direction} is "out"

   • sent to node N

The in-out message exchange pattern uses the rule 2.2.1 Fault Replaces Message propagation rule.^†

An operation using this message exchange pattern has a {message exchange pattern} property with the value "http://www.w3.org/ns/wsdl/in-out".

3.1.1 Relationship to WSDL Component Model

The safety extension adds the following property to the Interface Operation component model (defined in [WSDL 2.0 Core Language]):

• {safe} REQUIRED. An xs:boolean indicating whether the operation is asserted to be safe for users to invoke. If this property is "false", then no assertion has been made about the safety of the operation, thus the operation MAY or MAY NOT be safe. However, an operation SHOULD be marked safe if it meets the criteria for a safe interaction defined in Section 3.4 of [Web Architecture].^†

3.1.2 XML Representation

<description>
 <interface>
   <operation name="xs:NCName" pattern="xs:anyURI"
              wsdlx:safe="xs:boolean"? >
  </operation>
 </interface>
</description>

The XML representation for the safety extension is an attribute information item with the following Infoset properties:

• An OPTIONAL safe attribute information item with the following Infoset properties:^†

  • A [local name] of safe

  • A [namespace name] of "http://www.w3.org/ns/wsdl-extensions"

  • A type of xs:boolean

3.1.3 Mapping from XML Representation to Component Properties

See Table 3-1.

4.1.1 wrpc:signature Extension

The wrpc:signature extension attribute information item MAY be used in conjunction with the RPC style to describe the exact signature of the function represented by an operation that uses the RPC style.

When present, the wrpc:signature extension contributes the following property to the Interface Operation component it is applied to:

• {rpc signature} OPTIONAL, but MUST be present when the style is RPC^†. A list of pairs (q, t) whose first component is of type xs:QName and whose second component is of type xs:token. Values for the second component MUST be chosen among the following four: "#in", "#out", "#inout" "#return".^†

The value of the {rpc signature} property MUST satisfy the following conditions:

• The value of the first component of each pair (q, t) MUST be unique within the list.^†

• For each child element of the input and output messages of the operation, a pair (q, t), whose first component q is equal to the qualified name of that element, MUST be present in the list, with the caveat that elements that appear with cardinality greater than one MUST be treated as a single element.^†

• For each pair (q, #in), there MUST be a child element of the input element with a name of q. There MUST NOT be a child element of the output element with the name of q.^†

• For each pair (q, #out), there MUST be a child element of the output element with a name of q. There MUST NOT be a child element of the input element with the name of q.^†

• For each pair (q, #inout), there MUST be a child element of the input element with a name of q. There MUST also be a child element of the output element with the name of q.^†

• For each pair (q, #return), there MUST be a child element of the output element with a name of q. There MUST NOT be a child element of the input element with the name of q.^†

The function signature defined by a wrpc:signature extension is determined as follows:

1. Start with the value of the {rpc signature} property, a (possibly empty) list of pairs of this form:

       [(q0, t0), (q1, t1), ...]

2. Filter the elements of this list into two lists, the first one (L1) comprising pairs whose t component is one of {#in, #out, #inout}, the second (L2) pairs whose t component is #return. During the composition of L1 and L2, the relative order of members in the original list MUST be preserved.

   For ease of visualization, let's denote the two lists as:

       (L1)    [(a0, u0), (a1, u1), ...]

   and

       (L2)    [(r0, #return), (r1, #return), ...]

   respectively.

3. Then, if the input sequence ends with an element wildcard, the formal signature of the function is:

       f([d0] a0, [d1] a1, ..., rest) => (r0, r1, ...)

   where rest is a formal parameter representing the elements in the input message matched by the element wildcard.

   Otherwise the formal signature of the function is:

       f([d0] a0, [d1] a1, ...) => (r0, r1, ...)

   i.e.:

   • the list of formal arguments to the function is [a0, a1, ...];

   • the direction d of each formal argument a is one of [in], [out], [inout], determined according to the value of its corresponding u token;

   • the list of formal return parameters of the function is [r0, r1, ...];

   • each formal argument and formal return parameter is typed according to the type of the child element identified by it (unique per the conditions given above).

4.1.2 XML Representation of the wrpc:signature Extension

The XML representation for the RPC signature extension is an attribute information item with the following Infoset properties:

• A [local name] of signature

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

The type of the signature attribute information item is a list type whose item type is the union of the xs:QName type and the subtype of the xs:token type restricted to the following four values: "#in", "#out", "#inout", "#return". See Example 4-1 for an excerpt from the normative schema definition of this type.

Additionally, each even-numbered item (0, 2, 4, ...) in the list MUST be of type xs:QName and each odd-numbered item (1, 3, 5, ...) in the list MUST be of the subtype of xs:token described in the previous paragraph.^†

<xs:attribute name="signature" type="wrpc:signatureType"/>

<xs:simpleType name="signatureType">
  <xs:list itemType="wrpc:signatureItemType"/>
</xs:simpleType>

<xs:simpleType name="signatureItemType">
  <xs:union memberTypes="xs:QName wrpc:directionToken"/>
</xs:simpleType>

<xs:simpleType name="directionToken">
  <xs:restriction base="xs:token">
    <xs:enumeration value="#in"/>
    <xs:enumeration value="#out"/>
    <xs:enumeration value="#inout"/>
    <xs:enumeration value="#return"/>
  </xs:restriction>
</xs:simpleType>
          
           

4.1.3 wrpc:signature Extension Mapping To Properties of an Interface Operation component

A wrpc:signature extension attribute information item is mapped to the following property of the Interface Operation component defined by its [owner].

5.4.1 Description

Every SOAP binding MUST indicate what version of SOAP is in use for the operations of the interface that this binding applies to.^†

By default, SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] is used.

5.4.2 Relationship to WSDL Component Model

The SOAP protocol specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap version} REQUIRED. A xs:string, to the Binding component.

5.4.3 XML Representation

<description>
  <binding  name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
            wsoap:version="xs:string"? >
    ...
  </binding>
</description>

The XML representation for specifying the SOAP version is an optional attribute information item with the following Infoset properties:

• A [local name] of version

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

• A type of xs:string

5.4.4 Mapping from XML Representation to Component properties

See Table 5-1.

5.5.1 Description

Every SOAP binding MUST indicate what underlying protocol is in use.^†

5.5.2 Relationship to WSDL Component Model

The SOAP protocol specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap underlying protocol} REQUIRED. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987], to the Binding component. This IRI refers to an appropriate SOAP underlying protocol binding (see SOAP Protocol Binding Framework in [SOAP 1.2 Part 1: Messaging Framework (Second Edition)]), which is to be used for any of the SOAP interactions described by this binding.

5.5.3 XML Representation

<description>
  <binding  name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
            wsoap:protocol="xs:anyURI" >
    ...
  </binding>
</description>

The XML representation for specifying the SOAP protocol is a REQUIRED attribute information item with the following Infoset properties:

• A [local name] of protocol

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

• A type of xs:anyURI

5.5.4 Mapping from XML Representation to Component Properties

See Table 5-2.

5.6.1 Description

For every Interface Fault component contained in an Interface component, a mapping to a SOAP Fault MUST be described.^† This binding extension specification allows the user to indicate the SOAP fault code and subcodes that are transmitted for a given Interface Fault component.

5.6.2 Relationship to WSDL Component Model

The SOAP Fault binding extension adds the following properties to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap fault code} REQUIRED. A union of xs:QName and xs:token, to the Binding Fault component, where:

  • when the value of the {soap version} is "1.2", the allowed QNames MUST be the ones defined by [SOAP 1.2 Part 1: Messaging Framework (Second Edition)], section 5.4.6^†;

  • the allowed token value is "#any".

  The value of this property identifies a possible SOAP fault for the operations in scope. If the value of this property is "#any", no assertion is made about the possible value of the SOAP fault code.

• {soap fault subcodes} REQUIRED. A union of list of xs:QName, and xs:token where the allowed token value is "#any", to the Binding Fault component. The value of this property identifies one or more subcodes for this SOAP fault. The list of subcodes is the nested sequence of subcodes. An empty list represents a fault code without subcodes.

5.6.3 XML Representation

<description>
  <binding >
    <fault ref="xs:QName"
           wsoap:code="union of xs:QName, xs:token"?
           wsoap:subcodes="union of (list of xs:QName), xs:token"? >
      <documentation />*
    </fault>*
  </binding>
</description>

The XML representation for binding a SOAP Fault are two attribute information items with the following Infoset properties:

• wsoap:code OPTIONAL attribute information item

  • A [local name] of code

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

  • A type of union of xs:QName and xs:token where the allowed token value is "#any"

• wsoap:subcodes OPTIONAL attribute information item

  • A [local name] of subcodes

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

  • A type of union of list of xs:QName, and xs:token where the allowed token value is "#any"

5.6.4 Mapping XML Representation to Component Properties

See Table 5-3.

5.7.1 Description

For every Interface Operation component contained in an Interface component, in addition to the binding rules (for SOAP 1.2, see 5.10.3 SOAP 1.2 Binding Rules), there may be additional binding information to be specified. This binding extension specification allows the user to indicate the SOAP Message Exchange Pattern (MEP) and a value for the SOAP Action Feature on a per-operation basis.

5.7.2 Relationship to WSDL Component Model

The SOAP Operation binding extension specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap mep default} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987], to the Binding component.^† The value of this property identifies the default SOAP Message Exchange Pattern (MEP) for all the Interface Operation components of any Interface component to which this Binding is applied.

• {soap mep} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987], to the Binding Operation component.^† The value of this property identifies the SOAP Message Exchange Pattern (MEP) for this specific operation (see 5.10.3 SOAP 1.2 Binding Rules, paragraph "SOAP MEP Selection", for constraints on bindings).

• {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987], to the Binding Operation component.^† The value of this property identifies the value of the SOAP Action Feature for the initial message of the message exchange pattern of the Interface Operation bound, as specified in the binding rules of bindings to specific versions of SOAP (see 5.10.3 SOAP 1.2 Binding Rules for the SOAP 1.2 binding when the value of the {soap version} property of the Binding component is "1.2").

5.7.3 XML Representation

<description>
  <binding wsoap:mepDefault="xs:anyURI"? >
    <operation ref="xs:QName" 
               wsoap:mep="xs:anyURI"?
               wsoap:action="xs:anyURI"? >
    </operation>
  </binding>
</description>

The XML representation for binding a Binding Operation are two attribute information items with the following Infoset properties:

• wsoap:mep OPTIONAL attribute information item

  • A [local name] of mep

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

  • A type of xs:anyURI

• wsoap:action OPTIONAL attribute information item

  • A [local name] of action

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

  • A type of xs:anyURI

The following attribute information item for the binding element information item is defined:

• wsoap:mepDefault OPTIONAL attribute information item

  • A [local name] of mepDefault

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

  • A type of xs:anyURI

5.7.4 Mapping from XML Representation to Component Properties

See Table 5-4.

5.8.1 Description

The SOAP messaging framework allows a Web service to engage one or more additional features (typically implemented as one or more SOAP header blocks), as defined by SOAP Modules (see [SOAP 1.2 Part 1: Messaging Framework (Second Edition)]). This binding extension specification allows description of which SOAP Modules are in use across an entire binding, on a per operation basis or on a per-message basis.

5.8.2 Relationship to WSDL Component Model

The SOAP Module component adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap modules} OPTIONAL. A set of SOAP Module components as defined in 5.8.3 SOAP Module component to the Binding component

• Similarly, {soap modules} OPTIONAL, to the Binding Operation component

• Similarly, {soap modules} OPTIONAL, to the Binding Message Reference component

• Similarly, {soap modules} OPTIONAL, to the Binding Fault component

• Similarly, {soap modules} OPTIONAL, to the Binding Fault Reference component

The SOAP modules applicable for a particular operation of any service, consists of all the modules specified in the input or output Binding Message Reference components, the infault or outfault Binding Fault Reference components, those specified within the Binding Fault components, those specified within the Binding Operation components and those specified within the Binding component. If any module is declared in multiple components, then the requiredness of that module is defined by the closest declaration, where closeness is defined by whether it is specified directly at the Binding Message Reference component or Binding Fault Reference component level, the Binding Fault level or the Binding Operation component level or the Binding component level, respectively.

5.8.3 SOAP Module component

The SOAP Module component identifies a SOAP module that is in use.

The properties of the SOAP Module component are as follows:

• {ref} REQUIRED. A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987].^† The value of this property uniquely identifies the SOAP module that is in use (as per the SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] processing model).

• {required} REQUIRED. A xs:boolean indicating if the SOAP module is required.

• {parent} REQUIRED. The Binding, Binding Operation, Binding Message Reference, Binding Fault or Binding Fault Reference components that contains this component in its {soap modules} property.

5.8.4 XML Representation

<description>
  <binding >
    <wsoap:module ref="xs:anyURI"
                  required="xs:boolean"? >
      <documentation ... />*
    </wsoap:module>
    <fault>
      <wsoap:module ... />*
    </fault>
    <operation>
      <wsoap:module ... />*
      <input>
        <wsoap:module ... />*
      </input>
      <output>
        <wsoap:module ... />*
      </output>
      <infault>
        <wsoap:module ... />*
      </infault>
      <outfault>
        <wsoap:module ... />*
      </outfault>
    </operation>
  </binding>
</description>

The XML representation for a SOAP Module component is an element information item with the following Infoset properties:

• A [local name] of module

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

• One or more attribute information items amongst its [attributes] as follows:

  • A REQUIRED ref attribute information item with the following Infoset properties:

    • A [local name] of ref

    • A [namespace name] which has no value

    • A type of xs:anyURI

  • An OPTIONAL required attribute information item with the following Infoset properties:

    • A [local name] of required

    • A [namespace name] which has no value

    • A type of xs:boolean

  • Zero or more namespace qualified attribute information items. The [namespace name] of such attribute information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".

• Zero or more element information item amongst its [children], in order, as follows:

  1. Zero or more documentation element information items as defined in [WSDL 2.0 Core Language].

  2. Zero or more namespace-qualified element information items amongst its [children]. The [namespace name] of such element information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".

5.8.5 Mapping from XML Representation to Component Properties

See Table 5-5.

5.8.6 IRI Identification Of A SOAP Module component

WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a fragment identifier syntax for identifying components of a WSDL 2.0 document.

A SOAP Module component can be identified using the wsdl.extension XPointer Framework scheme:

wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.module(parent/ref))

1. parent is the pointer part of the {parent} component, as specified in appendix A.2, Fragment Identifiers in [WSDL 2.0 Core Language]. parts.

2. ref is the value of the {ref} property of the component.

5.9.1 Description

SOAP allows the use of header blocks in the header part of the message. This binding extension allows users to declare the SOAP header blocks in use on a per-message and on a per-fault basis.

5.9.2 Relationship to WSDL Component Model

The SOAP Header Blocks binding extension specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {soap headers} OPTIONAL. A set of SOAP Header Block components as defined in 5.9.3 SOAP Header Block component, to the Binding Message Reference component.

• Similarly, {soap headers} OPTIONAL, to the Binding Fault component.

5.9.3 SOAP Header Block component

A SOAP Header Block component describes an abstract piece of header data (SOAP header block) that is associated with the exchange of messages between the communicating parties. The presence of a SOAP Header Block component in a WSDL description indicates that the service supports headers, and MAY require a client interacting with the service to use the described header block. Zero or one such header block may be used.

The properties of the SOAP Header Block component are as follows:

• {element declaration} REQUIRED. An XML element declaration in the {element declarations} property of the Description component. This XML element declaration uniquely represents a specific SOAP header block.

• {mustUnderstand} REQUIRED. A xs:boolean. When its value is "true", the SOAP header block MUST be decorated with a SOAP mustUnderstand attribute information item with a value of "true"; if so, the XML element declaration referenced by the {element declaration} property MUST allow this SOAP mustUnderstand attribute information item.^† Otherwise, no additional constraint is placed on the presence and value of a SOAP mustUnderstand attribute information item.

• {required} REQUIRED. A xs:boolean indicating if the SOAP header block is required. If the value is "true", then the SOAP header block MUST be included in the message.^† If it is "false", then the SOAP header block MAY be included.

• {parent} REQUIRED. The Binding Fault or Binding Message Reference component that contains this component in its {soap headers} property.

5.9.4 XML Representation

<description>
  <binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/soap" >
    <fault ref="xs:QName" >
      <wsoap:header element="xs:QName" mustUnderstand="xs:boolean"?
                 required="xs:boolean"? >
        <documentation />*
      </wsoap:header>*
      ...
    </fault>*
    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"?>
        <wsoap:header ... />*
        ...
      </input>*
      <output messageLabel="xs:NCName"?>
        <wsoap:header ... />*
        ...
      </output>*
    </operation>*
  </binding>
</description>

The XML representation for a SOAP Header Block component is an element information item with the following Infoset properties:

• A [local name] of header

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

• One or more attribute information items amongst its [attributes] as follows:

  • A REQUIRED element attribute information item with the following Infoset properties:

    • A [local name] of element

    • A [namespace name] which has no value

    • A type of xs:QName

  • An OPTIONAL mustUnderstand attribute information item with the following Infoset properties:

    • A [local name] of mustUnderstand

    • A [namespace name] which has no value

    • A type of xs:boolean

  • An OPTIONAL required attribute information item with the following Infoset properties:

    • A [local name] of required

    • A [namespace name] which has no value

    • A type of xs:boolean

  • Zero or more namespace qualified attribute information items. The [namespace name] of such attribute information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".

• Zero or more element information item amongst its [children], in order, as follows:

  1. Zero or more documentation element information items as defined in [WSDL 2.0 Core Language].

  2. Zero or more namespace-qualified element information items amongst its [children]. The [namespace name] of such element information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/soap".

5.9.5 Mapping XML Representation to Component Properties

See Table 5-6.

5.9.6 IRI Identification Of A SOAP Header Block component

WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a fragment identifier syntax for identifying components of a WSDL 2.0 document.

A SOAP Header Block component can be identified using the wsdl.extension XPointer Framework scheme:

wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.header(parent/element declaration))

1. parent is the "wsdl.*" pointer part of the {parent} component, as specified in appendix A.2, Fragment Identifiers in [WSDL 2.0 Core Language], i.e. without the xmlns() pointer parts.

2. element declaration is the value of the {name} of the Element Declaration component that is referred to by the {element declaration} property of the SOAP Header Block component.

5.10.1 Identifying a WSDL SOAP 1.2 Binding

A WSDL SOAP Binding is identified as a SOAP 1.2 binding by assigning the value "1.2" to the {soap version} property of the Binding component.

5.10.2 Description

The WSDL SOAP 1.2 binding extension defined in this section is an extension of the SOAP binding defined in section 5. WSDL SOAP Binding Extension to enable Web service applications to use SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)].

The WSDL SOAP 1.2 binding extension supports the SOAP 1.2 HTTP binding defined by the [SOAP 1.2 Part 2: Adjuncts (Second Edition)] specification. This is indicated by assigning the URI "http://www.w3.org/2003/05/soap/bindings/HTTP/" (as defined by [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) to the {soap underlying protocol} property. Other values MAY be used for this property in conjunction with the SOAP 1.2 binding extension defined by this specification provided that the semantics of such protocols are consistent with this binding extension.

Default rules in section 5.10.3 SOAP 1.2 Binding Rules define the relationship between SOAP message exchange patterns defined in [SOAP 1.2 Part 2: Adjuncts (Second Edition)] and WSDL message exchange patterns defined in section 2. Predefined Message Exchange Patterns.

5.10.3 SOAP 1.2 Binding Rules

These binding rules are applicable to SOAP 1.2 bindings.

• SOAP Action Feature. The value of the SOAP Action Feature for the initial message of the message exchange pattern of the Interface Operation bound is specified by the {soap action} property of this Binding Operation component. If the Binding Operation component does NOT have a {soap action} property defined, then the SOAP Action Feature (see [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) has NO value. Otherwise, its value is the value of the SOAP Action Feature for the initial message of the message exchange pattern. The {soap action} property has NO effect when binding to the SOAP-Response MEP.

• SOAP MEP Selection. For a given Interface Operation component, if there is a Binding Operation component whose {interface operation} property matches the component in question and its {soap mep} property has a value, then the SOAP MEP is the value of the {soap mep} property. Otherwise, the SOAP MEP is the value of the Binding component's {soap mep default}, if any. Otherwise, the Interface Operation component's {message exchange pattern} property MUST have the value "http://www.w3.org/ns/wsdl/in-out", and the SOAP MEP is the URI "http://www.w3.org/2003/05/soap/mep/request-response/" identifying the SOAP Request-Response Message Exchange Pattern as defined in [SOAP 1.2 Part 2: Adjuncts (Second Edition)].^†

• SOAP Detail Element. If any, the value of the SOAP "Detail" element MUST be the element information item identified by the {element declaration} property of the Interface Fault component.^†

• HTTP Method Selection. This default binding rule is applicable when the value of the {soap underlying protocol} property of the Binding component is "http://www.w3.org/2003/05/soap/bindings/HTTP/". If the SOAP MEP selected as specified above has the value "http://www.w3.org/2003/05/soap/mep/request-response/" then the HTTP method used is "POST". If the SOAP MEP selected has the value "http://www.w3.org/2003/05/soap/mep/soap-response/" then the HTTP method used is "GET".^†

5.10.4 Binding WSDL 2.0 MEPs to SOAP 1.2 MEPs

This section describes the relationship between WSDL components and SOAP 1.2 MEP properties as described in [SOAP 1.2 Part 2: Adjuncts (Second Edition)].

6.4.1 HTTP Method Selection

When formulating the HTTP message to be transmitted, the HTTP request method used MUST be selected using one of the following:^†

• For a given Interface Operation component, if there is a Binding Operation component whose {interface operation} property matches the component in question and its {http method} property has a value, then the value of the {http method} property.

• Otherwise, the value of the Binding component's {http method default}, if any.

• Otherwise, if a {safe} property as defined in 3.1 Operation safety is present on the bound Interface Operation component and has a value of "true", the value "GET".

• Otherwise, the value "POST".

6.4.2 HTTP Content Encoding Selection

When formulating the HTTP message to be transmitted, content encoding for a given Binding Message Reference component is determined as follows:^†

• If the {http content encoding} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property.

• Otherwise, if the value of the parent Binding Operation component's {http content encoding default} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property.

• Otherwise, if the value of the grandparent Binding component's {http content encoding default} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property.

When formulating the HTTP fault message to be transmitted, content encoding for a given Binding Fault component is determined as follows:^†

• If the {http content encoding} property has a non-empty value, then a Content-Encoding header-field MUST be inserted with the value of this property.

• If the {http content encoding default} property has a non-empty value, then a Content-Encoding header-field MUST be inserted with the value of this property.

The body of the response message is encoded using the specified content encoding.

6.4.3 Payload Construction And Serialization Format

When formulating the HTTP message to be transmitted, the contents of the payload (i.e. the contents of the HTTP message body) MUST be what is defined by the corresponding Interface Message Reference or Interface Fault components, serialized as specified by the serialization format used.^†

[Definition: The serialization format is a media type token ("type/subtype"). It identifies rules to serialize the payload in an HTTP message. Its value is defined by the following rules. The HTTP request serialization format MUST be in the media type range specified by the {http input serialization} property. The HTTP response serialization format MUST be in the media type range specified by the {http output serialization} property. The HTTP serialization format of a fault MUST be in the media type range specified by the {http fault serialization} property. The concept of media type range is defined in Section 14.1 of [IETF RFC 2616]. The serialization format MAY have associated media type parameters (specified with the parameter production of media-range in Section 14.1 of [IETF RFC 2616]. ]

Section 6.8 Serialization Format of Instance Data defines serialization formats supported by this binding extension along with their constraints.

• Interface Message Reference component:

  • If the value of the {message content model} property of the Interface Message Reference bound is "#any" or "#element", the serialization of the instance data is specified as defined in section 6.4.3.1 Serialization rules for XML messages.

  • If the value is "#none", then the payload MUST be empty and the value of the corresponding serialization property ({http input serialization} or {http output serialization}) is ignored.^†

  • If the value is "#other", then the serialization format and its associated media type parameters, if any, specifies the value of the HTTP Content-Type entity-header field as defined in section 14.17 of [IETF RFC 2616]. The serialization of the payload is undefined.

• Interface Fault component: the serialization of the instance data is specified as defined in section 6.4.3.1 Serialization rules for XML messages.

If the Interface Message Reference component or the Interface Fault component is declared using a non-XML type system (as considered in the Types section of [WSDL 2.0 Core Language]), then additional binding rules MUST be defined in an extension specification to indicate how to map those components into the HTTP envelope.^†

6.4.4 Default input and output serialization format

Section Table 6-1 defines the default values for the GET, POST, PUT and DELETE values of the HTTP method as selected in section 6.4.1 HTTP Method Selection.

The default value for the {http input serialization} and {http output serialization} properties for any other HTTP method selected is application/xml.

Mechanisms other than setting the serialization properties MAY modify the serialization format of the instance data corresponding to the message. An example of such modification is the WSDL SOAP Binding HTTP IRI Serialization rules specified in 5.3 SOAP Binding Rules. This binding extension specifies that the SOAP-Response Message Exchange Pattern ([SOAP 1.2 Part 2: Adjuncts (Second Edition)], Section 6.3) supports input message serialization only as application/x-www-form-urlencoded. Other examples are other message exchange patterns or binding extensions.

6.4.5 HTTP Header Construction

If the {http headers} property as defined in section 6.6 Declaring HTTP Headers exists and is not empty in a Binding Message Reference or Binding Fault component, HTTP headers conforming to each HTTP Header component contained in this {http headers} property MAY be serialized as follows:^†

• The HTTP header field name used is the value of the {name} property of the HTTP Header component. The HTTP binding MUST NOT set an HTTP header field corresponding to the value of the {name} property already set by another mechanism, such as the HTTP stack or another feature.^†

• The HTTP header field value, whose XML Schema type is declared by the {type definition} property of the HTTP Header component, is serialized following the rules of the field-value production of section 4.2 of [IETF RFC 2616].

If the value of an HTTP Header component's {required} property is "true", the inclusion of this HTTP header field is REQUIRED^†, otherwise it is OPTIONAL.

6.4.6 HTTP Request IRI

When formulating the HTTP Request, the HTTP Request IRI is an absolute IRI reference and is the value of the {http location} property of the Binding Operation component, resolved using the value of the {address} property of the Endpoint component (see section 5 of [IETF RFC 3986]).^† If the {http location} property is not set, the HTTP Request IRI is the value of the {address} property of the Endpoint component. Input serializations may define additional processing rules to be applied to the value of {http location} before applying the process of reference resolution, i.e. before combining it with the {address} property of the endpoint element to form the HTTP Request IRI. For example, the three serialization formats defined in section 6.8 Serialization Format of Instance Data define a syntax to use the {http location} as a template using elements of the instance data.

If the resulting IRI uses the https scheme, then HTTP over TLS [IETF RFC 2818] is used to send the HTTP request.

The HTTP Request IRI identifies the resource upon which to apply the request and is transmitted using the Request-URI, and optionally the Host header field, as defined in [IETF RFC 2616].

6.5.1 Description

This binding extension specification provides a binding to HTTP of Interface Operation components whose {message exchange pattern} property has a value amongst:

• "http://www.w3.org/ns/wsdl/in-only"

• "http://www.w3.org/ns/wsdl/robust-in-only"

• "http://www.w3.org/ns/wsdl/in-out"

This HTTP binding extension MAY be used with other message exchange patterns, such as outbound message exchange patterns, provided that additional semantics are defined, for example through an extension.

Each of the three supported message exchange patterns above involves one or two messages or faults being exchanged. The first one is transmitted using an HTTP request, and the second one is transmitted using the corresponding HTTP response.^† In cases where only one single message is being sent, the message body of the HTTP response MUST be empty.^†

For successful responses, the HTTP response code MUST be:

• 202 when the MEP is "http://www.w3.org/ns/wsdl/in-only"^†

• 204 when the MEP is "http://www.w3.org/ns/wsdl/robust-in-only"^†

For every Binding Operation component corresponding to such Interface Operation components, this binding extension specification allows the user to indicate the HTTP method to use, the input, output and fault serialization, and the location of the bound operation.

6.5.2 Relationship to WSDL Component Model

The HTTP binding extension adds the following properties to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http location} OPTIONAL. An xs:anyURI, to the Binding Operation component. It MUST contain an IRI reference and MUST NOT include a fragment identifier component.^†

• {http method default} OPTIONAL. A xs:string, to the Binding component, indicating the default value for the HTTP Request Method for all the Interface Operation components of any Interface component to which this Binding is applied.

• {http method} OPTIONAL. A xs:string, to the Binding Operation component, indicating the value for the HTTP Request Method for this specific Binding Operation.

• {http input serialization} REQUIRED. A xs:string, to the Binding Operation component, indicating allowed serialization rules of the HTTP Request message for this specific operation, as described in section 6.5.3 Specification of serialization rules allowed.

• {http output serialization} REQUIRED. A xs:string, to the Binding Operation component, indicating allowed serialization rules of the HTTP Response message for this specific operation, as described in section 6.5.3 Specification of serialization rules allowed.

• {http fault serialization} REQUIRED. A xs:string, to the Binding Operation component, indicating allowed serialization rules of the HTTP Response message for this specific operation in case a fault is returned, as described in section 6.5.3 Specification of serialization rules allowed.

• {http query parameter separator default} REQUIRED. A xs:string, to the Binding component, indicating the default query parameter separator character for all the Interface Operation components of any Interface component to which this Binding is applied to.

• {http query parameter separator} OPTIONAL. A xs:string, to the Binding Operation component, indicating the query parameter separator character for this Binding Operation.

6.5.3 Specification of serialization rules allowed

The value of the {http input serialization}, {http output serialization} and {http fault serialization} properties is similar to the value allowed for the Accept HTTP header defined by the HTTP 1.1 specification, Section 14.1 (see [IETF RFC 2616]) and MUST follow the production rules defined in that section except for the following:^†

1. The prefix "Accept:" MUST NOT be used.

2. The rule qdtext is changed from:

   qdtext = <any TEXT except<">>

   to:

   qdtext = <any CHAR except<">>

   This change is made to disallow non-US-ASCII OCTETs.

These properties indicate the range of media types and associated parameters with which an instance MAY be serialized. The value of the serialization format used for a message is a media type which MUST be covered by this range.^†  Wild cards (for example, "application/*") SHOULD NOT be used in this attribute information item since they may lead to interoperability problems.^†

The use of {http input serialization}, {http output serialization} and {http fault serialization} is specified in section 6.4.3 Payload Construction And Serialization Format.

6.5.4 XML Representation

<description>
 <binding whttp:methodDefault="xs:string"?
          whttp:queryParameterSeparatorDefault="xs:string"? >
   <operation ref="xs:QName" 
              whttp:location="xs:anyURI"?
              whttp:method="xs:string"? 
              whttp:inputSerialization="xs:string"? 
              whttp:outputSerialization="xs:string"? 
              whttp:faultSerialization="xs:string"?
              whttp:queryParameterSeparator="xs:string"? >
  </operation>
 </binding>
</description>
          

The XML representation for binding an Operation are six attribute information items with the following Infoset properties:

• An OPTIONAL location attribute information item with the following Infoset properties:

  • A [local name] of location

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

  • A type of xs:anyURI

• An OPTIONAL method attribute information item with the following Infoset properties:

  • A [local name] of method

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

  • A type of xs:string

• An OPTIONAL inputSerialization attribute information item with the following Infoset properties:

  • A [local name] of inputSerialization

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

  • A type of xs:string

• An OPTIONAL outputSerialization attribute information item with the following Infoset properties:

  • A [local name] of outputSerialization

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

  • A type of xs:string

• An OPTIONAL faultSerialization attribute information item with the following Infoset properties:

  • A [local name] of faultSerialization

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

  • A type of xs:string

• An OPTIONAL queryParameterSeparator attribute information item with the following Infoset properties:

  • A [local name] of queryParameterSeparator

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

  • A type of xs:string whose pattern facet is "[&;a-zA-Z0-9\-\._~!$'\(\):@/\?\*\+,]{1,1}", "&" and ";" being the most frequently used characters in practice.

The following attribute information items for the binding element information item are defined:

• An OPTIONAL methodDefault attribute information item with the following Infoset properties:

  • A [local name] of methodDefault

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

  • A type of xs:string

• An OPTIONAL queryParameterSeparatorDefault attribute information item with the following Infoset properties:

  • A [local name] of queryParameterSeparatorDefault

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

  • A type of xs:string whose length facet value is "1". The allowed characters are the same as for the {http query parameter separator} property above.

6.5.5 Mapping from XML Representation to Component Properties

See Table 6-2.

6.6.1 Description

HTTP allows the use of headers in messages. This binding extension allows users to declare the HTTP headers in use on a per message and on a per-fault basis.

6.6.2 Relationship to WSDL Component Model

The HTTP Header binding extension specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http headers} OPTIONAL. A set of HTTP Header components as defined in 6.6.3 HTTP Header component, to the Binding Message Reference component.

• Similarly, {http headers} OPTIONAL, to the Binding Fault component.

A Binding Message Reference or a Binding Fault component's {http headers} property MUST NOT contain multiple HTTP Header components with the same {name} property.^†

6.6.3 HTTP Header component

An HTTP Header component describes an abstract piece of header data (HTTP header field) that is associated with the exchange of messages between the communicating parties. The presence of a HTTP Header component in a WSDL description indicates that the service support headers, and MAY require a client interacting with the service to use the described header field. Zero or one such header field may be used.

The properties of the HTTP Header component are as follows:

• {name} REQUIRED. An xs:string whose pattern facet is "[!#-'*+\-.0-9A-Z^-z|~]+", the name of the HTTP header field. The value of this property follows the field-name production rules as specified in section 4.2 of [IETF RFC 2616].

• {type definition} REQUIRED. A Type Definition component, in the {type definitions} property of the Description component, constraining the value of the HTTP header field. This type MUST be a simple type.^†

• {required} REQUIRED. An xs:boolean indicating if the HTTP header field is required. If the value is "true", then the HTTP header field MUST be included in the message.^† If it is "false", then the HTTP header field MAY be included.

• {parent} REQUIRED. The Binding Fault or Binding Message Reference component that contains this component in its {http headers} property.

6.6.4 XML Representation

<description>
  <binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/http" >
    <fault ref="xs:QName">
      <whttp:header name="xs:string" type="xs:QName"
                    required="xs:boolean"? >
        <documentation />*
      </whttp:header>*
      ...
    </fault>*
    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"?>
        <whttp:header ... />*
        ...
      </input>*
      <output messageLabel="xs:NCName"?>
        <whttp:header ... />*
        ...
      </output>*
    </operation>*
  </binding>
</description>

The XML representation for a HTTP Header component is an element information item with the following Infoset properties:

• A [local name] of header

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

• One or more attribute information items amongst its [attributes] as follows:

  • A REQUIRED name attribute information item with the following Infoset properties:

    • A [local name] of name

    • A [namespace name] which has no value

    • A type of xs:string whose pattern facet is "[!#-'*+\-.0-9A-Z^-z|~]+".

  • A REQUIRED type attribute information item with the following Infoset properties:

    • A [local name] of type

    • A [namespace name] which has no value

    • A type of xs:QName

  • An OPTIONAL required attribute information item with the following Infoset properties:

    • A [local name] of required

    • A [namespace name] which has no value

    • A type of xs:boolean

  • Zero or more namespace qualified attribute information items. The [namespace name] of such attribute information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/http".

• Zero or more element information item amongst its [children], in order, as follows:

  1. Zero or more documentation element information items as defined in [WSDL 2.0 Core Language].

  2. Zero or more namespace-qualified element information items amongst its [children]. The [namespace name] of such element information items MUST NOT be "http://www.w3.org/ns/wsdl" and MUST NOT be "http://www.w3.org/ns/wsdl/http".

6.6.5 Mapping from XML Representation to Component Properties

See Table 6-3.

6.6.6 IRI Identification Of An HTTP Header component

WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a fragment identifier syntax for identifying components of a WSDL 2.0 document.

An HTTP Header component can be identified using the wsdl.extension XPointer Framework scheme:

wsdl.extension(http://www.w3.org/ns/wsdl/http, whttp.header(parent/name))

1. parent is the pointer part of the {parent} component, as specified in WSDL Version 2.0 Part 1: Core Language.

2. name is the {name} property value.

6.7.1 Description

For every Interface Fault component contained in an Interface component, an HTTP error code MAY be defined. It represents the error code that will be used by the service in case the fault needs to be returned.

The fault definition SHOULD agree with the definition of the HTTP error codes, as specified in section 8 of [IETF RFC 3205].^†

6.7.2 Relationship to WSDL Component Model

The HTTP Fault binding extension adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http error status code} REQUIRED. A union of xs:int and xs:token where the allowed token value is "#any", to the Binding Fault component. An integer value of this property identifies the error Status-Code as defined by [IETF RFC 2616] that the service will use in case the fault is returned.^† If the value of this property is "#any", no claim is made by the service.

6.7.3 XML Representation

<description>
  <binding >
    <fault ref="xs:QName"
           whttp:code="union of xs:int, xs:token"? >
    </fault>*
  </binding>
</description>

The XML representation for binding an HTTP Fault is an attribute information item with the following Infoset properties:

• a code OPTIONAL attribute information item

  • A [local name] of code

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

  • A type of union of xs:int and xs:token where the allowed token value is "#any"

6.7.4 Mapping from XML Representation to Component Properties

See Table 6-4.

6.8.1 Serialization of the instance data in parts of the HTTP request IRI

This section defines templating rules for the {http location} property of the Binding Operation component. Templating is used by the serialization formats defined in section 6.8 Serialization Format of Instance Data, and MAY be reused by other serialization formats.

With this HTTP binding, part of the instance data for HTTP requests MAY be serialized in the HTTP request IRI, and another part MAY be serialized in the HTTP message body.

If the {style} property of the Interface Operation bound has a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI Style, and if the {http location} property of the Binding Operation component is present, the value of the {http location} property component is used as a template^† which is combined with the {address} property of the endpoint element to form the full IRI to be used in an HTTP request, as specified in section 6.5.2 Relationship to WSDL Component Model.

The resulting IRI MUST be mapped to an URI for use in the HTTP Request as per section 3.1 "Mapping of IRIs to URIs" of the IRI specification [IETF RFC 3987].^† Additional rules for the serialization of the HTTP request IRI MAY be defined by a serialization format.

httpLocation ::= charData? (( openBrace | closeBrace | template ) charData?)*
charData ::= [^{}]*
openBrace ::= '{{'
closeBrace ::= '}}'
template ::= rawTemplate | encodedTemplate
rawTemplate ::= '{!' NCName '}'
encodedTemplate ::= '{' NCName '}'

{scheme}://{host}:{port}/temperature/{town}

{!myIRI}

6.8.2 Serialization as "application/x-www-form-urlencoded"

This serialization format is designed to allow a client or Web service to produce an IRI based on the instance data of a message and serialize a query string in the HTTP message body as application/x-www-form-urlencoded.

If this format is used then the {style} property of Interface Operation component being bound MUST contain a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI Style, i.e. this serialization format may only be used to serialize the HTTP request corresponding to the initial message of an interface operation.^†

For the HTTP binding defined in this section (6. WSDL HTTP Binding Extension), "application/x-www-form-urlencoded" MAY be used as a serialization format for an input message (HTTP Request), but MUST NOT be used as a serialization format for an output or fault message (HTTP Response).^†

<data>
  <town>Fréjus</town>
  <date>2007-06-26</date>
  <unit>C</unit>
</data>

'temperature/{town}'

'&'

date=2007-06-26&unit=C

<operation ref='t:data'
    whttp:location='temperature/{town}'
    whttp:method='GET' />

<endpoint name='e' binding='t:b'
    address='http://ws.example.com/service1/' />

GET http://ws.example.com/service1/temperature/Fr%C3%A9jus?date=2007-06-26&unit=C HTTP/1.1
Host: ws.example.com

<operation ref='t:data'
    whttp:inputSerialization='application/x-www-form-urlencoded'
    whttp:location='temperature/{town}'
    whttp:method='POST' />

<endpoint name='e' binding='t:b'
    address='http://ws.example.com/service1/' />

POST http://ws.example.com/service1/temperature/Fr%C3%A9jus HTTP/1.1
Host: ws.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: …

date=2007-06-26&unit=C

6.8.3 Serialization as "application/xml"

In this serialization, for HTTP requests, the rules for constructing the HTTP request IRI defined in 6.8.1 Serialization of the instance data in parts of the HTTP request IRI apply if the {style} property of the Interface Operation bound has a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI Style.

The instance data of the input, output or fault message is serialized as an XML document in the message body of the HTTP message, following the serialization defined in [Canonical XML]. Therefore, it is only suitable for HTTP requests using methods allowing message bodies (i.e., for the HTTP binding defined in this specification, input messages where the HTTP method selected has a body), and for HTTP responses (i.e. output and fault messages for the HTTP binding defined in this specification).

The Content-Type HTTP header MUST have the value application/xml [IETF RFC 3023], or a media type compatible with application/xml as specified in section 6.4.3.1 Serialization rules for XML messages.^† Other HTTP headers MAY be used.

6.8.4 Serialization as "multipart/form-data"

In this serialization, for HTTP requests, the rules for constructing the HTTP request IRI defined in 6.8.1 Serialization of the instance data in parts of the HTTP request IRI apply if the {style} property of the Interface Operation bound has a value of "http://www.w3.org/ns/wsdl/style/iri" as defined in 4.2 IRI Style.

This format is for legacy compatibility to permit the use of XForms clients with [IETF RFC 2388] servers. This serialization format may only be used when binding Interface Operation components whose {style} property has a value of "http://www.w3.org/ns/wsdl/style/multipart" as defined in 4.3 Multipart style, i.e. this serialization format may only be used to serialize the HTTP request corresponding to the initial message of an interface operation.^†

Specifically, for the HTTP binding defined in this section (6. WSDL HTTP Binding Extension), "multipart/form-data" MAY be used as a serialization format for an input message (HTTP Request), but MUST NOT be used as a serialization format for an output or fault message (HTTP Response).^† This format serializes the instance data in the HTTP message body, making it only suitable for HTTP requests using methods allowing message bodies.

Each element in the sequence is serialized into a part as follow:

1. The Content-Disposition header MUST have the value form-data, and its name parameter is the local name of the element.^†

2. The Content-Type header MUST have the value:^†

   • application/xml (or a media type compatible with application/xml) if the element has a complex type;

   • application/octet-stream if the element is of type xs:base64Binary, xs:hexBinary, or a derived type;

   • text/plain if the element has a simple type; The charset MUST be set appropriately. UTF-8 or UTF-16 MUST be at least supported.

3. If the type is xs:base64Binary, xs:hexBinary, xs:anySimpleType or a derived type, the content of the part is the content of the element. If the type is a complex type, the element is serialized following the rules defined in the 6.8.3 Serialization as application/xml .

The instance data MUST NOT contain elements with an xs:nil attribute whose value is "true".^†

<data>
  <town>
    <name>Fréjus</name>
    <country>France</country>
  </town>
  <date>2007-06-26</date>
</data>

<operation ref='t:data'
    whttp:location='temperature'
    whttp:method='POST'
    whttp:inputSerialization='multipart/form-data'/>

Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: xxx
        
--AaB03x
Content-Disposition: form-data; name="town"
Content-Type: application/xml

<town>
  <name>Fréjus</name>
  <country>France</country>
</town>
--AaB03x
Content-Disposition: form-data; name="date"
Content-Type: text/plain; charset=utf-8

2007-06-26
--AaB03x--

6.9.1 Description

Every Binding Message Reference and Binding Fault component MAY indicate which content encodings, as defined in section 3.5 of [IETF RFC 2616], are available for this particular message.

The HTTP binding extension provides a mechanism for indicating a default value at the Binding component and Binding Operation levels.

If no value is specified, no claim is being made.

6.9.2 Relationship to WSDL Component Model

The HTTP binding extension specification adds the following properties to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http content encoding default} OPTIONAL. A xs:string to the Binding component. This property indicates the default content encodings available for all Binding Message Reference and Binding Fault components of this Binding.

• {http content encoding default} OPTIONAL. A xs:string to the Binding Operation component. This property indicates the default content encodings available for all Binding Message Reference of this Binding Operation.

• {http content encoding} OPTIONAL. A xs:string to the Binding Message Reference component. This property indicates the content encodings available for this Binding Message Reference component. If this property does not have a value, the value of the {http content encoding default} property of the parent Binding Operation component is used instead. If that itself has no value, the value from the Binding Operation component's parent Binding component is used instead.

• Similarly, {http content encoding} OPTIONAL, to the Binding Fault component

These properties are not relevant when HTTP 1.0 is used.

6.9.3 XML Representation

<description>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           whttp:contentEncodingDefault="xs:string"? >

    <fault ref="xs:QName"
           whttp:contentEncoding="xs:string"? >
    </fault>*

    <operation location="xs:anyURI"?
               whttp:contentEncodingDefault="xs:string"? >
      <input messageLabel="xs:NCName"? 
             whttp:contentEncoding="xs:string"? />

      <output messageLabel="xs:NCName"?
              whttp:contentEncoding="xs:string"? />

    </operation>
  </binding>
</description>

The XML representation for specifying the content encoding is an OPTIONAL attribute information item for the input, output, and fault element information items with the following Infoset properties:

• A [local name] of contentEncoding

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

• A type of xs:string

The XML representation for specifying the default content encoding is an OPTIONAL attribute information item for the binding element information item or binding's child operation element information items with the following Infoset properties:

• A [local name] of contentEncodingDefault

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

• A type of xs:string

6.9.4 Mapping from XML Representation to Component Properties

See Table 6-8.

6.10.1 Description

The {http cookies} property allows Binding components to indicate that HTTP cookies (as defined by [IETF RFC 2965]) are used by specific operations of the interface that this binding applies to.

6.10.2 Relationship to WSDL Component Model

The HTTP binding extension specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http cookies} REQUIRED. A xs:boolean to the Binding component.

6.10.3 XML Representation

<description>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           whttp:cookies="xs:boolean"? >
  </binding>
</description>

The XML representation for specifying the use of HTTP cookies is an OPTIONAL attribute information item with the following Infoset properties:

• A [local name] of cookies

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

• A type of xs:boolean

6.10.4 Mapping from XML Representation to Component Properties

See Table 6-9.

6.11.1 Description

Every Endpoint component MAY indicate the use of an HTTP access authentication mechanism (as defined by [IETF RFC 2616]) for the endpoint described.

This binding extension specification allows the authentication scheme and realm to be specified.

6.11.2 Relationship to WSDL Component Model

The HTTP binding extension specification adds the following property to the WSDL component model (as defined in [WSDL 2.0 Core Language]):

• {http authentication scheme} OPTIONAL. A xs:token with one of the values "basic" or "digest", to the Endpoint component, corresponding to the HTTP authentication scheme used. When present, this property indicates the authentication scheme in use: "basic" indicates the Basic Access Authentication scheme defined in [IETF RFC 2617], and "digest" indicates the Digest Access Authentication scheme as defined in [IETF RFC 2617].

• {http authentication realm} OPTIONAL. A xs:string to the Endpoint component. It corresponds to the realm authentication parameter defined in [IETF RFC 2617]. If the {http authentication scheme} property is present, then this property MUST be present.^†

6.11.3 XML Representation

<description>
  <service>
    <endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"? >
              whttp:authenticationScheme="xs:token"? 
              whttp:authenticationRealm="xs:string"? />
    </endpoint>
  </service>
</description>

The XML representation for specifying the use of HTTP access authentication is two OPTIONAL attribute information items with the following Infoset properties:

• An OPTIONAL authenticationScheme attribute information item with the following Infoset properties:

  • A [local name] of authenticationScheme

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

  • A type of xs:token where the allowed token values are "basic" and "digest".

• An OPTIONAL authenticationRealm attribute information item with the following Infoset properties:

  • A [local name] of authenticationRealm

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

  • A type of xs:string

6.11.4 Mapping from XML Representation to Component Properties

See Table 6-10.