- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Fri, 31 Oct 2003 08:09:54 -0500
- To: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Cc: www-ws-desc@w3.org
> > Yet another is being able to restructure and distribute the
> > service/ultimate receiver at run time (as compared to design time). For
> > example, a SOAP message may contain a document to print. The document
> > may need to be rasterized first. This is likely to be done by the
> > ultimate receiver; but in some settings it may be rasterized instead by
> > an intermediary. It will help if the document is targeted to a role that
> > may be played by the ultimate receiver or an intermediary.
>
> Nope, don't like this one either. :) Just as a digsig intermediary may
well
> sign the body, a rasterizing intermediary might rasterize it. Such an
> intermediary MAY drop in a header which indicates that the rasterization
was
> done at such-and-such a node (and your account with rasterizer.com was
> charged $0.00003), but even that is sideband data which your actual
> application (printing the document) doesn't strictly need.
Just to be clear (haven't had coffee yet) - in this case the ultimate
reciever needs to accept either an unrasterized document and do the work
itself, or a rasterized one. This will typically be indicated in the body
data itself (i.e. an <xsd:choice> between <doc> and <rasterizedDoc>), but
even in the case where the "flag" is a header, you still shouldn't be
thinking of that as "application level" data. For instance, there might be
a header in the message which indicates that the body has been encrypted -
that header will trigger processing by the decryption extension
("infrastructure" code), not by the actual application.
--Glen
Received on Friday, 31 October 2003 08:09:55 UTC