From: Kay, Michael <Michael.Kay@softwareag.com>

Date: Tue, 16 Sep 2003 17:21:43 +0200

Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD127@daemsg02.software-ag.de>

To: emerson@harvestman.net, public-qt-comments@w3.org

Date: Tue, 16 Sep 2003 17:21:43 +0200

Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD127@daemsg02.software-ag.de>

To: emerson@harvestman.net, public-qt-comments@w3.org

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 KayReceived on Tuesday, 16 September 2003 11:21:51 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:45:14 UTC
*