The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 .

This specification uses a number of namespace prefixes throughout; they are listed in . Note that the choice of any namespace prefix is arbitrary and not semantically significant (see ).

Namespace names of the general form http://example.org/... and http://example.com/... represent application or context-dependent URIs .

This specification uses the Extended Backus-Naur Form (EBNF) as described in XML 1.0 .

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

The WSDL SOAP binding described in this section extends WSDL by adding element information items and attribute information items to the Infoset of the WSDL binding element information item in the http://www.w3.org/2003/01/wsdl namespace. The following pseudo schema depicts each of these extensions.

The mandatory binding element information item indicates that messages are SOAP Envelopes .

The binding element information item has the following Infoset properties:

The binding element information item has no [children].

The optional module element information item indicates SOAP module(s) supported by a binding element information item. A SOAP module realizes zero or more SOAP features implemented as one or more SOAP header blocks.

The module element information item has the following Infoset properties:

The optional propertyConstraint element information item indicates SOAP module(s) supported by a module element information item.

The propertyConstraint element information item has the following Infoset properties:

The value of the propertyConstraint element information item is the value that is required for the SOAP property of the [parent] module.

The propertyConstraint element information item has no [children].

The optional operation element information item provides binding information for the [parent] operation. The operation element information item has the following Infoset properties:

The operation element information item has no [children].

If the operation element information item has no [attributes], it MAY be omitted.

The optional body element information item specifies properties of the SOAP Envelope body block(s) for the [parent] operation. The body element information item has the following Infoset properties:

The body element information item has no [children].

If the body element information item has no [attributes], it MAY be omitted.

The body element information item provides information on how to assemble the different message parts inside the Fault element of the SOAP Envelope. The body element information item is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Fault section is structured:

The same mechanisms are used to define the content of the Fault and parameter accessor elements.

Each part references a concrete schema definition using either the element or type attribute information item. In the first case, the element referenced by the part will appear directly under the Body SOAP Envelope element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style).

The optional header element information item specifies SOAP header block(s) for the [ancestor] operation. The header element information item has the following Infoset properties:

The header element information item has no [children].

The header element information item allow headers to be defined that are transmitted as SOAP header blocks. It is not necessary to exhaustively list all header blocks that appear in the SOAP Envelope using header element information items. For example, extensions (see Language Extensibility and Binding, , section 4) to WSDL may imply specific headers should be added to the actual payload, and it is not required to list those headers here.

Exactly one of the element and type attribute information items MUST be specified. The localname and namespace attribute information items MUST be specified if and only if the type attribute information item is specified.

The soap:header and soap:headerfault elements allows header to be defined that are transmitted inside the Header element of the SOAP Envelope. It is patterned after the soap:body element (see section ).

It is not necessary to exhaustively list all headers that appear in the SOAP Envelope using soap:header. For example, extensions (see Language Extensibility and Binding, , section 4) to WSDL may imply specific headers should be added to the actual payload and it is not required to list those headers here.

The namespace attribute is used in the same way as with soap:body (see section ), only style=document is assumed since headers do not contain parameters.

Together, the message attribute (of type QName) and the part attribute (of type nmtoken) reference the message part that defines the header type. The schema referenced by the part MAY include definitions for the soap:actor and soap:mustUnderstand attributes.

The referenced message need not be the same as the message that defines the SOAP Body.

The optional headerfault elements which appear inside soap:header and have the same syntax as soap:header allows specification of the header type(s) that are used to transmit error information pertaining to the header defined by the soap:header. The SOAP specification states that errors pertaining to headers must be returned in headers, and this mechanism allows specification of the format of such headers.

The soap:fault element specifies the contents of the SOAP Fault Details element. It is patterned after the soap:body element (see section ).

The name attribute relates the soap:fault to the wsdl:fault defined for the operation.

The fault message MUST have a single part. The namespace attribute is used in the same way as with soap:body (see section ), only style=document is assumed since faults do not contain parameters.

The mandatory address element information item contains the endpoint address of a port. The address element information item has the following Infoset properties:

The address element information item has no [children].

The following example shows three ports that are bound differently for a given port type.

If the values being passed are part1=1, part2=2, part3=3, the request format would be as follows for each port:

For each port, the response is either a GIF or a JPEG image.

The HTTP GET/POST Binding extends WSDL with the following extension elements:

These elements are covered in the subsequent sections.

The location attribute specifies the base URI for the port. The value of the attribute is combined with the values of the location attribute of the http:operation binding element. See section for more details.

The http:binding element indicates that this binding uses the HTTP protocol.

The value of the required verb attribute indicates the HTTP verb. Common values are GET or POST, but others may be used. Note that HTTP verbs are case sensitive.

The location attribute specifies a relative URI for the operation. This URI is combined with the URI specified in the http:address element to form the full URI for the HTTP request. The URI value MUST be a relative URI.

The urlEncoded element indicates that all the message parts are encoded into the HTTP request URI using the standard URI- encoding rules (name1=value&name2=value…). The names of the parameters correspond to the names of the message parts. Each value contributed by the part is encoded using a name=value pair. This may be used with GET to specify URL encoding, or with POST to specify a FORM-POST. For GET, the "?" character is automatically appended as necessary.

For more information on the rules for URI-encoding parameters, see Form submission (, section 17.13), Ampersands in URI (, section B.2.2), and Form content types (, section 17.13.4).

The http:urlReplacement element indicates that all the message parts are encoded into the HTTP request URI using a replacement algorithm:

Message parts MUST NOT have repeating values.

This example describes that a GetCompanyInfo SOAP request may be sent to a StockQuote service via the SOAP HTTP binding. The request takes a ticker symbol of type string. The response contains multiple parts encoded in the MIME format multipart/related: a SOAP Envelope containing the current stock price as a float, zero or more marketing literature documents in HTML format, and an optional company logo in either GIF or JPEG format.

The MIME Binding extends WSDL with the following extension elements:

They are used at the following locations in WSDL:

MIME elements appear under input and output to specify the MIME format. If multiple appear, they are considered to be alternatives.

To avoid having to define a new element for every MIME format, the mime:content element may be used if there is no additional information to convey about the format other than its MIME type string.

The part attribute is used to specify the name of the message part. If the message has a single part, then the part attribute is optional. The type attribute contains the MIME type string. A type value has two portions, separated by a slash (/), either of which may be a wildcard (*). Not specifying the type attribute indicates that all MIME types are acceptable.

If the return format is XML , but the schema is not known ahead of time, the generic mime element can be used indicating text/xml :

A wildcard (*) can be used to specify a family of mime types, for example all text types.

The following two examples both specify all mime types:

The multipart/related MIME type aggregates an arbitrary set of MIME formatted parts into one message using the MIME type multipart/related. The mime:multipartRelated element describes the concrete format of such a message:

The mime:part element describes each part of a multipart/related message . MIME elements appear within mime:part to specify the concrete MIME type for the part. If more than one MIME element appears inside a mime:part, they are alternatives.

When using the MIME binding with SOAP requests , it is legal to use the soap:body element as a MIME element. It indicates the content type is text/xml, and there is an enclosing SOAP Envelope.

To specify XML payloads that are not SOAP compliant (do not have a SOAP Envelope), but do have a particular schema, the mime:mimeXml element may be used to specify that concrete schema. The part attribute refers to a message part defining the concrete schema of the root XML element. The part attribute MAY be omitted if the message has only a single part. The part references a concrete schema using the element attribute for simple parts or type attribute for composite parts .