Re: Issue 71: Additional actors

Henrik,

Again, you are confusing the issue here. There may be cases
where a block has no target actor, that is merely referenced by
some other block or blocks that do. It is not the intent to have 
a block behave in a manner inconsistent with other blocks. Rather,
it is to enable the case where a block exists where its originator
specifically wants that there not be an even accidentally targetted
actor that might mistakenly process the block simply because the
originator chose an actor name that happened to match an actor
name that some SOAP node thinks means something else entirely.

I think that the proposed 'none' actor is consistent with the
SOAP process model and solves the problem.

Cheers,

Chris



Henrik Frystyk Nielsen wrote:
> 
> I am not saying whether we can or not or whether this is a good idea or
> not but rather trying to understand what the semantics are. The reason
> why I might be confused is the examples in [1] where MarkJ says that
> 
> "... you have a block that is referenced by some other
> block.  A module that employs such headers would generally be designed
> to dispatch off of the 'thisDoesSomething' while simply referencing the
> 'whatever' block.  By targeting 'whatever' at an actor URI that is
> guaranteed not to match, the module doesn't have to worry that the final
> destination may happen to dispatch (possibly for some other purpose) on
> a 'whatever' block."
> 
> To me this does seem like replacing the existing semantics of a block in
> order for it to behave in some other way than what it normally does. Is
> this not the case?
> 
> >It seems to me that this issue is not understanding, but
> >acting. Mark is asking for a canonical actor URI that can be
> >used to signify that "this block has no target actor" such
> >that it can never be mistaken for a block which MUST be
> >processed (such as in the case where the block is referenced
> >by another block that may have a specific actor.
> 
> Henrik
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Sep/0004.html

Received on Thursday, 6 September 2001 13:38:28 UTC