Re: [wsbpel] Issue 29 - Proposal For Vote

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

> I realize I'm being thick but I don't believe the sections you quote 
> solve the problem. The key issue is - is there such a thing as an 
> empty node in XPATH? I believe the answer to be no.

I believe the answer is found in the XPath data model specification:

"Document Nodes *must* satisfy the following constraints.

   1.

      The *children* *must* consist exclusively of Element, Processing
      Instruction, Comment, and Text Nodes if it is not empty.
      Attribute, namespace, and Document Nodes can never appear as children

   2.

      If a node /N/ is among the *children* of a Document Node /D/, then
      the *parent* of /N/ *must* be /D/.

   3.

      If a node /N/ has a *parent* Document Node /D/, then /N/ *must* be
      among the *children* of /D/."

http://www.w3.org/TR/xpath-datamodel/#DocumentNode

You may also want to look at XPath implementations to see what they 
accept as context node as part of their formal API. I will be interested 
in hearing of an implementation that doesn't accept an empty context 
node.  For example, the Java 1.5 XPath library:

http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/package-summary.html

(you can see the example at the bottom)

> An alternative argument is - is there such a thing as an empty 
> node-list in XPATH? There I think the answer is potentially yes. But 
> it isn't clear to me if an empty node-list can be legally used as a 
> context for an expression because all de-references would be illegal. 
> E.g. /foo would be an automatic fault but "/" would NOT. That worries 
> me alot. I think it's misleading to allow "/" to work but "/foo" not 
> to. I think it's better for users if we just ban "/".

I don't know of many implementations that support a node-set as an 
evaluation context, and I wouldn't want to rely on anything that's 
implementation specific.

Assaf

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