Re: [wsbpel] Issue 29 - Proposal For Vote

[Assaf Arkin <arkin@intalio.com>]

-1

If we decide to manifest properties as independent XPath variables, then 
we have a syntax that is consistent in how variable values are accessed, 
directly (the entire variable) or indirectly (a property of the 
variable). I happen to be on the side that likes consistency and abhors 
making changes to XPath implementations.

"We have in the past altered XPATH in order to suit our needs. For 
example, in some BPEL expressions we have banned the use of the global 
context node, a node whose presence is actually mandated by the XPATH 
specification. If we are willing to change XPATH that much I see no 
reason not to change it here as well. In for a dime, in for a dollar."

Since we have nothing to pass in the context node, wouldn't it be easier 
if we use the XPath specification to achieve that instead of forcing 
implementations to deviate from the specification, write custom XPath 
implementations (only for BPEL), and so forth. The XPath specification 
mandates that you pass a context node, but the XPath specification does 
not require the context node to have any content in it. You can pass an 
empty root node (XPath 1.0) or an empty document node (XPath 2.0) and be 
in full comformance with the XPath specification and the BPEL model at 
the same time.

Let's keep it simple (that's what this issue is all about). Get the 
semantics we want for expressions, but without having to change existing 
specifications or implementations.

assaf


Yaron Y. Goland wrote:

> Issue 29 - Simplification of XPath expressions
>
> Proposal: Require that all arguments to BPEL defined XPATH functions 
> must be quoted strings that are statically defined within the XPATH 
> expression.
>
> Note: This proposal won't be necessary if we decide to manifest 
> properties as independent XPATH variables since this would let us get 
> rid of getVariableProperty.
>
> Rationale: 
> getVariableProperty(getVariableProperty(foo,bar),getVariableProperty(ick,bick)) 
> is completely legal in XPATH. This is a problem because such an 
> expression makes it impossible to statically analyze the expression 
> that contains the function call and determine what variable is being 
> referenced. This is problematic for static analysis of the process 
> because it makes it impossible to determine what variable and property 
> are being accessed so there is no way to check if that variable is 
> accessible from that point in the BPEL process definition or if the 
> variable has the referenced property defined on it. Even worse (in my 
> mind anyway) is that the previous plays havoc with optimizations for 
> compensation handling. If the previous function was contained within a 
> compensation handler then there would be no way to know what variable 
> was being accessed and so the BPEL process would have no choice but to 
> persist all variables visible from the compensation handler, major yuck!
>     We have in the past altered XPATH in order to suit our needs. For 
> example, in some BPEL expressions we have banned the use of the global 
> context node, a node whose presence is actually mandated by the XPATH 
> specification. If we are willing to change XPATH that much I see no 
> reason not to change it here as well. In for a dime, in for a dollar.
>
> Section 9.1 -
>
> Add a new paragraph after the following paragraph "Any qualified names 
> used within XPath expressions are resolved by using namespace 
> declarations currently in scope in the WS-BPEL document at the 
> location of the expression.":
>
> The arguments to all XPATH functions defined in this specification 
> MUST be given as quoted strings. The previous requirement MUST be 
> statically enforced. It is therefore illegal to pass into a BPEL XPATH 
> function any XPATH variables, the output of XPATH functions, a XPATH 
> location path or any other value that is not a quoted string. This 
> means, for example, that getVariableProperty("varA","propB") meets the 
> previous requirement while 
> getVariableProperty($varA,string(getVariableProperty("varB","propB")) 
> does not. Note that the previous requirement institutes a restriction 
> which does not exist in the XPATH standard.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>

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