RE: XPath grammar questions

> Specifically, it's the 'not(*/node())' that I'm having
> trouble with.  The
> XPath spec states that:
>
>   not( boolean ) -> boolean
>
> This would imply that '*/node()' evaluates to a boolean.
> However, it also
> states that paths such as:
>
>   ancestor::node()
>
> evaluates to a set of matching nodes....
 I don't see how the same path should evaluate to
> two different
> results.

Expressions such as */node() and ancestor::node() evaluate to node-sets. The
not() function expects a boolean. The rules for an XPath function call state
that the supplied argument is converted to a value of the required type. The
rule for converting a node-set to a boolean is that an empty node-set
converts to false, a non-empty node-set to true.
>
> The second (and at this point, more critical) problem I'm
> having is with
> function names.  Take:
>
>   [normalize-space(@name)='x']
>
> If you follow the grammar, the evaluation is:
>
>    Predicate->Expr->OrExpr->AndExpr->EqualityExpr->RelationalExpr->
>    AdditiveExpr
>
> at which point it matches the rule:
>
>   AdditiveExpr:: AdditiveExpr '-' MultiplicativeExpr

You need to tokenize the XPath expression before you apply the grammar
rules, and the tokenization rules say that you find the longest token you
can. This means that "normalize-space" is recognized as a single token; the
"-" is therefore never recognized as a minus sign if it's preceded by a
name, with no intervening space.

The XPath spec is written rather tersely, and it takes a while to appreciate
it's subtleties. You might find that the explanations in my "XSLT
Programmer's Reference", while not definitive, are easier to follow.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list