[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

>>>> //@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/

---