Issue 107 - Proposed resolution to vote

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)

wsbpel message