On Thu, Feb 19, 2009 at 10:28 PM, Michael Kay
<mike@saxonica.com> wrote:
Looks like a nice piece of work (if it
works)
A few questions:
(a) I note that you support multiple downward selections in
a predicate, for example
/root/pub[book/name and book/author]//book
I would be interested to know whether you do this in a pure
streaming way, or whether you build an in-memory tree for any element that has
such a predicate. (Saxon's streamable subset of XPath currently doesn't allow
multiple downward selections).
Yes. It is done using pure streaming way. There is no in-memory tree for any element is created, otherwize it would defeat the main purpose of XMLDog.
In this example, when pub startElement is called, I catch the path of element say /root[1]/pub[5]. I call this as delayed evaluation which needs to qualified by the evaluation result of its predicate. the predicate [book/name and book/author] would be evaluated by the time i get endelement of pub. so when endelement of pub is notified, i know whether "/root[1]/pub[5]" has passed the predicate or not.
XMLDog do supports absolute paths in predicate also. for example:
/*/fibonacci[ count(/*/fibonacci) - 1 ]
(b) You've got an example that does
*[last()]. Do you allow *[last() - 1]? Is this done with a pure
streaming approach?
Yes. it supports [last()-1] also;
For your information it also supports position() and last() with a predicate. for example:
/*/fibonacci[@index>5][position()>5 and position() < last()]
And a couple of comments:
(c) When you say "XPath", you seem to mean "XPath 1.0". It
would avoid confusion to say that explicitly.
I mean XPath 1.0;
recently i added following support also (you need to build from sources for below features):
1: supports XPathVariableResolver & XPathFunctionResolver.
2: support for union. for example:
//shipTo | //billTo | //item | //items/*
NOTE:
currently it doesn't support FilteredExpr i.e (/root/pub[book/name]/book[@id=234])[2]
and pathExpr i.e (/a/b | /a/c)/d/e
They will be implemented in future. I am planning to support following-sibling and preceding-sibling also in near future;
(d) I would think that a common way to use a SAX-based
XPath engine is to filter the events, so that events are passed on to the next
stage in the SAX pipeline only if they belong to nodes selected by the XPath
expression. You don't seem to support this in your API.
Yes. currently XMLDog doesn't support it;
for xpaths which don't need delayed evaluation (i.e without predicates having downward selection), it would be possible to pass SAX events to another pipeline.
for xpaths with downward selection, user can do the sax parsing second time and register sax handler for interesed nodes.
currently it is not planned. Will try if someone is interesed;
currently XMLDog performs 1.24x faster than Xalan. There is still room for performance. I have tested memory consumption using netbeans profiler. it is quite low.