Am 11.12.2007 um 22:05 schrieb Michael Kay:

When Saxon is evaluating //a, it doesn't know that there is only one
a-element and that the a-element doesn't have any further a-elements in its
subtree - it has to keep looking!

I'm afraid I don't know why there aren't more calls on getStringValue() -
that will depend on the context in which the path expression appears.

Remember that an expression like //a/text() isn't naturally sorted, so in
general I would expect the text nodes to be retrieved first, and then sorted
into document order before being atomized. In your example the sort will be
a no-op, but that wouldn't be the case for example with


where the parent of rrr is in the result of //a ahead of the parent of qqq.

It might be that you have used the path expression in a context where order
doesn't matter, for example as an operand of "=", in which case Saxon will
be quite happy to retrieve the results in the "wrong" order.

I have to tell you that when I walk through the evaluation of such
expressions in the debugger, I often get surprises myself - sometimes it
seems the optimizer has a mind of its own.

my testfile:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a attribute="foobar">

Uhm it's a simple JUnit TestCase:

final XPathExpression findLine =
final ArrayList result =
        (ArrayList) findLine.evaluate(doc, XPathConstants.NODESET);
TestCase.assertEquals("foo1", ((NodeInfoImpl)result.get(0)).getStringValue());
TestCase.assertEquals("foo2", ((NodeInfoImpl)result.get(1)).getStringValue());
TestCase.assertEquals("foo3", ((NodeInfoImpl)result.get(2)).getStringValue());

I'm also not sure why it returns a NodeInfo object instead of a text string directly. The first ((NodeInfoImpl)result.get(0)).getStringValue()) returns "foo3"... and it returns only this "foo3", so foo1 and foo2 is never returned (I get an IndexOutOfBound exception with result.get(1) and result.get(2)), but it might be my testcase, I'm really not sure why it returns a NodeInfo object... :-/

best regards,