Proposal for describing MIME serialization/deserialization

Dear all,

Here is the fullfilment of the action item John and I had, concerning 
regenerating section 2.4.1 and 2.4.2 about generic MIME serialization 
and deserialization for MTOM using MIFFY.
Note that those sections are now numbered 2.3.1 and 2.3.2.

Hervé.


-------------------

Section 2.3.1 (was 2.4.1)
-------------------------
To send a SOAP message using the Abstract Transmission Optimization
Feature, a SOAP application MUST generate a data model that contains type
information for the SOAP message (see A.1 Infoset Mapping at Sending Nodes
).

When this feature is used in combination with the SOAP Request-Response 
Message Exchange Pattern (ref) or the SOAP Response Message Exchange 
Pattern (ref) described in SOAP 1.2, Part 2 (ref), the data model 
generated for the SOAP message MUST be represented in the value of the 
property corresponding to the sent SOAP message, i.e., 
http://www.w3.org/2003/05/soap/mep/OutboundMessage or 
http://www.w3.org/2003/05/soap/mep/InboundMessage. Similar rules MUST be 
applied for other MEP.

Implementations of this feature MUST NOT optimize a node of the SOAP
message whose dm:type is either xdt:untypedAny for Element Nodesand
xdt:untypedAtomic for Attribute Nodes. Implementations of this feature MAY
optimize a node of the SOAP message whose dm:type is different to
xdt:untypedAny for Element Nodesand xdt:untypedAtomic for Attribute Nodes,
and MAY use the value of the dm:type to determine how to optimize this
node.

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
dm:type of xs:base64binary. Moreover, an Element Node of
dm:type=xs:base64binary whose content is in canonical form on the sender
side MUST be reconstituted as an Element Node of dm:type=xs:base64binary
whose content is in canonical form on the receiver side. This feature
mandates nothing for Element Node of dm:type=xs:base64binary no in
canonical form. Therefore SOAP applications which need to preserve the
dm:string-value of an Element Node containing base64 encoded data are
advised against setting the dm:type of the Element Node to xs:base64binary.

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

For Element Nodes whose type was xs:base64binary on the sender side, the
reconstructed Element Node MUST either have the same dm:string-value if
enough information is available on the receiver side or have the same
dm:typed-value and a dm:string-value which is in canonical form.

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 (ref) or the SOAP Response Message Exchange 
Pattern (ref) described in SOAP 1.2, Part 2 (ref), the data model 
reconstructed MUST be represented in the value of the property 
corresponding to the received SOAP message, i.e., 
http://www.w3.org/2003/05/soap/mep/OutboundMessage or 
http://www.w3.org/2003/05/soap/mep/InboundMessage. Similar rules MUST be 
applied for other MEP.

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 (see SOAP 1.2, Part 1, SOAP Processing Model).

Received on Wednesday, 17 December 2003 05:19:46 UTC