Re: [xsl] is there really a need for location steps of ".."?

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Hi Robert,

At 09:25 AM 3/12/2003, you wrote:
>   a number of examples in the xpath books and tutorials i'm reading
> seem to enjoy showing examples involving ".." as one of the location
> steps, or some operation involving "backing up".  as one example,
> simpson's book "XPath and XPointer":
>
>   //part[. = "Hands"]/ancestor::*
>
> sure, i can see that this represents the node-set of all ancestors
> of all part elements whose string value is "Hands".
>
>   but it seems that this expression is equivalent:
>
>   //*[descendant::part = "Hands"]       # appears to mean the same
>
> one obvious difference, admittedly, is that the first expression
> will generate a node-set in order going up, while the second will
> work its way down from the root.

Actually, there's not even this difference. Both of these select node 
*sets* (the same set, as you've surmised), but (a bit of math I hadn't 
recalled before a lesson from David C. on XSL-List) as a set, it has no 
order. An order is provided when needed; usually that's document order. And 
if you use either of these expressions in the select of an apply-templates 
or for-each instruction, you'll find that they both come out in document 
order unless you do something to alter that.

(The fact that ancestor:: is a reverse axis has a bearing on which node 
you'll get back, for example, from //part/ancestor::*[1], but not on the 
"order of nodes" in a set.)

(And all this is due to change in XPath 2.0, where we'll have things like 
sequences.)

>   other than that, are these equivalent?  more to the point,
> it seems that most location paths can be rewritten to get rid
> of this kind of "backing up" idea.  and is efficiency an issue
> here?

To paraphrase Mike K. recently, are you having or do you reasonably expect 
to have a performance issue? "Efficiency" is a very relative concept. (Not 
that I like giving the machine extra wheels to turn either. Nonetheless the 
question remains fairly academic; and much of the point of a declarative 
language like XSLT is to insulate stylesheet writers from having to be 
generally concerned with these issues, and let the implementors optimize.)

On the other hand, it's hard to resist acknowledging that you've cut down a 
location path expression from three steps

//part[. = "Hands"]/ancestor::*

to two:

//*[descendant::part = "Hands"]

(Trick question for newbies: what are the three steps? what are the two?)

>   or does it not matter all that much?

Who's to say? There are people who lose sleep over this kind of thing. :-> 
(And even if you're not in that category, if you find it interesting does 
it matter if it matters?)

Cheers,
Wendell


___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
    "Thus I make my own use of the telegraph, without consulting
     the directors, like the sparrows, which I perceive use it
     extensively for a perch." -- Thoreau


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