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