RE: Alternative StepExpr evaluation policy

Interesting suggestions. I'm not sure there's much enthusiasm for adding
such features at this stage, and there will probably be a feeling in some
quarters that overloading the "/" operator to this extent is undesirable. In
principle I think the ideas are technically feasible; subject to some
comments below.

> 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.

You need to take into account that E2 is evaluated once for each node in E1.
In principle, some evaluations can return a number and others return a node,
for example:

E1/(if (position()=1) then 42 else *)

So the detailed rules are likely to be a bit complicated.
> 
> If E2 evaluates to a literal result then the expression 
> should be evaluated as;
> 
> E1/child::T2

By "literal result" I guess you mean a string? You need to explain how the
string is converted to a QName, i.e. how namespaces are handled. And the
same considerations apply as for a numeric value.
> 
> 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 ?
> 

I think you can't easily package all of these effects into one expression at
once, but the individual capabilities are already there, using the
constructs:

E1/*[$number]
E1/*[name()=$string]
E1/*[$boolean]

So I don't think you're proposing any important new capability, just a bit
of shorthand syntax.

Michael Kay