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