RE: First Draft of an MTOM Formulation based on the Query Data Model

> I agree we don't have to use the Data Model, but I'm suggesting it may be 
> desireable.  I think we have a tradition in W3C of trying to build on 
> existing specifications and abstractions.  MTOM by its nature requires 
> making statements about the type of the nodes to be optimized.  We have an 
> emerging W3C Recommendation for how to discuss typed nodes, and that's the 
> data model.  We don't have to use it, but we probably should. In addition 
> to avoiding the need to write our own prose describing the lexical/value 
> correspondence, we make it easier for others to use MTOM to describe the 
> efficient transmission of Query results, or to use MTOM as a building 
> block for a future spec that would send the full typed Infoset.

I think the problem I have with your proposal is the part that deals with the "lossy" transmission of the infoset. Type information is present when sending the infoset, but is lost once the infoset is received. If we area dealing with a typed infoset of the XQDM kind, then it should remain the same at the end of transmission.

I think we should distinguish two cases:

1) non-typed SOAP infoset (i.e. the "traditional" infoset)

No type information is logically present in the infoset either at the sending or receiving side. Nonetheless type information is "injected" at the infoset serialization/deserialization level (in correspondence with the SOAP bindings at both ends) which helps create an efficient infoset serialization. This is basically what MTOM has been dealing with so far.

2) type information is present in the SOAP infoset (the XQuery DM case)

Such type information is preserved through the SOAP transmission and is still available at the receiving side.
In addition to that, the infoset serialization/deserialization mechanism implemented by the SOAP bindings at both ends takes advantage of the XQDM type information in order to optimize the transmission of the infoset. (In other words, the type information is used for infoset serialization the same way as in case 1, but in case 2 this information comes directly from the augmented infoset).

Both cases should be supported by our MTOM mechanism.


Ugo

Received on Saturday, 6 September 2003 15:54:55 UTC