Issue 71: Additional actors

[ I have an action item to resolve issue 71 regarding definition of
extra actors. Upon reflection, there are arguments against both of
the proposals below ('None', because it really isn't essential, and
'All', because it enlarges the semantics of actor). Despite this, I'd
like to see if anyone else thinks they might be useful before closing
the issue. ]


Currently, SOAP Version 1.2 defines a specific value for actor,
'next', and also specifies the semantic of the absence of an actor:

  The special URI
  "http://www.w3.org/2001/06/soap-envelope/actor/next" indicates that
  the SOAP header block is intended for the very first SOAP node that
  processes the message. This is similar to the hop-by-hop scope
  model represented by the Connection header field in HTTP.

  Omitting the SOAP actor attribute indicates that the SOAP header
  block is targeted at the ultimate SOAP receiver.

The Abstract Model identifies these as 'Next' and 'Final',
respectively. It also introduces a third pre-defined value, 'None'.

  An untargeted block marked with None is useful for declarative
  information that is referenced by another block or blocks.  It is
  guaranteed not to be removed and can even be referenced by blocks
  which are targeted at different processors.

The working group should discuss the utility of adding 'None' to SOAP
Version 1.2, using the Abstract Model definition as a proposal. 

[In practice, everyone could define their own URI for 'None', and it
would be functional, because its purpose - not matching - would be
served. However, there may be some utility in settling on a normal
value for 'do not process me.']


Additionally, the working group should consider whether there are
other useful actors that should be standardised. While the actor
attribute can contain any URI, and is therefore extensible, there may
be value in identifying other generally useful actors.

For example, past discussions [1] have touched upon 'All', meaning
that any SOAP node may process the block (or, if mustUnderstand is
flagged, that all SOAP nodes must process the block).

[This has a semantic similar to 'next-and-reinsert', which may be
useful for 'advisory' modules which would otherwise need a
module-specific way to determine whether to reinsert or not. There
may be better, albeit more verbose, ways to control reinsertion - a
Module, for instance.]



[1] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Apr/0088.html
    (I have seen this elsewhere, but this was all that I could find
    presently, and is, alas, Member-confidential.)

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 30 August 2001 18:39:40 UTC