Ron, you raised several good questions. I'd like to
comment on the last part of your email.
Ron wrote:
> Which brings up another question: should we ban, in
<from> general expressions, the ability to
> indirectly refer to variable names? (I vaguely remember that Arkin (?)
raised this issue, possibly in
> another context, but I can't find it in the issues list.)
I think there are a couple issues here. One is the
tradeoff between the safety and static-checking ability of a more restrictive
static language versus the flexibility of a more dynamic language. I am not sure
where BPEL should fall on this continuum. However, I think there is a second
issue lurking which is whether or not XPath is the most appropriate way to
specify general expressions in BPEL. I'd like to discuss the latter
issue.
I think that if we decide to go with the more
restrictive, static-checking friendly approach, we should reconsider whether
XPath expressions are really the best way to refer to things like variables and
links. To me, the advantages of using XPath expressions for a general
expressions in BPEL is that it is a standard language that already has people
that understand it and can work with it as well as the potential for reusing
XPath tools. XPath has been extended in BPEL to support bpws:getVariableData(), bpws:getVariableProperty(), and
bpws:getLinkStatus(). It has also been restricted, through the
constraint that a joinCondition consist of only boolean operators and the
bpws:getLinkStatus() function. A potential additional restriction is the one
that Ron refers to above, and I suspect there may be others along these
lines. The result is a grammar for
expressions that is neither a superset of XPath
(because of the restrictions), nor a subset of XPath (because of the
extensions). This makes me question the wisdom of trying to fit it into XPath at
all. If we had a BPEL-specific syntax for
expressions, perhaps our expressions could be better engineered around what
we're actually trying to do. For example, we
wouldn't have to write bpws:getVariableData("x")
+ bpws:getVariableData("y") when we mean x+y.
Jim Clune
Parasoft
Corporation email:
101 E.
Huntington Ave. voice: (626) 256-3680
Monrovia,
CA. 91016
fax : (626) 305-9048
