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

Re: Proposed resolution for issue 440

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 06 Nov 2003 18:22:06 -0500
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Message-id: <09AA56C2-10B0-11D8-8C8B-0003937568DC@sun.com>
On 6 Nov 2003, at 17:59, Martin Gudgin wrote:
>> 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.
> To me archtecturally sound means that it composes well with the SOAP
> processing model. I don't believe any of the existing attachment
> technologies fit the bill. Hence MTOM.
'Composes well with' or 'is defined solely in terms of'. You seem to be 
leaning towards the latter. Things outside the SOAP processing model 
can still compose well with it.

>>> 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 ?
> This is exactly the situation the Representations header is designed to
> address.
But for this use case I don't *need* the representation header. 
Requiring all attachments to be referenced from the message would 
require me to use it but only to fulfill an unnecessary restriction.


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

Received on Thursday, 6 November 2003 18:22:09 UTC

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