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

Noah,

The more I think about this the more it seems to me that all we are doing here is specifying a particular instance of Infoset serialization. This is not intended, of course, to diminish the value of this activity, but to put it in the regular context of Infoset serialization. In other words, instead of looking at this work as a way of going beyond the Infoset by using "a typed superset of the Infoset", we could look at it as just a particular type of Infoset serialization. In that respect, all we are doing here is exactly part of what SOAP normally prescribes, i.e. choosing a particular Infoset serialization of the SOAP envelope and sending it over the wire.

By definition, an Infoset serialization consists of a concrete representation of the Infoset (e.g. a traditional character-based angle-brackets representation, an in-memory DOM-based representation, etc.) plus some rules that allow us to map from the abstract Infoset to the concrete representation. In our case, we choose the MIME Multipart/Related packaging as the base for our concrete Infoset representation. 

We still have to decide how to concretely represent Character Information Items. Instead of using the usual approach of representing them as characters in a string, we want something more compact (at least in some cases). Here comes the trick (i.e. the serialization rule) we use for achieving this more compact representation. The rule is:

- associate a type with particular Infoset string values (based on previous Schema validation, or whatever else)
- use that type to binary encode the Infoset string value (i.e. if the type is base64 get the corresponding binary value, if the type is integer get some binary representation of the corresponding integer value, etc.)

At this point we have a complete serialization mechanism for our Infoset, which allows us to go from abstract Infoset to concrete representation and vice versa.

From this perspective, reference to the XQuery Data Model is useful but not strictly necessary. In particular, we don't need to think of the SOAP envelope Infoset being sent as a typed augmentation of the traditional Infoset. The "typing trick" is below the cover, part of the Infoset serialization machinery, and does not need to appear either in the SOAP envelope Infoset being sent or in the SOAP envelope Infoset being received.

Ugo