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

Multicast MEP and multiple body actors

From: Paul Denning <pauld@mitre.org>
Date: Thu, 20 Dec 2001 12:20:31 -0500
Message-Id: <5.1.0.14.0.20011214143133.03da96a8@mailsrv1.mitre.org>
To: xml-dist-app@w3.org
If we assume a message exchange pattern where a SOAP message is sent to 
multiple recipients, as in usage scenario S2 [1],
can we define a body with multiple body blocks where each body block 
contains a different actor.

xmlns:env="http://www.w3.org/2001/12/soap-envelope"
xmlns:app="http://myapp.example.org"
<env:body>
   <app:part env:actor="A">...</app:part>
   <app:part env:actor="B">...</app:part>
   <app:part env:actor="C">...</app:part>
   <app:part env:actor="D">...</app:part>
   <app:part env:actor="E">...</app:part>
</env:body>

If we start out with five nodes as the ultimate recipient of the message, 
then each node can process one body block (one actor per node).  If one 
node goes down, then the role of the failed node can be transferred or 
delegated to another node (in some unspecified way), such that one of the 
four remaining nodes would process two body blocks (its original role, and 
the role of the failed node).

I don't think the schema for SOAP 1.2 prohibits use of actor within the 
body.  Should we explicitly discourage use of actor in the body?  Emphasize 
more strongly that SOAP processors are not required to process actor 
attributes (if used) within the body?
Do we want to force application designers to use their own namespace for 
the body actor processing, for example

xmlns:env="http://www.w3.org/2001/12/soap-envelope"
xmlns:app="http://myapp.example.org"
<env:body>
   <app:part app:actor="A">...</app:part>
   <app:part app:actor="B">...</app:part>
   <app:part app:actor="C">...</app:part>
   <app:part app:actor="D">...</app:part>
   <app:part app:actor="E">...</app:part>
</env:body>

[1] http://www.w3.org/TR/xmlp-scenarios/#S2

Paul 
Received on Thursday, 20 December 2001 12:21:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC