RE: Alternative StepExpr evaluation policy

There are alternative proposals that we considered where E2 returns
atomic values:

One is that an expression such as

Expr/foo(.) 

where foo() returns an atomic value based on the passed node, 
passes each node as argument to the function foo and returns the
sequence of 
atomic values.

Since there are several possible interpretations, I would consider this
to be something to be investigated for the next version at this time,
since I think getting XQuery done is more important than piling more
features on.

Best regards
Michael



> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Emerson
> Sent: Monday, September 15, 2003 5:10 PM
> To: public-qt-comments@w3.org
> Subject: 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 Tuesday, 16 September 2003 16:58:58 UTC