- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 17 Nov 2003 21:30:52 -0500
- To: "John J. Barton" <John_Barton@hpl.hp.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, Jacek Kopecky <jacek.kopecky@systinet.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
John Barton writes: > first, go back one step to the info model the app will > really be working against: > > <person> > <name>Noah Mendelsohn</name> > <picture href="file://mylocaldrive/file_or_DB"/> > </person> This seems like an interesting specific case, but I think what I've proposed is more general and somewhat simpler as an abstraction in the following senses: * My model doesn't presume that a file exists. Maybe the data is streaming off a sensor like a camera (my API used a file source as an example, but it would have worked equally well with createMTOMElementfromUnamedInputStream(). * If the file does exist at the sender, my model doesn't presume that its existence is of interest in the message or to the receiver. If all you want is the data, that's all you get, just like any other XML element content. * Although it allows you to build things like manifests if you need them, it eliminates the requirement that you have them. If you want to put my picture in a vcard-like XML, you can put it right in, and MTOM will optimize it. No need for a manifest except if you want a manifest. On the other hand, if you happen to WANT the model that you've described, I think that something close layers quite nicely onto what I've proposed. The PASWA representation header is just an example of how associations with known files or other web resources can be modeled. In this case, my createMTOMElementChild or similar API would be used to create the representation header itself. You can also invent and standardize manifest formats to your heart's content. Consider your example: > <manifest> > <attachment metadata="image/jpeg etc..." ID="1"> > <xbinc:include href="file://mylocaldrive/file_or_DB"/> > </attachement> > </manifest> > <person> > <name>Noah Mendelsohn</name> > <picture href="#1"/> > </person> Although we are still working on the exact syntax, PASWA suggests an idiom more along the lines of: <soap:Header> <swa:Representation URI='file://mylocaldrive/noahpic.jpeg' xmime:MediaType='image/jpeg' > ...base 64 of the picture inline here... </swa:Representation> </soap:Header> <soap:Body> <person> <name>Noah Mendelsohn</name> <picture href="file://mylocaldrive/noahpic.jpeg"/> </person> </soap:Body> The reference to a file: URI that I've lifted from your example is a bit stilted in this illustration, since its meaning is dependent on context. There might be a completely different file with the same name at each node in the message path, and that's confusing. So, just to get that confusion out of the way, let's instead assume that the file with my picture were out on some webserver. What we want is to send a copy of the representation bits with the message. This is the exactly the same example as above, just changing the URI to make clear that we are talking about a web resource with stable identity external to the message: <soap:Header> <swa:Representation URI='http://example.org/noahpicture.jpeg' xmime:MediaType='image/jpeg' > ...base 64 of the picture inline here... </swa:Representation> </soap:Header> <soap:Body> <person> <name>Noah Mendelsohn</name> <picture href="http://example.org/noahpicture.jpeg"/> </person> </soap:Body> The point of these two examples is: * swa:Representation carries a cached representation of a Web resource. The intended implementation at the receiver is specifically a proxy cache, as one would find in a browser. * The href on the picture element is a proper web reference, not an id/idref. It is expected that it will be satisfied by the cached copy carried by the representation. You can view the set of Representation(s) as reprsenting a simple form of manifest that by the way carries the content of the identified items. I think it should be clear that one could also invent higher level manifests if required by the application, but the above is all that is needed for the MTOM/PASWA mechanisms. Anyway, I hope this explains the model as I understand it. While we have never discussed API specifics, I think I'm right in saying that these message idioms are pretty close to concensus as what we mean by MTOM. These are very definitely different than SOAP+Attachemnts; that's the difference we bought into when we switched gears to work on MTOM. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Monday, 17 November 2003 21:35:33 UTC