Subject: Re: [xsl] // expanding to descendant-or-self::node() From: "Andrew Welch" <andrew.j.welch@xxxxxxxxx> Date: Wed, 17 Sep 2008 10:10:39 +0100 |
>>>> //@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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] // expanding to descendan, Florent Georges | Thread | Re: [xsl] // expanding to descendan, David Carlisle |
RE: [xsl] Tag movement in XML, Michael Kay | Date | Re: [xsl] // expanding to descendan, David Carlisle |
Month |