[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 103 - Proposed amendmants
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:arkin@intalio.com] 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]