Re: [wsbpel] Issue 29 - Proposal For Vote

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

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

Not according to XPath. A root node is selectable with '/' regardless of 
its type or content.

Assaf


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

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

S/MIME Cryptographic Signature