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

Re: PASWA, Include and Protocol Bindings

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 07 May 2003 15:03:10 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: noah_mendelsohn@us.ibm.com, Mark Nottingham <mark.nottingham@bea.com>, xml-dist-app@w3.org
Message-id: <8BCFEB76-80BE-11D7-A614-0003937568DC@sun.com>

On Wednesday, May 7, 2003, at 14:34 US/Eastern, Martin Gudgin wrote:

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

I was assuming that the Include elements would be retained at the 
Infoset level. Their presence would indicate a logical inclusion of 
some binary data.

>  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:
> 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?
It makes sense at a theoretical level but I'm not sure it makes sense 
at a practical level.


Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 7 May 2003 15:03:17 UTC

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