[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: is there really a need for location steps of ".."?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 12 Mar 2003 11:21:03 -0500
need for location
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



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.