//@foo and //child:: would both be errors - //@* would need to be
//*/@foo and //child:: doesn't make sense anyway
Not quite. If // was short for /descendant::, then //*/@foo would still
not be equivalent. That's because, in XPath as actually designed,
/descendant::*/@foo isn't the same as //@*. The former excepts attributes of
the context node, whereas //@* also includes attributes of the context node.
So, instead, you'd have to write (@* | ./descendant::*/@*). In that case,
the actual definition of // is handy.
Evan
Oops, quick correction. When starting at the document node, there wouldn't
be any attributes. So what I meant to say was that .//descendant::*/@* is
not the same as .//@*.
Aargh. I should just give up. :-) Against my better judgment, here's one
last try at communicating what I meant to say:
./descendant::*/@* is not the same thing as .//@*
*blush*
:)
So in summary, //@* is the equivalent of //*/@* but .//*/@* would be
the gotcha.... I wouldn't expect .//*/@* to return attributes from the
self axis anyway, as I'm consciously asking for the descendants .//*
and not for the self axis.
In fact it's a bit odd that .//@* does return all attributes,
considering attributes aren't descendants, but only accessible from
the attribute axis of their parent element - its just a quirk of the
way // currently works that you can do //@* at all....isn't it?
--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/
--~------------------------------------------------------------------
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>
--~--