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

On Wed, 12 Mar 2003, Wendell Piez wrote:

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

ah, you're right -- regarding order, i was thinking about ...
 
> (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.)

quite right -- i'm still getting my head around all this.
 
> 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?)

hey, even *i've* figured that out. :-)  my original question was based 
more on aesthetics than efficiency.  consider two different ways to
define a node set:

  //step/step/../step/ancestor::*/.../blart

so this is clearly selecting *some* set of "blart" nodes,
in which the path meanders up and down, and where the final 
filtering takes place at the end.

  conversely, i suspect that any location path that could
be written that way could also be written as

  //blart[... possibly stunningly complicated predicate(s)]


the one advantage i see in the second form is that it's clear
right up front (at the left) that my final node set will
consist of zero or more "blart"s.  in the first form, i have
to read all the way to the end to see this.

  OTOH, i'm willing to accept that some people may find it 
easier to design the first form.  matter of taste, i guess.
it just struck me as curious that so many of the examples
i saw in the docs i was reading insisted on creating paths
that involved "backing up" to parents or ancestors, that's
all.  i was just taking it as a challenge to rewrite such
paths using the second form.

rday

  


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