An edge label is an XML qualified name. Two edge labels are equal if and only if their XML expanded names are equal. I.e., both of the following are true:

See for uses of edge labels and position to distinguish the members of encoded values, and XML Schema for more information about comparing XML qualified names.

A graph node may be single reference or multi reference. A single reference graph node has a single inbound edge. A multi reference graph node has multiple inbound edges.

Each graph edge is encoded as an element information item and each element information item represents a graph edge. describes the relationship between edge labels and the [local name] and [namespace name] properties of such element information items.

The graph node at which an edge terminates is determined by examination of the serialized XML as follows:

All nodes in the graph are encoded as described in 1 above. Additional inbound edges for multi reference graph nodes are encoded as described in 2 above.

The lexical value of a graph node representing a simple value is the sequence of Unicode characters identified by the character information item children of the element information item representing that node. The element information item representing a simple value node MAY have among its attributes a 'nodeType' attribute information item (see ). Note that certain Unicode characters cannot be represented in XML (see XML 1.0 ).

An outbound edge of a graph node is encoded as an element information item child of the element information item that represents the node (see ). Particular rules apply depending on what kind of compound value the graph node represents. These rules are as follows:

The type name property of a graph node is a {namespace name, local name} pair computed as follows:

The arraySize attribute information item has the following Infoset properties:

The type of the arraySize attribute information item is enc:arraySize. The value of the arraySize attribute information item MUST conform to the following EBNF grammar

The arraySize attribute conveys a suggested mapping of a SOAP array to a multi-dimensional program data structure. The cardinality of the arraySize list represents the number of dimensions, with individual values providing the extents of the respective dimensions. When SOAP encoding multidimensional arrays, nodes are selected such that the last subscript (i.e., the subscript corresponding to the last specified dimension) varies most rapidly, and so on with the first varying most slowly. An asterisk MAY be used only in place of the first size to indicate a dimension of unspecified extent; asterisks MUST NOT appear in other positions in the list. The default value of the arraySize attribute information item is "*", i.e., a single dimension of unspecified extent.

The nodeType attribute information item has the following Infoset properties:

The type of the nodeType attribute information item is enc:nodeType.

The value of the nodeType attribute information item MUST, if present, be one of the strings "simple" or "struct" or "array". The value indicates what kind of a value this node represents - a simple value, a compound struct value or a compound array value respectively.

The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to procedures, or in the names of those procedures. For example, the call:

updateQuantityInStock(PartNumber="123", NewQuantity="200")

suggests that the resource to be updated is the QuantityInStock for PartNumber 123. Accordingly, when mapping to or from a programming language method or procedure, any arguments that serve to identify resources (such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed. When mapping to or from a programming language method or procedure, the name of which identifies or qualifies the identification of a resource (such as QuantityInStock above), such naming or qualification should when practical be represented in the URI to which the SOAP message is addressed. No standard means of representation of arguments or method names is provided by this specification.

The World Wide Web depends on mechanisms that optimize commonly performed information retrieval tasks. Specifically, protocols such as HTTP provide a GET method which is used to perform safe retrievals, i.e., to perform retrievals that are idempotent, free of side effects, and for which security considerations do not preclude the use of cached results or URI-based resource identification.

Certain procedure or method calls represent requests for information retrieval. For example, the call:

getQuantityInStock(PartNumber="123")

might be used to retrieve the quantity established in the example above.

The following conventions can be employed to implement SOAP retrievals and other RPCs on the Web:

The SOAP RPC Representation does not define any other value for the http://www.w3.org/2003/05/soap/features/web-method/Method.

An RPC invocation is modeled as follows:

Applications MAY process invocations with missing parameters but also MAY fail to process the invocation and return a fault.

An RPC response is modeled as follows:

When using SOAP encoding (see ) in conjunction with the RPC convention described here, the SOAP Body MUST contain only a single child element information item, that child being the serialized RPC invocation or response struct.

Under the convention, properties are represented as follows:

Properties within a SOAP node differ in terms of their scope and the origins of their values. As shown in the figure below, we make the distinction between per-message-exchange properties and more widely scoped properties by assigning them to different containers called Message Exchange Context and Environment Context respectively. All properties, regardless of their scope, are shared by a SOAP node and a particular Binding.

A feature may be expressed through multiple properties and a single property may enable more than one feature. For example, the properties called User ID and Password may be used to enable a feature called Authentication. As a second example, a single property called Message ID could be used to enable one feature called Transaction and a second feature called Message Correlation.

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 SOAP Features):

The SOAP Request-Response MEP defines a pattern for the exchange of a SOAP message acting as a request followed by a message acting as a response. The response message MAY contain a SOAP envelope, or else the response MUST be a binding-specific message indicating that the request has been received. In the absence of failure in the underlying protocol, this MEP consists of exactly two messages.

In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is first transferred from the requesting SOAP node to the responding SOAP node. Following the successful processing of the request message by the responding SOAP node, a response message is transferred from the responding SOAP node to the requesting SOAP node.

Abnormal operation during a Request-Response message exchange might be caused by a failure to transfer the request message, a failure at the responding SOAP node to process the request message, or a failure to transfer the response message. Such failures might be silent at either or both of the requesting and responding SOAP nodes involved, or might result in the generation of a SOAP or binding-specific fault (see ). Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.

The scope of a Request-Response MEP is limited to the exchange of a request message and a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

The Request-Response MEP defines a set of properties described in .

To initiate a message exchange conforming to the Request-Response MEP, the requesting SOAP node instantiates a local message exchange context. describes how the context is initialized.

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of the http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a base URI value carried in the http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/Role property of the local message exchange context.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. describes the properties that the binding initializes as part of the context's instantiation.

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. and describe these updates for the requesting and the responding SOAP nodes, respectively.

Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:

During the operation of the Request-Response MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the responding SOAP node while it is in the Receiving state, the SOAP fault is made available in http://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the Receiving+Sending state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see ).

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 SOAP Features):

The SOAP Response MEP defines a pattern for the exchange of a non-SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of failure in the underlying protocol, this MEP consists of exactly two messages, only one of which is a SOAP message:

Abnormal operation during a SOAP Response message exchange might be caused by a failure to transfer the request message or the response message. Such failures might be silent at either or both of the requesting and responding SOAP nodes involved, or might result in the generation of a SOAP or binding-specific fault (see section ). Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.

The scope of a SOAP Response MEP is limited to the request for an exchange of a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

The SOAP Response MEP defines a set of properties described in .

To initiate a message exchange conforming to the SOAP Response MEP, the requesting SOAP node instantiates a local message exchange context. describes how the context is initialized.

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a Base URI value carried in the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property of the local message exchange context.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. describes the properties that the binding initializes as part of the context's instantiation.

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. and describe these updates for the requesting and the responding SOAP nodes, respectively.

During the operation of the SOAP Response MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the responding SOAP node while it is in the Receiving state, the SOAP fault is made available in http://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the Sending state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see ).

The SOAP Web Method feature is identified by the URI (see SOAP 1.2 Part 1 SOAP Features):

Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE. These methods are formally defined in the HTTP specification , but other underlying protocols might also support them. Bindings to HTTP or such other protocols SHOULD use the SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message.

Bindings supporting this feature SHOULD use the appropriate embodiment of that method if provided by the underlying protocol; for example, the HTTP binding provided with this specification represents the GET Web method as an HTTP GET request, and the POST method as an HTTP POST request (see ). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.

The SOAP Web Method feature MAY be implemented by bindings to underlying transports that have no preferred embodiment of particular Web methods (e.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature.

The SOAP Web Method feature defines a single property, which is described in .

This specification provides for the use of the SOAP Web Method feature in conjunction with the and message exchange patterns. This feature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.

A node sending a request message MUST provide a value for the http://www.w3.org/2003/05/soap/features/web-method/Method property. A protocol binding supporting this feature SHOULD set the value of the http://www.w3.org/2003/05/soap/features/web-method/Method property at the receiving node to match that provided by the sender; the means of transmission for the method property is binding-specific.

A responding node SHOULD respond in a manner consistent with the Web method requested (e.g. a GET should result in retrieval of a representation of the identified resource) or SHOULD fault in an application-specific manner if the Web method cannot be supported.

Bindings implementing this feature MUST employ a Message Exchange Pattern with semantics that are compatible with the Web method selected. For example, the SOAP Response Message Exchange Pattern (see ) is compatible with GET.

The SOAP Action feature is identified by the URI (see SOAP 1.2 Part 1 SOAP Features):

Many SOAP 1.2 underlying protocol bindings will likely utilize the application/soap+xml media type (described in ) to transmit XML serializations of SOAP messages. The media type specifies an optional action parameter, which can be used to optimize dispatch or routing, among other things. The Action Feature specifies well-known URIs to indicate support for the action parameter in bindings which use MIME, and also to refer to value of the parameter itself.

The SOAP Action feature defines a single property, which is described in . The value of this property MUST be an absolute URI and MUST NOT be empty.

If the http://www.w3.org/2003/05/soap/features/action/Action property has a value at a SOAP sender utilizing a binding supporting this feature, the sender MUST use the property value as the value of the action parameter in the media type designator.

Conversely, if a value arrives in the action parameter of the media type designator at a SOAP receiver, the receiver MUST make that value available as the value of the http://www.w3.org/2003/05/soap/features/action/Action property.

The SOAP HTTP Binding is optional and SOAP nodes are NOT required to implement it. A SOAP node that correctly and completely implements the SOAP HTTP Binding may to be said to "conform to the SOAP 1.2 HTTP Binding."

The SOAP version 1.2 specification does not preclude development of other bindings to HTTP or bindings to other protocols, but communication with nodes using such other bindings is not a goal. Note that other bindings of SOAP to HTTP MAY be written to provide support for SOAP Message exchange patterns other than or the . Such alternate bindings MAY therefore make use of HTTP features and status codes not required for this binding.

The SOAP HTTP binding defines a base URI according to the rules in HTTP/1.1 . I.e., the base URI is the HTTP Request-URI or the value of the HTTP Content-Location header field.

This binding of SOAP to HTTP is intended to make appropriate use of HTTP as an application protocol. For example, successful responses are sent with status code 200 or 202, and failures are indicated as 4XX or 5XX. This binding is not intended to fully exploit the features of HTTP, but rather to use HTTP specifically for the purpose of communicating with other SOAP nodes implementing the same binding. Therefore, this HTTP binding for SOAP does not specify the use and/or meaning of all possible HTTP methods, header fields and status responses. It specifies only those which are pertinent to the or the , or which are likely to be introduced by HTTP mechanisms (such as proxies) acting between the SOAP nodes.

Certain optional features provided by this binding depend on capabilities provided by HTTP/1.1, for example content negotiation. Implementations SHOULD thus use HTTP/1.1 (or later compatible versions that share the same major version number). Implementations MAY also be deployed using HTTP/1.0, although in this case certain optional binding features may not be provided.

Particularly when used with the , the HTTP messages produced by this binding are likely to be indistinguishable from those produced by non-SOAP implementations performing similar operations. Accordingly, some degree of interoperation can be made possible between SOAP nodes and other HTTP implementations when using this binding. For example, a conventional Web server (i.e., one not written specifically to conform to this specification) might be used to respond to SOAP-initiated HTTP GET's with representations of Content-Type application/soap+xml. Such interoperation is not a normative feature of this specification.

Even though HTTP often is used on the well-known TCP port 80, the use of HTTP is not limited to that port. As a result, it is possible to have a dedicated HTTP server for handling SOAP processing on a distinct TCP port. Alternatively, it is possible to use a separate virtual host for dealing with SOAP processing. Such configuration, however, is a matter of convenience and is not a requirement of this specification (see SOAP 1.2 Part 1 Binding to Application-Specific Protocols).

Conforming implementations of this binding:

The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with either or (differences are indicated as necessary.) This binding supports streaming and, as a result, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted (see ). The following subsections describe each state in detail.

The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with either or (differences are indicated as necessary). The following subsections describe each state in detail.