XPath expressions was: [wsbpel] Serializable Scopes Issues?

[Assaf Arkin <arkin@intalio.com>]

As far as join conditions go, these are strictly boolean expressions 
that can only reference static values and link status. The restrictions 
are such that it's not really a subset of XPath, and even if it is, a 
not well defined subset. My personal opinion is that we are better off 
clarifying a simple expression language for that which can borrow 
partial syntax/semantics from XPath.

See issue 28 - Simplification of Join condition.

As for other expressions, XPath is powerful, well understand and 
supported that I am definitely in favor of it. But the use of 
getVariableData() bugs me since it doesn't allow for static validation, 
and you need a specialized XPath engine to conform to any requirment 
that would allow for static validation. An alternative is to use XPath 
variables, so instead of writing bpws:getVariableData("x") + 
bpws:getVariableData("y"), you would write $x+$y.

See issue 29 - Simplifcation of XPath expressions

arkin

Jim Clune wrote:

> 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: jim.clune@parasoft.com 
> <mailto:jim.clune@parasoft.com>
> 101 E. Huntington Ave.      voice: (626) 256-3680
> Monrovia, CA.  91016           fax  : (626) 305-9048
>