RE: Issue 71: Additional actors

You can always wrap it into another block like this:

  <s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope">
   <s:Header>
    <c:thisDoesNothing xmlns:c="http://www.noop.org">
      <a:whatever xmlns:a="http://www.example.org" id="foo">
         ...
      </a:whatever>
    </c:thisDoesNothing>
    <b:thisDoesSomething xmlns:b="http://www.example.org">
      <blah ref="#foo"/>
    </b:thisDoesSomething>
   </s:Header>
   <s:Body>
     ...
   </s:Body>
  </s:Envelope>

I am still struggeling for a real-world scenario where we can't leave
the definition of what "mustnotthinkyouunderstand" means to a wrapper
module?

It seems to me that the only purpose of a non-matching actor is to
override the default semantics for a block and say that regardless of
what processing rules that block may have had initially, this is now
nullified and the contents of the block is merely "dead data" without
any processing rules or semantics associated. 

The reason is that in section 2.2 [1] states: "In processing a SOAP
message, a SOAP node is said to act in the role of one or more SOAP
actors, each of which is identified by a URI known as the SOAP actor
name". Furthermore, section 2.3 [2] states that "We say that a SOAP
block is targeted to a SOAP node if the SOAP actor (if present) on the
block matches (see [10]) a role played by the SOAP node, or in the case
of a SOAP block with no actor attribute information item (including SOAP
body blocks), if the SOAP node has assumed the role of the anonymous
SOAP actor."

However, while mustUnderstand has the property that it is up to the
block/module to define what "mustUnderstand" really means,
"mustnotthinkyouunderstand" doesn't and so it is not clear to me what to
do with it: can I apply schema processing to it? What can I use the data
for as it wasn't really for me?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.w3.org/2000/xp/Group/1/08/29/soap12-part1.html#N321
[2] http://www.w3.org/2000/xp/Group/1/08/29/soap12-part1.html#N32D

Received on Wednesday, 5 September 2001 22:26:50 UTC