OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: XPath expressions was: [wsbpel] Serializable Scopes Issues?

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]