W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2003

Re: Proposal for generic MTOM format

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Mon, 20 Oct 2003 18:07:08 -0700
Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, noah_mendelsohn@us.ibm.com
To: "John J. Barton" <John_Barton@hpl.hp.com>
Message-Id: <E48DD6CC-0362-11D8-82AF-00039396E15A@bea.com>

I agree. Our generic format (however it's defined) could support all 
references, and we could then chose to nail down the kinds of 
references allowed in our SOAP-specific work (or allow people to nail 
it down in WSDL).


On Monday, October 20, 2003, at 05:29  PM, John J. Barton wrote:

> Mark,
>   Whether the thing is called a "specification" or an "application", 
> we need a thing
> that nails down whether or not the resources can be served out of the 
> message.
> If my box must support opening new sockets and downloading content to 
> process
> the message, I need to know that when we evaluate its feasibility, not 
> shortly after
> someone tries sending it a message.  So I agree that the ability to 
> mix in-message
> and online URLs would be a great thing to have at some level, we also 
> need a level
> that says "only in-message URLs" inside.
> John.
> At 12:30 PM 10/20/2003 -0700, Mark Nottingham wrote:
>> Noah,
>> I can understand your concerns here as a matter of practice, but I 
>> wonder why it's necessary to embody them in the specification. There 
>> may be cases where getting things from the network are desirable, and 
>> I don't see any reason to preclude their use (whether or not that's a 
>> good idea for a particular application is another story, of course).
>> Regards,
>> On Monday, October 20, 2003, at 12:11  PM, noah_mendelsohn@us.ibm.com 
>> wrote:
>>> Anish Karamarkar writes:
>>>>> If we separate out section 3.2 as a part of
>>>>> the separate document which is not SOAP
>>>>> specific, isn't that the same as XInclude
>>>>> with parse="binary"?
>>> I don't think so.  My impression is that an XInclude can reference 
>>> any web
>>> resource, which is a quite weak contract packaging wise.  MTOM, as I
>>> understand it, says:  xbinc:Include must be replaced with the 
>>> resource
>>> representation >>in the multipart MIME  stream in which the reference
>>> occurs<<.   In other words, I see the MTOM serialization (though not
>>> necessarily all embodiments of the abstract MTOM feature) as 
>>> specifically
>>> providing for data packaged together in a single stream.  Indeed, I 
>>> would
>>> argue that if we used generalized include in the MTOM serialization, 
>>> it
>>> should be limited to representations carried in that serialization.
>>> It is
>>> completely unacceptable to have to open a web connection to get these
>>> message parts.
>>> Perhaps this is a reason not to use generalized XInclude in MTOM?  In
>>> other words, if you really mean Web-scale XInclude, with the 
>>> possible need
>>> to open external connections, use generalized XInclude (if it gets to
>>> Rec.)  For local-only include use xbinc:Include?  I can see this 
>>> either
>>> way, but I think its essential that we call out separately the case 
>>> where
>>> messages are self-contained.  Thanks!
>>> Noah
>>> ------------------------------------------------------------------
>>> Noah Mendelsohn                              Voice: 1-617-693-4036
>>> IBM Corporation                                Fax: 1-617-693-8676
>>> One Rogers Street
>>> Cambridge, MA 02142
>>> ------------------------------------------------------------------
>> ______________________________________________________
>> 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 Monday, 20 October 2003 21:13:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC