- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Fri, 4 Jul 2003 13:47:54 -0700
- To: "XMLP Dist App" <xml-dist-app@w3.org>
I took an action item on the July 2nd concall to summarize the discussion of issues 431[1] and 432[2] Issue 431 What are the semantics of optimized elements? Specifically, are intermediaries required to preserve optimization/non-optimization of element content? I think ( and serveral people agreed with me ) that intermediaries can change the set of 'optimized elements'. In MTOM terms this means that the set of values in the OptimizationCandidates property may change from node to node. I think this is coherent, and potentially useful. Two possible scenarios spring to mind: A) Passage through a non-MTOM aware intermediary, or transmission to a non-MTOM aware end-point. An initial sender optimizes a message resulting in one or more attachments. An intermeidary detects that the next downstream node does not support MTOM and transmits the message using standard SOAP 1.2/XML 1.0 serialization. B) Passage over a communication channel with different characteristics. This one is a bit more tenuous right now, but the idea was that a message might arrive at an intermediary with one set of optimized elements and due to the characteristics of the communications channel to the next SOAP node, it might make sense to optimize more ( or less ) elements. Issue 432 How does a binding determine which nodes to optimize? At the momemnt the spec is fairly clear that a binding can use any number of ways of determining which elements to optimize including phase of the moon, size of the data, QNames of the elements. Another question that came up is how does a receiver determine which elements were optimized which led to discussion of a receiver side property 'OptimizedElements'. This may be worth recording as a separate issue. I think this summarizes where we got to, if others have more info, please wade in :-) Gudge [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x431 [2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x432
Received on Friday, 4 July 2003 16:48:54 UTC