Proposal for issue 107:
Language extensions required for
abstract processes
The language extensions consist of
opaque 'placeholders'. 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 decrease the allowed level of opacity at its discretion, but may
not increase it. The functions of these opaque placeholders are
explained below:
[1] Opaque expressions- Needed in
particular for opaque assignment, opaque transition conditions, opaque
query expression. Opaque assignment is used for capturing variable
creation/modification in a yet-to-be-concretized mechanism/fashion.
[2] Opaque activities- Hide a
concrete BPEL activity, such as a structured activity, a lifecycle activity
(ie.receive-start) or even just an
"empty". They may also be used as a source or a target of control links.
[3] Opaque attributes- Hide a concrete
BPEL attribute. For example in invoke, receive or reply activities
opaque attributes are specifying that variables need to be filled in by or when mapping the partial process
specification to a fully executable artifact.
------
Question arising from discussion : if
all attributes are opaquable, and all opacity can be shown by omission,
this means all attributes become optional. Is this desirable ? (an "easy fix" is said to be available)