- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Tue, 11 Nov 2003 10:52:00 -0800
- To: Jacek Kopecky <jacek.kopecky@systinet.com>, Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Anish, Here is my version of what Jacek et al. have been saying. Or rather this is my attempt to put what they are saying in terms I can understand. If I'm correct maybe it will help you; if not maybe someone will correct me. We start off with some XML and some binary files. We open up the API to package these up into a message. What's the API going to look like? One model has functions to set up a container, put some xml in, put some binary in, futz around with the connections between them, get a MIME package back. Then I can send it. Makes sense to me. Another model has no packaging API at all. Instead we create an outer XML document that points to our original XML and to the binaries. Once we have the outer document we can just "send it" and the packager layer will deal with the MIME bit. We never think about MIME except one brief moment when we configure the sender. The first time we do this second model we have to futz with connections, making our original XML point to other parts of the enclosing document. But the second time we "get it" and create the outer document straight away. At first the extra wrapper sounds like yet more goop, but XML land has infinite goop anyway. The extra goop can also be used as a manifest, meta-data on the binaries so we can talk about their properties behind their back. So after the first time, this approach makes sense to me as well. Now as far as I can tell all this babbling about "infoset" amounts to creating this outer XML document. The outer doc is the container that we pour our XML control doc and the binaries into. We could have a MIME container and I would be just as happy. I am confident that the spec could be defined adequately with MIME on the outside, but the people who are moving this want the XML on the outside. Down the road we'll probably thank them: we will be able to push the outer XML document through transports that don't use MIME without re-writing our apps. Hope this is correct and helps. John. At 09:29 AM 11/11/2003 -0800, Jacek Kopecky wrote: >Anish, > >are you trying to say that you want your application to use the >inclusion part of MTOM to avoid having to specify a referencing scheme >and still to be able to transfer repeating binary data optimally? > >Your application is free to do that, except that if it then uses SOAP, >the SOAP layer doesn't provide a way to specify anything but the infoset >of your message, so I'd imagine you'd put the binary chunks in headers. >The proposed Representation header would be suitable for this, wouldn't >it? 8-) > >IOW, SOAP doesn't know about anything external to the infoset of a >message, and MTOM doesn't try to change that. Of course one could devise >a binding that had a feature of transporting additional parts and a >property containing those additional parts, and that's the SwA approach, >but since the processing model is unclear, PASWA (and subsequently MTOM) >chooses the other approach of everything in the infoset. > >Hope it helps to clarify things, > > Jacek Kopecky > > Systinet Corporation > http://www.systinet.com/ > > > > >On Fri, 2003-11-07 at 19:32, Anish Karmarkar wrote: > > Gudge, > > > > We have already accepted use case UC6 [2]. It seems to me that this > > requires that we allow multiple references to the same attachment. > > > > You have suggested that Representation header can be used for this > > purpose. I don't see how this will work (possibly because of not > > understanding exactly what you meant). > > > > For example, I may have the following XML fragment to be send inside a > > SOAP env: > > > > <foo> > > <bindata1>...</bindata> > > <bindata2>...</bindata2> > > <foo> > > > > Both bindata1 and bindata2 have the exact same binary content. > > I can include the data in the MIME part with content-id > > "1234@example.org" and send the following (along with the right MIME > parts): > > > > <foo> > > <bindata1> > > <xbinc:Include href="cid:1234@example.org"/> > > </bindata1> > > <bindata2> > > <xbinc:Include href="cid:1234@example.org"/> > > </bindata2> > > > > If I am not allowed to do this, then the binary data has to be > > replicated in two MIME parts (defeats the purpose of optimization). > > > > I don't quite see how Representation header fits the bill. To use the > > Representation header, I have to change the original infoset that I > > wanted to send (by inventing a application specific mechanism of > > referring to the URI whose content is carried by the Representation > > header) -- which means it is no longer just optimization. > > > > For example I can do the following: > > > > <foo> > > <bindata1 myhref="http://example.com/bindata"/> > > <bindata2 myhref="http://example.com/bindata"/> > > </foo> > > > > where, "http://example.com/bindata" is the value of the "URI" attribute > > on the Representation header element. > > > > Did I correctly infer what you were trying to say about how > > Representation header can be used? If so, I don't think it fits the > > bill. If not, can you please explain what you meant. > > > > Thx. > > > > -Anish ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX: (650)-857-5100
Received on Tuesday, 11 November 2003 13:52:08 UTC