- 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
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 UTC