RE: PASWA, Include and Protocol Bindings

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 06 May 2003 17:59
> To: noah_mendelsohn@us.ibm.com
> Cc: Mark Nottingham; xml-dist-app@w3.org
> Subject: Re: PASWA, Include and Protocol Bindings
> 
> 
> On Monday, May 5, 2003, at 20:36 US/Eastern, 
> noah_mendelsohn@us.ibm.com
> wrote:
> >
> > My key point is:  I don't want the applications to see the Include.
> > Indeed, my understand of PASWA is that the whole point is that 
> > "attachments" are modeled by value as children.  It's not the 
> > doInclude that bothers me, as I said, it's the 
> xbinc:Include element.  
> > That violates the whole notion that PASWA models things by 
> value.  I 
> > think it also
> > raises many, many architectural complexities.   Does a 
> signature sign 
> > the
> > child data or the include element?  Indeed, one of the claimed 
> > benefits of PASWA (and it's one I quite like) is that the 
> infoset can 
> > be carried by bindings that don't play tricks:  our own 
> HTTP binding 
> > can send the character children.
> >
> I find the implications of the above rather disturbing. My 
> mental model of PASWA was of 'logical' inclusion rather than 
> 'actual' inclusion. If the Include mechanism is only a matter 
> for the binding then, unless we introduce the notion of a BII 
> (binary information item), bindings that support attachments 
> will be forced to base64 or hex encode the contents of those 
> attachments prior to passing them on to the 'SOAP layer'. 
> Such a requirement would seriously impact any performance 
> advantage gained from using attachments rather than inline 
> serialization.
> 
> Marc.

Given that the Infoset is a data model, it is difficult to distinguish
between 'logical' and 'actual' inclusion at that level. Certainly at the
serialization level, a SOAP stack that implements PASWA would serialize
binary data as binary bits. However, consider the following case:

A -> B -> C ->D -> E

where C does NOT understand PASWA. The serialization stream would be as
follows:

A -PASWA-> B -SOAP1.2HTTP-> C ->SOAP1.2HTTP-> D -PASWA-> E

So, the ultimate receiver ( E ) gets a PASWA message, but along the way,
it was at some point serialized accordings to the HTTP binding we have
in SOAP 1.2 today.

Does this make sense?

Gudge

Received on Wednesday, 7 May 2003 14:34:57 UTC