- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 3 Sep 2001 14:02:43 -0400
- To: Mark Jones <jones@research.att.com>
- Cc: henrikn@microsoft.com, jones@research.att.com, xml-dist-app@w3.org
Kind of related...how are people treating the actor="" attribute? 1 - the same thing as no actor attribute at all 2 - it will match everything 3 - it will match nothing 4 - it's just like any other URI -Dug Mark Jones <jones@research.att.com>@w3.org on 09/03/2001 12:39:15 PM Sent by: xml-dist-app-request@w3.org To: henrikn@microsoft.com, jones@research.att.com, xml-dist-app@w3.org cc: Subject: RE: Issue 71: Additional actors > Subject: RE: Issue 71: Additional actors > Date: Fri, 31 Aug 2001 17:21:24 -0700 > From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> > To: "Mark Jones" <jones@research.att.com>, <xml-dist-app@w3.org>, > <mnot@mnot.net> > Putting aside the question of why a sender would want to put something > in the message that must not be understood, it seems to me to be better > dealt with using encapsulation as this does not put us in a situation > where we have to redefine what "understand" means. Mark Nottingham captured pretty well the very common case that I had in mind, where 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. <s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope"> <s:Header> <a:whatever xmlns:a="http://www.example.org" id="foo" s:actor="http:/wherever/this/actor/will/never/match"> ... </a:whatever> <b:thisDoesSomething xmlns:b="http://www.example.org"> <blah ref="#foo"/> </b:thisDoesSomething> </s:Header> <s:Body> ... </s:Body> </s:Envelope> I think this is a common enough case to warrant a standard URI, rather than having lots of ad hoc URI's with the same semantics. Mark
Received on Monday, 3 September 2001 14:03:20 UTC