Alternative StepExpr evaluation policy

Rather than raising a type error during evaluation of StepExpr, which as
far as I can see is simply a way of handling the case where an
expression does not return a sequence of nodes, I propose an
alternative.

Let us first take, E1 & E2 to be two StepExpr's, and T1 & T2 to be the
return types of E1 & E2 respectively. Assume E1 to be a valid axis step
returning a sequence of nodes.  

Given the following XPath

E1/E2

If E2 evaluates to a numeric result then the expression should be
evaluated as;

E1/child::*[T2]

Such that E2 is substituted with an expression returning the T2'th child
of E1.

If E2 evaluates to a literal result then the expression should be
evaluated as;

E1/child::T2

Such that E2 is substituted with an expression returning all children
which match the node test given by the string literal T2.

If E2 Evaluates to a boolean result then the expression should be
evaluated as;

E1/*

If and only if the boolean result evaluates to true, otherwise the
expression should be evaluated as;

E1

Variable references would be handled as the appropriate primitive type
above.

Since there is already a special rule for numbers in predicate
expressions, this is only a logical extension plus or minus a little
translation.  Some of these recommendations are already used in the
Xpointer specification (a derivative of Xpath 1.0)

Surely doing something wise (and potentially very useful) with a return
type is better than giving a type error.  After all, its not like the
type error is any more graceful than saying "boom!" your expression did
not evaluate.

Can anyone show an example of how the functionality given above can be
provided in a single line Xpath statement (i.e. without the use of
branching statements such as "if") without the extensions that I have
proposed here ?

emerson

Received on Monday, 15 September 2003 20:13:36 UTC