- From: Jacek Kopecky <jacek@systinet.com>
- Date: 09 Jul 2003 20:43:14 +0200
- To: XMLP Dist App <xml-dist-app@w3.org>
Hi all, I voiced this opinion before in a telcon, I believe, but I'll better try to put it down in writing: I think that in the abstract, the property that our Abstract Transmission Optimization Feature would use better would be a set of (pointers to) the elements that are *to be optimized*, not just a set of candidates. The reason for making the property a set of candidates is seemingly that the binding may actually decide it knows better and not optimize transmission of certain elements. What I'm saying is that in an implementation, any piece of code can contribute to the value of the property, including the code implementing the binding. If we have OptimizedElements property instead of OptimizationCandidates, the property can be naturally transmitted to the other node and it may (and I think it should) be the initial value of the property on a relaying node. This would make it clear that we think that unless the relaying node explicitly changes the value, the same elements will be optimized after relay. If we keep OptimizationCandidates with thee current semantics, we are implicitly providing (at least on the sending node) another piece of information - the set of elements that were considered optimization candidates but weren't actually optimized. What do we need this information for? Some people actually seem to think this piece of information might be transferred to the receiving node, which introduces more implementation complexity. Why? In summary, I propose we rename the property to OptimizedElement (or alike) and change the current semantics to say that it contains (pointers to) the elements that will be optimized in transmission by an MTOM-aware binding. Hope it makes sense, Jacek Kopecky Senior Architect Systinet Corporation http://www.systinet.com/
Received on Wednesday, 9 July 2003 14:43:19 UTC