1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0 Data Model

The SOAP Recommendation ([SOAP Part 1] and [SOAP Part 2]) provides for processing of SOAP "envelopes", which are modeled as XML Information Sets ([XML InfoSet]). Such Infosets capture the tree structure, the names of the elements, the character content of elements and attributes, and so on. The Infoset does not model schema data types, such as integer, and thus provides no association between character strings and values. Schema validation is not in general required for processing of SOAP messages.

The purpose of the feature described in this document is to optimize the transmission of SOAP envelopes by relying on type information that may be available to the sender. This feature does not specify any particular means by which such type information is to be determined: schema validation is one possibility, but senders MAY determine or establish types using other means. Type information need be provided only for Element Nodes that are to be optimized.

Unlike the Infoset, the XQuery 1.0 and XPath 2.0 Data Model ([XML Query Data Model], hereinafter referred to as the "Data Model") provides a model that carries type and value space information for each element and attribute. Accordingly, the feature described in this document and its implementations are expressed in terms of that Data Model. A precondition for use of this feature is therefore availability of a Data Model for the message to be transmitted. Details of the correspondence between SOAP Infosets and Data Models are provided in [XOP] A. Mapping between Infosets and Data Models. The Data Model introduces properties and accessors such as dm:string-value , dm:type and dm:typed-value , which are used in this specification.

The SOAP envelope does not in general convey schema type information, and the purpose of this feature is to optimize but not otherwise change the SOAP processing model. Accordingly, as described in 2.3.2 Receiving a message, the feature described in this document and its implementations does not require that the type property or the return value of the dm:typed-value accessor be reconstructed at a receiving node. This feature thus implements a "lossy" model, in which type information available to the sender may be used for purposes of optimization, but need not in general be provided to the receiver (except insofar as necessary in the binding to implement the optimization). The envelope Data Models at sender and receiver are therefore identical in overall structure, dm:string-value accessor return value, and children property value, but not necessarily with respect to type property value and dm:typed-value accessor return value.

1.2.2 Relationship to the SOAP Processing model

This feature makes no changes to the SOAP processing model. Although type information is used to optimize transmission of SOAP envelopes, that type information in no way affects the processing of messages once received. As described in 2.3.1 Sending a message and 2.3.2 Receiving a message, there is in all cases an untyped XML Infoset corresponding to each transmitted and received envelope Data Model. The Data Models transmitted MUST in all cases correspond to legal SOAP envelope Infosets, and as described in 2.3.2 Receiving a message, SOAP processing is performed on received Infosets in the manner prescribed by the SOAP Recommendation.

2.3.1 Sending a message

To send a SOAP message using the Abstract Transmission Optimization Feature, a SOAP application MUST generate a Data Model corresponding to the SOAP Envelope Insoset in the manner specified in [XOP] A.1 XOP Infoset to Data Model Mapping.

When this feature is used in combination with the SOAP Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2 SOAP Request-Response Message Exchange Pattern) or the SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP Response Message Exchange Pattern), the http://www.w3.org/2003/05/soap/mep/OutboundMessage property is the Infoset derived from the Original Data Model as described in [XOP] A.2 XOP Data Model to Infoset Mapping. Similar rules should be applied for other MEPs, as appropriate.

Implementations of this feature are likely to optimize a set of Element Nodes of the SOAP message and may use the value of the type property to determine how to optimize the Element Nodes.

One purpose of the Abstract Transmission Optimization Feature is to optimize the transmission of base64 encoded data. To be optimized, an Element Node whose content consists of base64 encoded data MUST have a type property value of xs:base64Binary and the return value for its dm:string-value accessor MUST be a canonical lexical form of that type (see [XML Schema Part 2] 3.2.16 base64Binary and Errata in XML Schema, E2-54).

Note: the means of identifying Nodes in canonical lexical form are implementation-dependent. Some implementations can identify such Nodes by construction (e.g., because a certain API may create only canonical forms); others may check the characters prior to sending; yet others may observe a convention of setting the type property to xs:base64Binary in MTOM Data Models only when the data is known to be canonical. Because of the need to exactly preserve the characters in the transmitted Infoset, non-canonical representations MUST NOT be optimized.

2.3.2 Receiving a message

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node SHOULD fault if it does not support the implementation used or the Abstract Transmission Optimization Feature.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST reconstruct the transmitted Data Model, with the following rules:

• The type of all received Data Model Element Nodes and Attribute Nodes MUST be set as described in [XML Query Data Model] 6.2.3 Construction from an Infoset for Element Nodes and in [XML Query Data Model] 6.3.3 Construction from an Infoset for Attribute Nodes.

• The return value of the dm:typed-value accessor MUST be adjusted accordingly, i.e., to return the same characters as dm:string-value for Element Nodes and Attribute Nodes of undeterminated type (see dm:typed-value ).

The receiving node MUST reconstruct from the Data Model an Envelope Infoset, as described in [XOP] A.2 XOP Data Model to Infoset Mapping; the receiving node MUST then perform SOAP processing on the reconstructed Infoset (see [SOAP Part 1] 2. SOAP Processing Model). In all cases, the received Infoset MUST be exactly the same as that transmitted by the sender. Receivers MUST NOT, for example, convert non-canonical lexical representations to canonical.

Implementations are free to reconstruct only those portions actually needed for processing, or to present information from the message in a form convenient for efficient processing. For example, a value sent in an optimized form (e.g., binary) MAY be made available in that form as well as in the character form mandated by dm:string-value .

When this feature is used in combination with the SOAP Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2 SOAP Request-Response Message Exchange Pattern) or the SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP Response Message Exchange Pattern), the Infoset contained in the http://www.w3.org/2003/05/soap/mep/InboundMessage property is derived from the Data Model as described in [XOP] A.2 XOP Data Model to Infoset Mapping. Similar rules should be applied for other MEPs, as appropriate.

Note: applications may perform schema validation or other processing that might create Data Models with more specific type information than that provided herein, but this feature does not provide for the reconstruction of type information based on type property values provided by the sender.

2.3.3 Intermediaries

The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path. Therefore, no changes or restrictions to the SOAP processing model are introduced by this feature at an intermediary. The section 2.3.4 Binding Optimizations at Intermediaries details the means by which certain optimizations can be performed by bindings at intermediaries. Note that the type property is used only as a means of facilitating hop-by-hop optimization: it does not in general affect processing at a SOAP receiver, and values of the type property are not in general preserved when relaying through an intermediary.

However a SOAP intermediary implementing the Abstract Transmission Optimization Feature MUST still follow the rules related to the usage of an implementation of the Abstract Transmission Optimization Feature when receiving the message (see 2.3.2 Receiving a message) and those related to the usage of an implementation of the Abstract Transmission Optimization Feature when sending the message (see 2.3.1 Sending a message). In addition, it MUST follow the rules for relaying SOAP messages (see [SOAP Part 1] 2.7 Relaying SOAP Messages).

2.3.4 Binding Optimizations at Intermediaries

As described in [SOAP Part 1] 2.7 Relaying SOAP Messages, a SOAP intermediary may be called upon to relay intact certain headers, or to reinsert headers identical to those received and removed for processing. Furthermore, many intermediaries will relay unmodified the contents of the SOAP body. In all these cases, portions of the relayed message have content identical to corresponding portions of the inbound message.

The Abstract Transmission Optimization Feature does not require any particular correspondence between the optimization of the inbound message and the outbound message, even when optimized portions of the inbound message are relayed intact, or reinserted in identical form in the envelope Infoset. Nonetheless, the implementations of the receiving binding and the binding used to transmit the relayed message MAY cooperate to provide efficient relay. For example, if the inbound and outbound binding use the same representation for optimized binary, the implementations MAY cooperate to pass the optimized form directly from the inbound to the outbound binding. The choice of whether to implement such cooperation, and if so the means used, is at the discretion of the binding specification(s) and/or the implementation of the bindings. In support of such cooperation, the inbound binding MAY make available to the outbound binding the received values of some or all type properties.

Note: a consequence of this architecture is that there are no invariant rules for the degree to which optimizations are preserved as a message passes through intermediaries. Certain outbound bindings may be incapable of any optimization, and will therefore transmit unoptimized forms in all cases. Other bindings may be capable of optimization, but may or may not choose to or succeed in optimizing the same portions (if any) that were optimized in the inbound message. Other bindings, perhaps under the direction of logic provided in SOAP modules or perhaps as consequence of conventions embodied in the bindings, may optimize portions of the message that were not optimized inbound, or which were optimized using different techniques.

4.3.1 Sending a SOAP message

When sending a SOAP message, the HTTP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding. This section describes the perturbations to [SOAP Part 2] 7.5.1 Behavior of Requesting SOAP Node that result from use of the HTTP Transmission Optimization Feature. Only those aspects described below differ from the existing operation of the HTTP binding, all other aspects of its operation remaining unchanged.

4.3.2 Receiving a SOAP message

When receiving a SOAP message, the HTTP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding. This section describes the perturbations to [SOAP Part 2] 7.5.2 Behavior of Responding SOAP Node that result from use of the HTTP Transmission Optimization Feature. Only those aspects described below differ from the existing operation of the HTTP binding, all other aspects of its operation remaining unchanged.

When making an abstraction of the request message available in http://www.w3.org/2003/05/soap/mep/InboundMessage , the HTTP Binding MUST reconstruct the SOAP Envelope Infoset as described in 3.3 Deserialization of a SOAP message.