Re: PROPOSAL: Drop interface/operation/(input|output)/@headers

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