Re: [wsbpel] Issue 29 - Proposal For Vote

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

> 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.

It is illegal to have a null context node, it is permissible to have an 
empty context node. My suggestion takes XPath into account so it doesn't 
violate any XPath rules. So my suggestion still stands, now let me 
explain why it works.

The context size refers to the size of the node-set which contains the 
current context node, while the position refers to the position of the 
current context node in that node-set. When you begin evaluating an 
XPath expression - the initial values are 1 and 1, meaning one element 
in the node-set (the context node) in the first ordinal position. It 
matters not what the contents of the context node is, i.e. whether it's 
a document, an element, a text node, or an empty node.

The XPath 1.0 specification is easy to misread. If you try to implement 
it, you will soon catch this subtelty when you have to implement 
functions like count() and position(), but without going deep it's easy 
to misread it. I suggest referring to the XPath 2.0 specification, which 
is not fundamentally different on this issue, just more expressive and 
precise:

    *

      Definition: The *context item* is the item currently being
      processed. An item is either an atomic value or a
      node.][Definition: When the context item is a node, it can also be
      referred to as the *context node*.] The context item is returned
      by an expression consisting of a single dot (|.|). When an
      expression |E1/E2| or |E1[E2]| is evaluated, each item in the
      sequence obtained by evaluating |E1| becomes the context item in
      the inner focus for an evaluation of |E2|.

    *

      [Definition: The *context position* is the position of the context
      item within the sequence of items currently being processed.] It
      changes whenever the context item changes. Its value is always an
      integer greater than zero. The context position is returned by the
      expression |fn:position()|. When an expression |E1/E2| or |E1[E2]|
      is evaluated, the context position in the inner focus for an
      evaluation of |E2| is the position of the context item in the
      sequence obtained by evaluating |E1|. The position of the first
      item in a sequence is always 1 (one). The context position is
      always less than or equal to the context size.

    *

      [Definition: The *context size* is the number of items in the
      sequence of items currently being processed.] Its value is always
      an integer greater than zero. The context size is returned by the
      expression |fn:last()|. When an expression |E1/E2| or |E1[E2]| is
      evaluated, the context size in the inner focus for an evaluation
      of |E2| is the number of items in the sequence obtained by
      evaluating |E1|.

Assaf

>
>     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
>>>
>>>
>>
>
>

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