Re: Proposal for describing MIME serialization/deserialization

Herve, please see below.

                   Jacek Kopecky

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




On Wed, 2003-12-17 at 11:17, Herve Ruellan wrote:
> 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.

I suggest the last sentence above to be:

"Similar rules should be applied for other MEPs, as appropriate."

I don't think we can say something MUST be done in such a vague
sentence.

> 
> 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.

can xdt:untypedAtomic be the type of an element node? Anyway, why
prohibit optimization of untyped values? What if compressing them is a
useful optimization?

> 
> 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

...not in... (as opposed to ...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 the node is doing something it doesn't support, it must fault? 
I don't think it would be doing it in the first place.

> 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.

I think the above paragraph should be rephrased to only include the
canonical form case because "This feature mandates nothing for Element
Node of dm:type=xs:base64binary not 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.

Same comment as above.

> 
> 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).
> 
>