Hi Simone and Sylvain,
aren't XSLT transformers already SAX/Xpath optimized? I mean, an XSLT
containing an XPath expression and used in a SAX context, isn't already
able to resolve the XPath while keeping buffering at the minimum possible?
I can clearly remember that there has been a lot of work about this in
Xalan and other XSLT engines, and also how a complex XPath expressions
could change the performance of a transformation because of increased
buffering.
In that case, maybe, instead of reinventing it, it should be possible to
delegate the "transformation" (extraction of a fragment from the entire
XML stream) to an XSLT processor. The simplest way could be to generate
an XSLT on the fly :) .. the correct way would be to use the
[Xalan|Saxon|any other] internal APIs to perform the XPath resolution.
In both cases, it will be faster than transforming to DOM.
Simone
Simone Tripodi wrote:
Hi Sylvain,
indeed, that's yet another exception I didn't think, thanks for your
clarification!!!
Bonne journée, a bientot ;)
Simo
On Mon, Nov 23, 2009 at 8:28 AM, Sylvain Wallez <[email protected]> wrote:
Jos Snellings wrote:
Hmmm, I guess the XPath expression is known before the parsing begins?
I remember I have done a similar thing, where a chunk had to be isolated
from a document that came by via a SAX stream, but here the xpath
expression was something like: "/element1/elemen...@id=somenumber]".
Theorem: any XPath expression can be evaluated with a SAX filter.
Proof?
Do you know some exceptions?
What about this one : //foo[bar[position() = 3]//baz], find all elements
"foo" whose 3rd "bar" child has a "baz" descendent element.
This requires to buffer the contents of every "foo" element to inspect their
chidren sub-tree.
Sylvain
--
Sylvain Wallez - http://bluxte.net
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
