We did not identify
compelling examples for opaque attributes (and Satish's
summary correctly points that out). Would you please comment my
concerns explained below?
Excerpt from your
document:
·
Opaque attributes are
needed
·
In a receive activity for
defining input variables. If we omit an input variable in an Abstract BPEL
process definition then it means that there is no inputVariable in this receive.
If an Opaque placeholder is used for the input variable, then it means that the
process designer has to specify this variable. Hence there is no ambiguity of
deliberate omission because the attribute is not needed versus implicit missing
of details that need to be filled in.
Attribute
inputVariable of a receive step (which is specified within an abstract process)
may be omitted if it is not used in any subsequent expression, activity, etc.
So, it must be specified if it is used. I do not understand how opaque
attributes help in this case.
·
In a BPEL activity with an optional
attribute, which has a default value, if we omit that attribute in an Abstract
BPEL process definition then it means the default value of that attribute will
be used. If an Opaque placeholder
is used for the attribute, then it means that the process designer has to
specify this value. Hence there is no ambiguityof whether the default value
should be used or an explicit value needs to be specified.
Wouldn't it make the
specification much simpler if we defined a particular attribute as mandatory and
allowed only two values (e.g. "yes" or "no".)? Defining an optional attribute
with a default value is just a convenience. If we think that this may lead to
ambiguity then we should avoid this designing approach. In that case we do not
need yet another BPEL element/attribute/value.
Can
you list other examples that call for opaque attributes?
Regarding
issue 99: Abstract
processes cannot be instantiated and executed - therefore "lifecycle"
activities play little or no role for abstract processes. Also the BPEL
specification is saying that BPEL executable processes must contain at least one
"start activity". So opaque activity is not really necessary in
this case (issue 99) - the specification is clear about places which need
to be further specified (or concretised) when mapping an abstract process to an
executable process.