Does this mean you will be writing your own implementation of the NodeInf=
interface, Saxon's representation of the data model?
The XPath axes and node tests are implemented below the NodeInfo interfac=
so if you write your own implementation of NodeInfo it can be clever abou=
how the axes and node tests are implemented (there are helper methods in =
Navigator class if you want to use a standard implementation). However,
predicates in a path expression, such as , are handled above the
NodeInfo interface, so you can't influence how these are evaluated.
Actually my intend was rather to write my own implementation of DOMSource=
DOM interfaces, and then use it with the saxon XPathEvaluator class.
> XPath 1.0 was based on the fact that NodeSet were not ordered
> (theoretically, practically in most cases they were). Thus,
> with Jaxen, running
> an expression like
> /elt1/* involves the creation of not only two objects (
> the root element
> and its 2500th child ) but of 2501 children (in the case of a
> query)... If I use a deeper query such as
> /elt1/*/*/*, of course, I
> hardly get a result (memory and CPU time explodes).
I don't see why this one should be a particular problem. It's not
essentially any different from evaluating /elt1/*/*. And although y=
might have to create lots of objects, the objects should be very
short-lived, and Java is quite good at discarding short-lived objects
-- Well, I think that Jaxen keeps a lot of intermediate results, which pr=
lots of nodes to be discarded as the tree is navigated. I must give a try=
> I have read that saxon includes optimizations for sequence
> iteration. Does it
> include something to address the simple case of an expression
> like these
> (containing '/*[X]' pattern where X is a constant number) ?
> How will behave
> saxon in such a case ? Direct access to Xth element, iterate
> to Xth element
> then stop, iterate fully and keep only Xth element ??
If the predicate is attached to a step in a path expression, Saxon will
iterate to the Nth element and then stop (Saxon's own implementations of
NodeInfo don't provide any other way to do it. In some cases you could do
better in the case of child::node(), but I can't see many people
wanting to do that: most people will want comments and processing
instructions to be skipped). If the predicate is attached to a variable, =
example $x, Saxon uses lazy evaluation to evaluate $x: if the full
sequence has already been evaluated, it will use direct access to obtain =
2500th item; if not, it will evaluate as far as the 2500th item; the rest=
the sequence will be evaluated if and when it is needed.
-- The child nodes I am working with are only Element nodes (if we do not=
attribute as child nodes), and child elements are naturally ordered. I
understand it is not an issue for most people to iterate through the chil=
but I use Xpath really intensively on huge trees and this is really the
performance bottleneck on my use case. Since my ElementImpl provides prov=
"getElementAt" function, I really need to override this iteration mechani=
my particular case. The solution I implemented for jaxen was to implement=
'element-at' extension XPath function (but the syntax is really nasty in =
case of several steps in the path). I am not sure I have fully understood=
explanation, but I think you say that it is not really a 'common' optimiz=
issue, and I agree with this. Do you think I can implement properly some =
optimization on my side ?
> Secondary question : the solution I used was to write an
> extension function
> child-at for jaxen. In XPath 2.0 spec, a function item-at
> exists but was
> removed in latest version of Saxon. Is there a good reason for this ?
The function was removed from the spec because it was redundant: item-at(=
$n) was just another way of writing $s[$n].
-- Many thanks for answering anyway.