Re: [wsbpel] Issue 29 - Proposal For Vote

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

As I mentioned previously the problem with an empty root node is that it 
makes "/" legal but any other expression starting with "/" illegal. I 
think that is unnecessarily confusing.
	Yaron

Assaf Arkin wrote:
> Yaron Y. Goland wrote:
> 
>  > The reference to XPATH 2.0 isn't relevant, XPATH 1.0 != XPATH 2.0.
> 
> For future reference, my e-mails are shorter and more to the point when
> I quote the XPath 2.0 and only the XPath 2.0 specification, since that
> version is much better organized and better articulated.
> 
> I assume that most members of this group will find the more
> readable/concise text easier to follow, and that the few members who are
> deeply interested in this subject can go and validate my statements
> against the XPath 1.0 specification.
> 
> I will always point out if there are differences between the two specs
> (see below).
> 
> 
>  >
>  > And at the end of the letter you point out yourself that you wouldn't
>  > want to use empty node-sets as the context but that is exactly what
>  > your proposal requires.
> 
> To further clarify, my proposal requires that you either pass an empty
> root node (XPath 1.0) or an empty document node (XPath 2.0/XQuery 1.0)*
> as the context node, in compliance with these specifications.
> 
> If it's still not clear, can you point out where I'm being confusing?
> 
> Assaf
> 
> * You should note the name difference between the two specs.
> 
> 
>  >
>  >     Yaron
>  >
>  > Assaf Arkin wrote:
>  >
>  >> 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
>  >>  >>  >>>
>  >>  >>  >>>
>  >>  >>  >>
>  >>  >>  >
>  >>  >>  >
>  >>  >>
>  >>  >
>  >>  >
>  >>
>  >
>  >
> 
>