Re: PASWA, Include and Protocol Bindings

On Tue, 6 May 2003, Marc Hadley wrote:

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

PASWA is not exactly a way of doing attachments, but rather a way of
serializing the infoset that happens to have cool features like not having
to wait to download GB of data. I agree with Noah that the application
should NOT see the include tags, as I am not sure we should require that
all application should know how to process PASWA, while it is easy to just
declare that this endpoint knows this serialization (and just plug a
serializer/deserializer dedicated to it), wasn't this kind of modularity
one of the benefits of SOAP Version 1.2?

Also one neat part would be that the HTTP binding could use something like
Content-Encoding: x-paswa to declare that the message use this specific
encoding of a SOAP envelope (if we don't want to define another MIME
type).

Regarding the need of re-encode into base64, it depends on the way you
decode the stream, do you want to reconstruct in plain XML and let the
application deal only with std parsers, or do you want to have a specific
parser (based on std XML ones (*)) for PASWA that will do lazy
inclusion/processing? Anyway, base64 encoding is really a no-cost encoding
in terms of CPU, so if it is just a matter of doing it within an
application, and streamed, the cost is minimal and the processing of the
SOAP message is far higher than that.

(*) Note that with more specific parsers, we may have fancier ways of
sending multiple interleaved binary streamed, if we _really_ want
efficiency.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Tuesday, 13 May 2003 09:53:52 UTC