Issue - 111 - Extension Activity Syntax : evaluation / testing criteria

[Alex Yiu <alex.yiu@oracle.com>]

Hi, all,

Here are evaluation / testing criteria for Extension Activty Syntax design choice:

(1) How the attributes and sub-elements specific to an extension activity look like:

(2) How an extension activity (of NS1) is extended by the extension attributes and elements (of NS2)?

(3) How to make an extension activity as an activity container?

(4) How the above syntax constructs are weaved with standard activity attributes and elements?

It may be too difficult to imagine all four constructs mixed with each other. I can use one example to sum it up: the <forEach> activity from Issue 147 with some extra extensions.

-------------------------------------
<bpel:forEach
              name="myForEach" suppressJoinFailure="no"
              indexVariable="int" parallel="yes"
              bpeldesigner:nodeId="123" >
       <superLink:source multicastLink="mySuperLink3" />
       <bpel:targets>
             <bpel:target linkName="myLink2" />
       </bpel:targets>
       <bpel:iterator>
             <bpel:startCounterValue> 1 </bpel:startCounterValue>
             <bpel:finalCounterValue> 4 </bpel:finalCounterValue>
       </bpel:iterator>
       <bpel:scope name="innerScope">
          ...
       <bpel:scope>
</bpel:forEach>
-------------------------------------

(1) Activity Specific Attributes and Sub-Elements (in BLUE): e.g.: "indexVariable", "parallel" and <iterator>.
(2) Extension attributes and elements (in BROWN): e.g.: "bpeldesigner:nodeId" and <superLink:source>
(3) Extension Activity as an activity container (in GREEN): e.g.: <forEach> contains <scope>
(4) Standard Attributes and Elements (in PURPLE): e.g. "name", "suppressJoinFailure", <bpel:targets>

I would suggest that: pretending that we had not passed Issue 147 yet; we should try to model the above <forEach> activity with different extension activity proposals and compare them and see how they look like.

Extra note:  This is NOT a pure cosmetic issue.
IMHO, whether the extension activity syntax looks fundamentally different from a standard activity is one of my key concerns. If they looks too different, we are digging a hole for ourselves by making un-necesesarily difficult for BPEL designer tools / compiler / management console to support these two kinds of syntax, while we were given a chance to unify their syntax (relatively speaking).
(Hence, Yaron's original proposal is the best so far, IMHO)



Regards,
Alex Yiu