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:
> >> >> >>> For additional commands, e-mail:
> >>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
>
