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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--