Re: Proposed resolution for issue 440


   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, 
our original XML point to other parts of the enclosing document.  But the 
time we "get it" and create the outer document straight away.  At first the 
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 
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.

At 09:29 AM 11/11/2003 -0800, Jacek Kopecky wrote:

>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
>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
> > "" and send the following (along with the right MIME 
> parts):
> >
> > <foo>
> >    <bindata1>
> >      <xbinc:Include href=""/>
> >    </bindata1>
> >    <bindata2>
> >      <xbinc:Include href=""/>
> >    </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=""/>
> >    <bindata2 myhref=""/>
> > </foo>
> >
> > where, "" 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:
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