Issue 2 - A modest proposal

[Maciej Szefler <mbs@fivesight.com>]

Ivana,

Keeping in mind the understandable desire by certain members of the committee to make these things macros and your desire to address this issue, what do you think about the following approach:

We create the notion of a "parameterized scope" an "abstraction" of a
scope. These scope abstractions must be declared (in a scope, or in
another abstraction), using a syntax nearly identical to that of scopes:
<scope>
   <variables>?
   <correlationSets>?
   <partnerLinks>?
   <faultHandlers>?
   <compensationHandlers>?

   <scopeDeclerations>
     <scopeDeclaration typeName="typeName">
       <parameters>
	 <param name="paramName" {message,element,}type="" />*
       </parameters>
       <faultHandlers?>
       <compensationHandlers?>
       <variables?>
       <correlationSets?>
       <partnerLinks?>
       <any-activity>
     </scopeDeclaration>
   </scopeDeclerations>
   ...
</scope>

To use a scope abstraction we have a new "concretion" activity:
<SCOPE name="scopeName" type="typeName">
   <arg paramName="paramname" replacement="visibleVarName" />*
</SCOPE>

So the construction:
<scope>
  <scope name="foo">
     <empty/>
  </scope>
</scope>

is equivalent to;

<scope>
  <scopeDeclerations>
    <scopeDecleration typeName="fooType">
      <empty/>
    </scopeDecleration>
  </scopeDeclerations>

  <SCOPE name="foo" type="fooType" />
</scope>


In the other direction, the concretion <SCOPE name="foo" type="bar"  can
be defined simply in terms of an XML re-write rule: it is equivalent to
writing <scope name="foo"> with the body found in scopeDecleration of
typeName="bar" subject to renaming of names found in the <parameters>
block to the names specified in the <arg> elements. In order to keep
this a pure "macro" we have to disallow recursion, and we must disallow
free variable or link names in the scope declarations (i.e. parameters
are the only way to pass data around). 

To do functions: 

<scope> 
   <scopeDecls>
      <scopeDecl typeName="multiply">
          <parameters>
             <vararg name="x" ../>
             <vararg name="y" ../>
             <vararg name="product"  ../>
          </parametrs>
          <assign>
             <to variable="product" />
             <from>$x * $y</from>
          </assign>
      </scopeDecl>
   </scopeDecls>

   <scope>
      <variables>
        <variable name="a1"/>
        <variable name="a2"/>
        <variable name="a3"/>
        <variable name="a4"/>
        <variable name="a5"/>
        <variable name="a6"/>
      </variables>
      <sequence>
          <SCOPE name="s1" type="multiply">
             <vararg paramName="x" varName="a1" />
             <vararg paramName="y" varName="a2" />
             <vararg paramName="product" varName="a3" />
          </SCOPE>
          <SCOPE name="s2" type="multiply">
             <vararg paramName="x" varName="a2" />
             <vararg paramName="y" varName="a3" />
             <vararg paramName="product" varName="a4" />
          </SCOPE>
          <SCOPE name="s3" type="multiply">
             <vararg paramName="x" varName="a4" />
             <vararg paramName="y" varName="a5" />
             <vararg paramName="product" varName="a6" />
          </SCOPE>

      </sequence>
   </scope>
</scope>


The appeal of this approach is that it gives you parameterization, and
can be done completely on the XML re-writing level (simple XSLT can do
it) without introducing any new "native" BPEL constructs.

If you want to get even fancier, you can also have link parameters. 

-maciej

This is a digitally signed message part