Re: Proposal for generic MTOM format

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).

Cheers,


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