[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:
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]