Re: Proposal for describing MIME serialization/deserialization

Hi Jacek,

my responses are below.

Jacek Kopecky wrote:

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

I agree that it is probably better. I had a hard time figuring out how 
to express the idea that for other MEP we should do the same thing. So 
either we keep your proposal (or something similar), or we create a 
whole paragraph giving more precise abstract rules (which may be 
difficult to write and to understand). I prefer keeping your proposal.

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

I just checked: an element node can be of type xdt:untypedAtomic.
After more thought on this, I think we should make the decision of what 
kind of nodes we want to be able to optimize.
Document Nodes: probably not
Element Nodes: yes, probably even untyped.
Attribute Nodes: yes?
Namespace Nodes: ??? need to read better the spec to determine this
PI Nodes: No (don't exist in SOAP)
Comment Nodes: ?
Text Nodes: No: optimized as part of their parent element nodes.

This should be discussed tonight when evaluating this proposal.

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

Argh ! Typo :-(
> 
> 
>>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.

What I was trying to say is that if you receive a message you do not 
understand, you fault. If this seems not necessary, this sentence could 
be removed, but I think we should keep it for completeness.
Moreover it should be a SHOULD and not a MUST.

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

The sentence "This feature mandates nothing for Element Node of 
dm:type=xs:base64binary not in canonical form." is not clear enough. 
What is meant is that the feature mandates nothing for the reconstructed 
form of Element Nodes of dm:type=xs:base64binary not in canonical form.

Therefore I think we should keep the above paragraph and change the 
other sentence to be more clear.


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

Agreed.

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

Thanks for your comments,

Hervé.

Received on Wednesday, 17 December 2003 08:43:03 UTC