Issue - 82.3 - Propsoal for vote

[Rania Khalaf <rkhalaf@watson.ibm.com>]

Here we go again. Incorporated some changes based on comments received 
from TC members during the week.
-------------------------------------------

Hi everyone,

First phase of two-phase voting (content, then spec wording). I've
merged the previously named 'proposed changes' section into the main
text of this mail since this is the proposal.

--------------------------------------------------
AP1.1 refactoring, start.
-------------------------------

(add motivation in phase 2)

(consider what old text to bring in from spec and how to modify it to
introduce various aspects, especially regarding clarifications about
initialization of correlation sets and variable omission in phase 2).

ProfileURI:

- urn:oasis:names:tc:wsbpel:2.0:abstract:ap11

Base Language subset
_____________________

.. This profile restricts the base in the following manner:

*  Allowing all expressions to be opaque except joinCondition. Please
note that the joinCondition is based on the transition conditions on
the incoming links. If the joinCondition is missing its default
value is the disjunction of the status of the incoming links.

* The only attributes that can be opaque are the attributes
"variable", "inputVariable", "outputVariable", "part" and "toVariable"
attribute of "fromPart" element, "part" and "fromVariable" attribute
of "toPart", on receive/invoke/reply/onMessage/onEvent (Note: bug fix
based on Issue 97: fixing the consistency for elements onMessage and
onEvent. "from/toPart" are new in BPEL2.0).

* Allowing opaque activity, as a bug fix for the two reasons
below. Note that its use elsewhere is superfluous since completions
in this profile allow adding new BPEL activities anywhere:

    -Allows for hiding an activity that is the source or target of
    -links.  Allows for using omission-shortcut in places like fault
    handlers etc (This had led to Issue 91).


* Activity <exit > is not allowed.

* Uses omission-shortcut for the opaque tokens above (allowed by all
   APs anyway).

(* sidebar to TC : 'getVariableData' and 'get VariablePropery' are
allowed. No need to mention this above since everything not restricted
is allowed.)



Base Completions subset
_________________________

The intent of this profile is for a valid completion to follow the
same interactions as the abstract process with the partners of the
abstract process, and possibly perform additional steps relating to
new partners. Therefore, a completion should not change the presence
or order of interactions already in the abstract process, nor perform
additional interactions with the partner links defined in the abstract
process.

Places where new activities may be added are not explicitly defined in
processes in this profile. The permitted executable completions of
abstract processes in this profile include both 'Opaque Token
Replacement' and 'Addition of BPEL Constructs', but subsetting those
to provide guildelines to meeting the intent above in a simple way, such 
that:

-In any executable completion:

     * New activities (including those created to replace opaque
       activities) MUST NOT interact with partnerLinks already defined
       in the abstract process. Note that these restrictions still
       allows for adding new interactions with new partnerLinks (ie:
       partnerLinks added in the executable completion but not present
       in the abstract process).

     * The target of a newly created link MUST NOT be an activity
       existing in the abstract process during executable
       completion. Note that adding such a new target would cause the
       corresponding join condition to change and that would violate
       the completion rules of the base (ie: cannot modify a non-opaque
       existing value). This restriction does not affect adding links
       to new activities (that are not replacing opaque activities).

     * It is not allowed to add copies in assigns whose 'to' is any of
       the EPRs of the partnerLinks defined in the abstract process,
       because that is equivalent to removing subsequent interactions
       with that partner.  Remember that 'opaque token replacement'
       also replaces opaque tokens omitted through the
       omission-shortcut.

     * The lexical parent BPEL construct of an existing BPEL construct
       (including activities) in the Abstract Process MUST NOT be
       changed during execution completion. Hence, the nesting
       structure of composite activities around any activity in an
       abstract process is unchanged in any legal
       completion.
              Examples:
              ---------
              OK: add a variable or a partner link to an existing
              scope, even though that scope is the parent of activity
              A.
              OK: add a new link def to an existing flow.
	     Not OK: add a 'while' around the existing activity A
              whose parent is B.
              Not OK: add a new scope around an existing variable
              definition whose parent is an existing scope S.


     * One MUST NOT add:

         * New branches to an existing if-then-else activity, unless it
           has no else branch AND the new branch is added after all
           existing branches.
         * New branches to an existing pick activity.
         * New fault, compensation, or termination handlers to an
           existing scope. However, they may be added at the process
           level.
         * <exit>


         * <throw> - only in cases where the exception will leak
           outside of the highest *newly added* activity in the parent
           hierarchy of the <throw>. However, one may add a <throw>
           nested within a newly added activity A, as long as the
           excetion is caught by A or its descendants and not rethrown
           outside of A.

      * For a newly added activity, any faults it throws must be caught
        and handled without leaking to the activities of the AP. (see
        throw above).


Note that one way one could still change the order of interactions is
by changing the value of a variable used in a condition that affects
branching (transition condition, if-then, while condition, etc), in
such a way that the new effective branching behavior is in direct
conflict with what was done in the abstract process. In this profile,
we will not restrict writing to variables in a strict manner, but
provide this note as an advisory restriction.