W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2003

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

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Mon, 15 Sep 2003 18:02:58 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org
Message-id: <5DF7686A-E7C8-11D7-831E-0003937568DC@sun.com>

On Monday, Sep 15, 2003, at 11:31 US/Eastern, Martin Gudgin wrote:
>
> 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.
>
I agree that its certainly describable in infoset terms but I don't 
think that would be optimal. MTOM is based on knowledge of data types 
(or at least knowing that some elements have a type of base64) so 
basing the description of it on a spec that includes that concept seems 
like a good idea to me. Personally I don't find the XQuery Data Model 
spec overly complex, particularly when compared to PSVI which would be 
another alternative.

> 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.
>
I had a similar comment on the original document. We really need to 
make this point clear.

Regards,
Marc.

>
>
>
>> -----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
>> ------------------------------------------------------------------
>>
>>
>>
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Monday, 15 September 2003 18:03:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT