[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 29 - Proposal For Vote
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 > >> >> >>> > >> >> >>> > >> >> >> > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]