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

John,

On the data model call a week or so ago, I took an action item to draft
(with advice from you) a version of MTOM based on the Query data model.
I've taken a first cut over the past day or so, and I think it looks pretty
good.  XML and HTML are attached.  I'll try and check it into CVS after
lunch.  Also:  I've cc:'d distApp, as I think it's worth a review by at
least the DM task force, and for that matter by anyone else who's
interested.

For those who don't remember the context of this work, I proposed a few
months ago that we explore expressing MTOM in terms of the Query data
model.  Among the reasons for this proposal are:

* MTOM uses type information, and the Data Model is emerging as the
normative W3C model for typed XML

* There is some reason to hope that this formulation will facilitate the
transmission of Query results through SOAP.

* If investments are made, for example, in DSIG canonicalizations that work
on the typed data model (e.g. using dm:typed-value as input to the c14n),
then the
same mechanism should apply to signing of MTOM transmissions (which seems
interesting to me, as the performance of signatures is one of the major
remaining concerns about MTOM, IMO.)

* Although this version of MTOM doesn't do it, the extensions to turn this
into an optimized facility for sending the whole data model would be
straightforward.

Also FYI:  this formulation attempts to capture a few decisions that were
made >tentatively< on the dm call.  These include:

* Type information is used only for optimization:  it is not in any other
sense conveyed for processing by the receiver.  We could loosen that, but
would lose the ability to run compatibly under old bindings, and would
raise the question of useful information being conveyed outside the XML
serializations.

* We decided, for now, to handle only base64Binary.  The extension to any
other type(s) with canonical lexical representations is straightforward.

I tried not to make substantative changes beyond the DM reformulation, but
in a few cases I did.  For example, I point out that we can only optimize
data in the canonical form of base64Binary, and I refer to the appropriate
Schema erratum (as yet not formally published, unfortunately.)

Comments from all are most welcome, but after tomorrow AM I am likely to be
incommunicado until about cheers.  Enjoy!

(See attached file: OptimizationMechanismDM.html)(See attached file:
OptimizationMechanismDM.xml)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------