Re: Proposed resolution for issue 440

On 6 Nov 2003, at 16:40, Martin Gudgin wrote:
>>
>>>> MTOM provides one approach to attachments but I fail to see why it
>>>> shouldn't be composable with alternative mechanisms.
>>>
>>> Because the alternatives are not architecturally sound.
>>>
>> That's quite a claim. MIME based systems have been
>> functioning quite well without MTOM for some time now...
>
> I'm not claiming MIME itself is not architecturally sound. I'm claiming
> that using
> MIME for SOAP in the absence of an infoset view is not architecturally
> sound.
>
Thanks for clarifying, can you define what you mean by architecturally 
sound ? Many existing B2B systems do exactly that in, what seems to me, 
an architecturally sound manner.

>>
>>>> What gets broken in MTOM by allowing this flexibility ?
>>>
>>> The fact that the entire message is not an infoset.
>>
>> And that's a problem for MTOM because ... ? Where you want
>> the MTOM abstraction to apply then you can use the MTOM
>> facilities, where that isn't important then you can use
>> something else. Why does it have to be all or nothing ?
>
> SOAP deals in messages that are infosets. If it's outside the infoset
> SOAP doesn't know about it.
>
That doesn't require MTOM to actively prevent inclusion of anything 
outside the infoset. It can just not talk about it.

Here's an example. I have a SOAP message that includes an MTOM 
reference to a purchase order in XML format. The purchase order 
includes an application specific reference to some documentation in the 
form of a HTML document. The HTML document includes an image. My 
application wants to bundle the whole lot together and send it. Why 
should MTOM force me to create an Include reference to the HTML 
document and associated image inside the SOAP message ?

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.