I apologize if I'm being dense, but I don't understand how the nearest
ancestor can be anything other than the parent. Could you please give
an example?
I just want to make sure I haven't sent you off with the wrong
expression for your intended usage.
On Wed, Apr 16, 2014 at 8:48 PM, José Tomás Atria <jtatria@gmail.com> wrote:
> Thank you all for your answers.
>
> I was just tryig to determine if $test/ancestor::element()[1] would be the
> correct way of getting the nearest ancestor, as I couldn't find whether axes
> were ordered or not in the xpath specification.
>
> Thanks!
>
> ps: Parent doesn't apply, because the relevant node is not always the
> parent, but the first node with a given name.
>
>
> On Wed, Apr 16, 2014 at 2:45 PM, David Rudel <fwqhgads@gmail.com> wrote:
>>
>> Mr. Atria,
>> You left out a key element from the answer you got from stack overflow.
>>
>> Note that Dimitre's response used a filter expression
>> (path expression) [predicate]
>>
>> not a simple path expression
>>
>> The ()s are critical.
>>
>> $test//child/ancestor-or-self::test[ last() ]
>>
>> is very different from
>>
>> ($test//child/ancestor-or-self::test)[ last() ]
>>
>> The ancestor axis is a reverse axis, but when the xpath expression is
>> complete, the sequence of nodes are then put in document order
>> regardless of what order the last axis had.
>>
>> In any event, I don't understand what is wrong with simply
>> $test/ancestor::element()[1]
>>
>> Perhaps I don't understand your question (which is simpler than the
>> Stack Overflow question you linked to). But if you are just looking
>> for the nearest ancestor element, then it seems that
>> $test/ancestor::element()[1] should give it to you.
>
>
>
>
> --
> entia non sunt multiplicanda praeter necessitatem
--
"A false conclusion, once arrived at and widely accepted is not
dislodged easily, and the less it is understood, the more tenaciously
it is held." - Cantor's Law of Preservation of Ignorance.