Re: [wsbpel] Issue 103 - Proposed amendmants

[Assaf Arkin <arkin@intalio.com>]

I) Back in the days I raised an issue (Issue 29) with the use of XPath 
functions to access BPEL variables. In order to perform static analysis, 
it is helpful to know which variables are accessed in the expressions 
used by the process. Since variable names are passed by value to 
functions, some fancy XPath parsing is required to identify all the 
variable names. And that is, assuming variable names can be determined 
at design-time.

For example:

getVariableData( getVariableData( 'varname' ) )

The actual variable being accessed will depend on the value of the 
variable 'varname' at run-time. Such an expression cannot be statically 
analyzed to determine which variables are being used.

However, if we decide to use XPath variables to access BPEL variables, 
life becomes simpler. One can easily determine which variables will be 
accessed in a given expression by asking the XPath engine, and there are 
no run-time surprises.

The current proposal for 103 solves this problem when accessing 
variables directly. However, properties are still accessed using 
functions, and since properties are derived from variables, by extension 
variables are still accessed using functions. Satish proposed before 
that we use a naming scheme to create XPath variables that access 
message parts. I suggest we extend this proposal to cover properties, 
and devise a naming scheme to access properties using XPath variables, 
thereby solving the static analysis problem.


II) One of the issues XPath had to deal with (from back when it was part 
of XSLT) was the fact that you can't always use complete XML documents. 
Well-formed XML documents are great for sending and storing data, but 
for data manipulation you need to work with individual nodes, or 
document fragments. So XPath 1.0 came up with the notion of a 'root 
node', which XPath 2.0/XQuery 1.0 renamed to 'document node', but kept 
the same semantics.

The root/document node has two interesting properties:

1. True to its name, it's the top-most node and there's nothing above 
it. Which means you can always get back to it with a '/'.
2. It can contain any number of child nodes and they can be any type.

When you use the root/document node to access BPEL variables, you end up 
with three cases:

1. The BPEL variable is a simple type. The rood/document node contains 
the value of that variable in the form of a text node (a valid 
root/document node).

2. The BPEL variable is an element. The root/document node contains the 
value of that variable in the form of an element (a valid root/document 
node).

3. The BPEL variable is a complex type, a sequence of zero or more 
elements. The root/document node contains the value of that variable in 
the form of a node that contains these elements. For example, the 
root/document node can be a DOM Level 1 DocumentFragment.

It seems that XPath/XQuery and DOM (as most other XML APIs) are well 
equipped to deal with these three BPEL variable types. As well as 
message types, which happen to be a combination of these three variable 
types. There is no need to devise new mechanisms, since we already have 
specifications and available implementations to support our use cases. 
The proposal for issue 103 decides to take the long route and force 
implementations to create fake documents and elements, which creates 
unnecessary complexity.

I propose that we use the available mechanisms in XPath/XQuery to handle 
BPEL variable content.


III) Another issue I raised (Issue 28) deal with join conditions. As 
with other expressions, I wanted join conditions to yield to static 
analysis, and one way to achieve that is by replacing XPath functions 
with XPath variables. The proposal for issue 103 does exactly that.

However, it mandates that join conditions derive the full power of 
XPath, which enables us to support "interesting" join conditions, for 
example:

joinCondition=" floor( 2.4 )"
joinCondition=" string-length( $myLink ) > 4"

I don't feel a compelling need to support these use cases. In fact, the 
restrictions we have in the current spec support all the valid use cases 
for join conditions, effectively allowing all boolean tests on any 
combination of link status. With such restrictions one doesn't have to 
wonder what kind of link status would lead to the activity being 
executed. In addition, it is possible for a smart implementation to 
easily determine the truth value of a join condition even before all 
link status have been determined.

For example, if the join condition is '$X and $Y' and the status of link 
X is known to be false, then an XPath expression cannot evaluate the 
condition, but a smarter implementation can easily determine it will 
never evaluate to true.

I propose that we retain the current restrictions we have in the spec, 
which are ment to limit join conditions to boolean tests on link status, 
and simply replace the use of XPath functions with XPath variables.

assaf


Alex Yiu wrote:

>
> Hi, all,
>
> Here is the updated version of Issue 103 proposal from Yaron and I.
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>------------------------------------------------------------------------
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature