RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 06 November 2003 20:31
> To: Martin Gudgin
> Cc: Xml-Dist-App@W3. Org
> Subject: Re: Proposed resolution for issue 440
> 
> On 6 Nov 2003, at 14:33, Martin Gudgin wrote:
> >>
> >> For my part I think that requiring every attachment to have a 
> >> corresponding xbinc:Include is too restrictive because it would 
> >> effectively disallow use of existing attachment techniques.
> >
> > I see this as a feature not a bug.
> >
> Interesting.
> 
> >> 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.

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

Gudge

<SNIP/>

Received on Thursday, 6 November 2003 16:40:17 UTC