Re: XPath over DOM

>I think most of the Java XSLT processors do this by having a wrapper layer
>above the DOM, with a significant performance penalty over using a direct
>implementation of the XPath tree model. Saxon is an exception, but it is a
>recognized requirement.

Since I think this could be of interest to some people, here's my summary of
the feedback I got for XSLT processors traversing directly over DOM:

o Xalan-J v1: I heard that it has its own DTM, but hasn't verified that.

o Xalan-J v2: Yes.

o Oracle: Michael Kay says yes, but from looking at APIs, it appears to use
Oracle parser's DOM implementation objects. Can someone confirm one way or
the other?

o XT: Yes, but disclaimed on the website as "significantly less functional
and much slower". I would love to see some quantification for
"significantly" and "much", if anyone has run any tests...

o Rasin: Yes, but may possibly move away from that implementation in the
future.


Also, the wrapper layer that Michael mentioned has gotten me slightly
worried: if the wrapper is memory intensive enough, it could be just as bad
as reparsing the document into own DTM. If I use persistence-based DOM
implementation (for example, a database that supports DOM APIs), I
theoretically should be able to handle XML documents of any size; but if the
size of XPath-specific objects grows linearly with the size of the document,
that seems like it could cause a problem. Could the experts who are familiar
with internals of any of these processors roughly estimate amount of memory
taken up by wrappers with respect to the size of the original XML document?
Or am I just overthinking it?

Any comments would be most welcome. 

Thanks,

- Eugene

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list