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: Re: [wsbpel] Serializable Scopes Issues?

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
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]