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::*, 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format