W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Processing which is not triggered by blocks?

From: christopher ferris <chris.ferris@east.sun.com>
Date: Sat, 21 Jul 2001 08:36:00 -0400
Message-ID: <3B597730.9A59D7A4@east.sun.com>
To: Glen Daniels <gdaniels@macromedia.com>
CC: xml-dist-app@w3.org
My personal take is that this should be permitted. It seems 
equivalent to the case where a processing intermediary does 
process some blocks and then performs some unrelated action (say adding
another block as in the signing example you cite). In the case
you cite, the message simply has no targetted blocks for it.



Glen Daniels wrote:
> In a conversation today (well, yesterday :)) the following issue came up,
> which I would appreciate the group's input on.
> Is it possible for a node (say an intermediary) to perform processing on a
> SOAP message purely as a result of receiving the message, and not because
> any particular blocks in the message are targeted at that node?
> For instance, I can imagine a digital signature intermediary whose job is
> simply to sign any message it receives and forward it, with an extra trailer
> block containing the signature, to a fixed endpoint for which it acts as a
> proxy.  Although our model for this sort of thing has traditionally
> contained a header block targeted at the intermediary to trigger this
> processing, it seems to me that there may be nothing which actually requires
> such a block.
> This would also make the case for the "fault on mustUnderstand blocks which
> are targeted elsewhere" easier to explain, since the endpoint could simply
> perform this (or any other custom) processing as a part of its standard way
> of dealing with messages.
> So, what do you think?  Is it OK for a processor/node to do work without
> explicitly being told to do so by a block?  And if we think it is, should we
> call that out in the processing model?
> --Glen
Received on Saturday, 21 July 2001 08:37:44 UTC

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