Re: [wsbpel] Issue 29 - Proposal For Vote

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

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.

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

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