Re: Proposed resolution for issue 440

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