Re: Proposal for describing MIME serialization/deserialization

Hi all, per my action item I'm sending an amended version of Herve's
text. I've folded in the changes I proposed in my previous message in
this thread, that is those that I think we agree on with Herve.

More importantly, I changed the third paragraph as discussed at the
telecon today - regarding the text saying nodes MUST NOT optimize some
given nodes.

Also, I changed the fourth paragraph not to mandate that the receiving
side reconstruct the typing information - as per Noah's comments on the
call.

Comments welcome.

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




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

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 should
be applied for other MEPs, as appropriate.

Implementations of this feature are likely to optimize a set of nodes of
the SOAP message and may use the value of the dm:type to determine how
to optimize the 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
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 whose content is in
canonical form on the receiver side. This feature mandates nothing for
the reconstructed form of an Element Node of dm:type=xs:base64binary not
in canonical form. Therefore SOAP applications which need to preserve
the non-canonical 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 that uses 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 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 adjuste
    accordingly, i.e., to return the same characters as dm:string-value 
    for elements and attributes of simple type (see dm:typed-value).

For optimized 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 should
be applied for other MEPs, as appropriate.

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 14:17:35 UTC