SOAP Message Transmission Optimization Mechanism: Experimental Data Model Formulation

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

The SOAP Recommendation 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 this feature 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, this feature is 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 A. Mapping between Infosets and Data Models. The data model introduces 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.4.2 Receiving a message, this feature does not require that dm:type or dm:typed-value 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, and dm:children content, but not necessarily with respect to dm:type and dm:typed-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 A. Mapping between Infosets and Data Models, there is in all cases an untyped 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 SOAP processing MUST be performed on received Infosets in the manner prescribed by the SOAP Recommendation.

2.4.1 Sending a message

To send a SOAP message using the Abstract Transmission Optimization Feature, an application MUST enable the Abstract Transmission Optimization Feature. In addition it SHOULD define the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property.

When sending a SOAP message with the Abstract Transmission Optimization Feature enabled, a SOAP node using a binding implementing the Abstract Transmission Optimization Feature SHOULD optimize the transmission of all the SOAP message element nodes listed in the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property. The means of optimization is at the discretion of the binding. The fact that optimization candidates are known to be of dm:type=xs:base64binary and in canonical form implies that transmission of the dm:typed-value is sufficient to enable reconstruction of the required dm:string-value at the receiving node. Bindings MAY use such means of optimization if desired.

In addition, the SOAP node binding MAY optimize the transmission of other SOAP message element nodes not listed in the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property. In particular, if the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property is not defined or if it has an empty value, the SOAP node binding MAY optimize the transmission of any SOAP message element node(s) which have a dm:type of xs:base64binary and which are known to be in canonical form.

2.4.2 Receiving a message

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node MUST 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 exceptions:

• The dm:type of any or all received data model nodes may be set as indeterminate, using the mechanisms of dm:type.
• For any such nodes, the dm:typed-value must be adjusted accordingly, E.g. to return the same characters as dm:string-value for elements and attributes of simple type (see dm:typed-value).
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.

The receiving node MUST reconstruct from the data model an Envelope Infoset, as described in A.2 Infoset Mapping at Receiving Nodes; the receiving node MUST then perform SOAP processing on the reconstructed Infoset.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST enable the Abstract Transmission Optimization Feature. In addition, the SOAP node binding SHOULD/MAY set the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property to reflect the SOAP message parts whose transmission was optimized in the incoming message.

2.4.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 specific rules exist for a SOAP intermediary implementing the Abstract Transmission Optimization Feature.

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.4.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.4.1 Sending a message). In addition, it MUST follow the rules for relaying SOAP messages (see [SOAP Part 1] Relaying SOAP Messages).

3.2.1 Include element

The xbinc:Include element node is used for logically including generic data into an XML data model. The full XML data model can be reconstructed by replacing the xbinc:Include element node among the dm:children of its parent: the replacement content of dm:children must be a dm:text node; the dm:string-value of that text node MUST be the canonical lexical representation of the base64 encoded value of the data referred to in the href attribute of the xbinc:Include element node.

The xbinc:Include element node accessor values are as follows:

• dm:node-kind MUST be element.

• dm:node-name MUST be {http://www.w3.org/2003/06/soap/features/binary-inclusion;Include} .

• There MUST be no element nodes among dm:children.

• There MUST be one or more attribute nodes comprising dm:attributes. Among these MUST be the following:

  • href attribute node (see 3.2.2 href attribute).

• dm:nilled MUST be false.

• Other accessors such as dm:parent MUST be set according to the context.

3.2.2 href attribute

The href attribute node is used to identify the external data logically included by the xbinc:Include element node.

The href attribute node has the following data model accessor values:

• dm:node-kind MUST be attribute.

• dm:node-name MUST be {(no-namespace-URI);href} .

• dm:type MUST be xs:anyURI.

• dm:typed-value MUST be a URI referencing the part of the multipart serialization comprising the data logically included by the dm:parent element (I.e. the xbinc:Include).

• Other accessors such as dm:parent MUST be set according to the context.

3.3.1 Introduction

The MIME Multipart/Related serialization provides part of an implementation of the Abstract Transmission Optimization Feature by describing how to serialize a SOAP envelope data model in an optimized way, using MIME Multipart/Related packaging. This serialization uses the 3.2 Inclusion element element for linking the main SOAP message with element nodes serialized in a compact form.

3.3.2 Serialization of a SOAP message

For transmitting a SOAP message for which the Abstract Transmission Optimization Feature is enabled, the MIME Multipart/Related serialization helps optimizing the transmission of the message by allowing to transmit in a compact form parts of the SOAP message. The SOAP message is serialized into a MIME Multipart/Related ([RFC 2387]) packaging: one body part, the root, containing an XML representation of the SOAP envelope, while other body parts contain the parts of the SOAP message transmitted in a compact form.

Unless otherwise stated, serializing a SOAP envelope data model with the MIME Multipart/Related serialization MUST be semantically equivalent to performing the following steps separately, and in the order given.

1. Create a MIME Multipart/Related packaging.

2. Create a list of the element nodes whose transmission is to be optimized. This list SHOULD contain all the element nodes of the SOAP message pointed to in the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property. This list MAY contain other element nodes of the SOAP message provided those nodes have a dm:type of xs:base64Binary, and a dm:string-value which is in the canonical form for that type.

3. Add a serialization of the content of each element node in the list in a body part of the MIME Multipart/Related packaging.

   Editorial note: HR
   How do we set the Content-type?

4. Modify the SOAP envelope data model by replacing the dm:children of each element node in the list by an xbinc:Include element node referring to the body part of the MIME Multipart/Related packaging containing its serialization.

5. Serialize the resulting SOAP envelope data model, using XML 1.0, in the root object of the MIME Multipart/Related packaging.

   Editorial note: HR
   Do we allow only an XML 1.0 serialization?

3.3.3 Deserializing a SOAP message

When receiving a SOAP message using the MIME Multipart/Related serialization, deserializing MUST, at least logically, provide access to the reconstructed SOAP envelope data model.

The reconstruction of the SOAP envelope data model from the data contained in the MIME Multipart/Related packaging MUST be semantically equivalent to performing the following steps separately, and in the order given.

• Extract the SOAP envelope from the root object of the MIME Multipart/Related packaging and deserialize it to a data model representation.

• Extract and deserialize each other body part of the MIME Multipart/Related packaging.

• Find every xbinc:Include element node in the SOAP envelope data model.

  For each xbinc:Include element node, find the body part of the MIME Multipart/Related packaging which is referred to by the href attribute node of the xbinc:Include element node. For the element node which had the xbinc:Include element node as the value of its dm:children, set the value of dm:children to a newly constructed text node. That text node MUST have as its dm:string-value the canonical lexical representation of the base64binary value of the referred to body part.

When reconstructing a SOAP message data model, the implementation:

• SHOULD generate an "env:Sender" SOAP fault with a subcode of xbinc:MissingHRef if an xbinc:Include element node does not contain a href attribute node among its dm:attributes.

• SHOULD generate an "env:Sender" SOAP fault with a subcode of xbinc:NotFoundHRef if no body part of the MIME Multipart/Related packaging matches the href attribute node of an xbinc:Include element node.

4.3.1 Sending a SOAP message

When sending a SOAP message for which the Abstract Transmission Optimization Feature is enabled, the HTTP Transmission Optimization Feature optimizes the transmission of the message by serializing it using the 3.3.2 Serialization of a SOAP message. Unless otherwise stated, serializing a SOAP message infoset into the HTTP body MUST be semantically equivalent to performing the following steps separately, and in the order given.

1. Serialize the SOAP Message into a MIME Multipart/Related packaging as described in 3.3.2 Serialization of a SOAP message.

2. Serialize the MIME Multipart/Related packaging into the HTTP body.

4.3.2 Receiving a SOAP message

When receiving a SOAP message using the HTTP Transmission Optimization Feature, the HTTP binding MUST, at least logically, provide access to the reconstructed SOAP message infoset.

The reconstruction of the SOAP message infoset from the data contained in the HTTP Body MUST be semantically equivalent to performing the following steps separately, and in the order given.

• Extract the MIME Multipart/Related packaging from the HTTP body.

• Deserialize the SOAP message from the MIME Multipart/Related packaging as described in 3.3.3 Deserializing a SOAP message.