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

Re: // expanding to descendant-or-self::node()

Subject: Re: // expanding to descendant-or-self::node()
From: Evan Lenz <evan@xxxxxxxxxxxx>
Date: Wed, 17 Sep 2008 08:48:34 -0700
Re:  // expanding to descendant-or-self::node()
Andrew Welch wrote:
Really - even though it implies attributes are descendants and that
the attribute axis is available from node()s?

I think it only implies that if you're used to misinterpreting "//". ;-)

It looks like:

/foo/bar

expands to

/child:foo/child:bar

so // had to expand to

descendant-of-self::node()
More precisely, it expands to /descendant-or-self::node()/ That trailing slash makes it syntactically invalid on its own, whereas descendant-or-self::node() is a valid expression in its own right.
so //@* works as a side-effect of that - a happy accident if you like.

Actually, it's precisely the reason // is defined the way it is: so that //@* will work (and the less common //namespace::*). So it's really a special design concession rather than a happy accident. :-) I'm not aware of and can't think of any reason why "//" is defined the way it is other than so that //@* will work. Can you think of any?

But it does make sense in a way, and I have found occasion to use it. "Get me all attributes from here on down." .//@* is a lot more convenient to write than (@* | .//*/@*).

I wonder how we should approach //@* - is it less effective than
//*/@* because it gets non-element nodes, or does it come under the
category of those things to leave to the processor.
It remind me of the identity template - calling apply-templates when
matching an attribute - no big deal, but not exactly good either.


I think I see what you're getting at. The expression //@*, because of the way the shorthand expands, "unnecessarily" traverses nodes that would never have attributes of their own (document node, text nodes, comments, and processing instructions). And you're wondering if all those dead ends might make the evaluation less efficient than evaluating //*/@*. I'm not an implementor, but I think you'll find that any processor worth its salt will have optimized //@* and probably "//" in general, rather than literally expanding it and going from there. In fact, //*/@* is probably optimized too, since you can tell by looking at the expression that it will only ever return attributes and there's no need to traverse nodes that don't have attributes.

So if you want a usage guideline, I'd say (almost) always go with what's simplest to read and write: //@*

Evan

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.