Re: [wsbpel] Issue 29 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

This proposal is only relevant if we don't decide to adopt a mechanism 
to map properties to XPATH variables.

As for the desire to use XPATH 1.0 in a standard manner, unfortunately 
that is quite impossible given our semantics. It is explicitly illegal 
to have a null context node in XPATH 1.0. In section 1, the introduction 
to XPATH 1.0, a series of requirements are listed for defining the 
context in which a XPATH executes. List in there is a node (explicitly 
referred to as the context node). This is then followed by a requirement 
for a pair of non-zero positive integers identifying the context 
position and context size. If the context is empty or null then these 
two numbers would have to be 0 and that's explicitly prohibited. Hence 
why we already are forced into a situation where we have to require a 
BPEL specific XPATH processor.

	Yaron

Assaf Arkin wrote:
> -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
>>
>>
>