Assaf,
You wrote:
______
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.
______
I like the spirit of what you are saying. But what exact modification
to the proposal are you suggesting?
Satish
-----Original Message-----
From: Assaf Arkin [mailto:]
Sent: Tuesday, March 08, 2005 3:49 AM
To: Alex Yiu
Cc: wsbpeltc; Yaron Y. Goland; Diane Jordan
Subject: Re: [wsbpel] Issue 103 - Proposed amendmants
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_workgr
oup.php.
>
