RE: Data model task force recommends adoption of data model formulation

I've read the MTOM data model draft and have the following comments:

General

1.	While I appreciate the goodness behind referencing other W3C
specifications, I don't think referencing the most complex spec that
will do the job is a good thing. Specifically, I think that the Infoset
spec is adequate for describing MTOM and that the XPath 2.0/XQuery 1.0
Data Model spec is overkill.

2.	The current draft would lead me to believe that I am required to
construct an XPath 2.0/Xquery 1.0 Data Model for my SOAP envelope (
albeit one with several properties set to 'default' values ). I do not
think this is a good thing ( see point 1 ).

3. 	If I were to come at this document with no prior knowledge of
where the spec came from, I could easily go away with the impression
that I have to have base64 strings around on the sender side before
transmission. I think we need language that makes it very clear to
people that they can start and finish with the binary form.

Specific:

4.	The Introduction cites several reasons for wanting to described
things it terms of the XPath 2.0/Xquery 1.0 Data Model;

	a) facilitating transmission of optimized queries
	b) foundation for digitial signatures canonicalizations based on
the XPath 2.0/Xquery 1.0 Data Model
	c) foundation for optimization of a fully-typed XPath 2.0/Xquery
1.0 Data Model

	Regarding a) I fail to understand why describing MTOM in terms
of the XPath 2.0/Xquery 1.0 Data Model is necessary in order for MTOM to
transmit optimized queries. That feels a bit like saying that given a
method that takes a string as a parameter has a French name then french
language strings cannot be passed to that method.

	Regarding b), I think it is unlikely that such canonicalizations
will be developed anytime soon. And even if they were, I don't see why
an Infoset description would be any less able to take advantage of such
canonicalizations.

	Regarding c), I think this is a very dangerous direction to go
in. The original intent of PASWA was to provide an approach to
serialization of raw binary data that still allows SOAP to see an XML
Infoset. It was not intended to be the first step down the road to a
binary version of XML. Given that the W3C is investigating binary XML in
other fora, I do not think desire for tranmission of a fully type
optimized Infoset is a valid reason for describing MTOM in terms of the
XPath 2.0/Xquery 1.0 Data Model.

5.	The draft states in several places that base64 encoded strins
must be in the canonical form. What is the reason for this requirement (
I realise this comment my not be directly related to the XPath
2.0/Xquery 1.0 Data Model )

6.	I do not find the descriptions in Sections 3.2.1 and 3.2.2 to be
particularly helpful. I think that the number of people who will
understand the data model spec is less than the number who will/already
do understand the Infoset spec. Describing things using Infoset terms is
consistent with SOAP 1.2 and results in no loss of descriptive power for
our purposes. ( This is largely the same as point 1 )

Regards

Martin Gudgin




> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of 
> noah_mendelsohn@us.ibm.com
> Sent: 13 September 2003 15:49
> To: xml-dist-app@w3.org
> Subject: Data model task force recommends adoption of data 
> model formulation
> 
> 
> 
> 
> 
> 
> On Friday Sept. 12th, the data model task force held a 
> teleconference during which we considered the draft 
> reformulation [1]* of MTOM based on the new XPath XQuery data 
> model [2].  During the call, the task force unanimously 
> agreed on the following recommendations to the XML Protocols
> Workgroup:
> 
> * The draft at [1] is ready for consideration by the entire 
> XML Protocols Workgroup.
> 
> * The DM formulation, as presented in [1], should be adopted 
> as the basis for future work on MTOM (though this is an 
> initial draft and will require cleanup and editing).
> 
> It should be noted that only three members of the task force 
> were present for the call on the 12th, and while the above is 
> their unanimous agreement, previous calls have had broader attendance.
> 
> The task force also considered concerns raised by Ugo Corda 
> at [3], and decided that the response at [4] represents the 
> consensus of the task force.  In quick outline, Ugo's concern 
> is that, in the interests of sticking to the established 
> scope of the existing MTOM design, and specifically in 
> allowing MTOM messages to be sent through the existing SOAP 
> HTTP binding, the data model formulation is presented as 
> lossy.  Although type information from the data model is used 
> as a hint by bindings to optimize SOAP transmission, such 
> type information is not in general transmitted.  I believe 
> Ugo's concern is that if the data model is used all, it 
> should be transmitted faithfully.  This concern presents a 
> Catch-22 for those interested in the data model formulation:  
> the XMLP WG has already agreed, at least tentatively, that 
> regardless of how the specification is modeled, type 
> information is not necessarily to be transmitted.  The task 
> force believes that on balance, the benefits of using 
> terminology that is on its way to Recommendation status, and 
> indeed doing so in way that might provide a basis for future 
> specifications that would indeed transmit the full data model 
> faithfully, outweigh any negatives resulting from the lossy 
> use of the model in MTOM at this time.
> 
> Thus, we recommend consideration and adoption of the draft at 
> [1] as the basis for future work on MTOM.
> 
> At least one set of details remains to be resolved if the DM 
> formulation is to be used: the current draft does not discuss 
> all of the accessors provided by the data model.  For 
> example, element nodes [5] provide a base-uri [6], which in 
> principle can vary for each element.  Future versions of the 
> draft would need to explain that, like type information, such 
> base URI and similar information is not transmitted.  This 
> limitation is consistent with the general philosophy that 
> MTOM will transform the input data model to a different (but 
> predictably different) output data model at the receiver.  In 
> general, the transmission will exactly preserve certain 
> information, will lose other information such as base URI and 
> type, and will not add or synthesize other information, 
> except as directly follows from the losses (e.g. typed values 
> change in the obvious way when type information is lost.)
> 
> Thank you very much.
> 
> Noah
> 
> * The draft linked from [1] is incorrectly formatted as a 
> full WD.  The current copies at [7,8] correctly show editors' 
> copy status, but are otherwise identical.  I referred to [1] 
> im the note above, as it has the original submission text to the WG.
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0014.html
> [2] http://www.w3.org/TR/xpath-datamodel/
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0018.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0007.html
> [5] http://www.w3.org/TR/xpath-datamodel/#ElementNode
> [6] http://www.w3.org/TR/xpath-datamodel/#dm-base-uri
> [7]
> http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationM
> echanismDM.xml
> [8]
> http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationM
> echanismDM.html
> 
> 
> 
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
>

Received on Monday, 15 September 2003 11:32:10 UTC