- 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
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: > > 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? > It makes sense at a theoretical level but I'm not sure it makes sense at a practical level. Marc. -- Marc Hadley <marc.hadley@sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 7 May 2003 15:03:17 UTC