Re: [wsbpel] Issue 107 - Proposal to Vote (updated)

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

Updated Text, Issue 107 (big changes are addition of third paragraph in 
15.1 and addition of last paragraph in Part A. Rest is tweaks).

******

15.1 Language extensions for Abstract Processes

The language extensions consist of opaque tokens which are used as
explicit 'placeholders' for missing details. Note that "opaque" is not
a new semantically meaningful construct but a syntactic device for
indicating incompleteness. As such, "opaque" entities have no
semantics of their own.

There are three kinds of opaque placeholders: expressions, activities,
and attributes. A usage profile may restrict the kinds of opaque
tokens allowed at its discretion.  For example, a profile could
specify that it allows only opaque activities, but not opaque
expressions and attributes, or a profile could specify that it allows
all attributes to be opaque except the "partnerLink"
attribute. However, a usage profile may not expand it above what is
allowed by the "common base". For example, a profile cannot specify
that it allows <faultHandler> elements to be opaque.

Each opaque token is a placeholder for a corresponding executable BPEL
construct, as will be described below. That construct can be different
in each executable completion an abstract process. For example, an
opaque activity in an abstract process could represent an <assign> in
one executable process and an <empty> in another executable process
that are both valid completions of the abstract.

-Under the 'common base' section
---------------------------------

Three types of opaque tokens are allowed in abstract processes:
activities, expressions, and attributes. The functions of these opaque
placeholders are described below, with examples:

Part A - Opaque activities:

An opaque activity is an explicit placeholder for exactly one
executable BPEL activity, not counting any activities that could be
nested within that executable activity.  This executable activity
carries over all non-opaque elements/attributes defined by the opaque
activity it replaces. It also replaces any opaque attributes or
expressions that are part of that opaque activity.

An opaque activity has the same standard elements and attributes
common to all BPEL activities (see spec section 11.1 and 11.2).  An
opaque activity has the following form:

<opaqueActivity standard-attributes>
standard-elements
</opaqueActivity>


One example of using opaque activities could be the creation of a
process template that marks the points of extension in a process.
Another is when creating an abstract process from a known executable
process and wanting to hide an activity that is a join point for
several links. If that activity, on the other hand, had just been an
unlinked activity in a 'sequence' it could have just been omitted from
the resulting abstract process.

At first glance, it seems that this could instead be done using
<empty>. The difference is that <empty> explicitly says "nothing
happens here," whereas <opaqueActivity> is really saying "something
happens here, but it's hidden on purpose".

The reason for making an opaque activity a placeholder for one
activity (and not zero or more) is that in the case of one activity
there is no ambiguity regarding carrying over any attributes or
elements defined on the opaque activity, or in its relation to its
parent and sibling activities.


A.1 Opacity of activities allowed in the base:
Opaque activities are allowed.

PART B - Opaque expressions:

An opaque expression is a placeholder for a corresponding executable BPEL
expression.

An example usage of an opaque expression is that of copying a hidden
value into a known variable.  Opaque assignment can be used to express
non-determinism: the obvious case being a process that needs to show a
decision point with alternative outcomes without specifying how the
decision is reached. In this case the expressions that constrain each
branch may need to be left unspecified, but it may also be convenient
to make a specific value or quantity such as a price threshold
unspecified, so that explicitly specified conditions relative to the
threshold become non-deterministic as a result of the threshold value
being unknown.

All expressions in BPEL, and their corresponding opaque representations are
listed below:

1-Boolean valued expressions:

-Transition Condition:
<transitionCondition expressionLanguage="anyURI"? opaque="yes"/>
-Join Condition:
<joinCondition expressionLanguage="anyURI"? opaque="yes"/>
-While Condition:
<condition expressionLanguage="anyURI"? opaque="yes"/>
-Switch Case Condition (editors’ note: reflect new if-then-else syntax) :
<case>
<condition expressionLanguage="anyURI"? opaque="yes"/>
activity
</case>

2- Deadline valued expressions:

-Until element of onAlarm and wait:
<until expressionLanguage="anyURI"? opaque="yes"/>


3- Duration valued expressions:

-For element of onAlarm and wait:
<for expressionLanguage="anyURI"? opaque="yes"/>

-repeatEvery element of onAlarm:
<repeatEvery expressionLanguage="anyURI"? opaque="yes"/>

4- Opaque From-Spec in Assignment:

(Issue 103)

<from expressionLanguage="anyURI"? opaque="yes"/> is allowed, and
represents hiding any of the forms of the 'from-spec'.

-Opaque assignment (<from opaque="yes"/>) is used for capturing
variable creation/modification in a yet-to-be-concretized
mechanism/fashion. See section 9.3.

(editor’s note: update with any new expressions from any new activities)

B.1 Opacity of expressions in the common base:

All BPEL expressions are allowed to be opaque. The generic form of
opaque assignment is also allowed.


PART C - Opaque attributes:

An executable BPEL attribute used in an abstract process can have an
opaque value, thereby hiding the attribute's value. We refer to these
as "opaque attributes"

For example, an opaque variable attribute in a receive activity hides
where the data is stored once the corresponding message is received.

The reserved value "##BPELopaque" shall be made available for use as
the value of any BPEL attributes in a BPEL abstract process that can
be opaque. (editor’s note: this may change to make sure have a value
for attribute types based on XSD.

C.1: Opacity of attributes in the common base:
All BPEL attributes are allowed to be opaque in the common base.


---------

Rania's note on spec editing :
if 82 passes, then A.1, B.1, and C.1 could go in the bullets of the
common base where it says that it depends on 107.