Re: [wsbpel] Serializable Scopes Issues?

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.

wsbpel message