commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject [jxpath] Future of JXPath and DOM???
Date Wed, 09 Feb 2005 02:55:35 GMT
I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny 
wrapper API so we can change implementations fairly painlessly.

I'd like to use something more recent and was looking at JXPath, but I 
note that the sources contain "TO_DO" comments about using Xalan as the 
backing XPath implementation -- for the DOM case presumably.

Is this the plan?  If not, what is?

If this is the plan, then there is no reason for me to switch from Xalan 
to JXPath -- as I only care about XPath usage against DOMs (not JDOM, 
other beans, etc).

You may ask why I'm on such an old Xalan or why I'm looking for 
something other than Xalan -- which are good questions...

Essentially, recent versions of Xalan are missing the boat on some 
important XPath use cases.  Xalan 2.1.0 is the last version of Xalan 
which does not have immense performance penalties for my use cases.  
Specifically, my use case is:

   1. Parse/compile XPath expressions.
   2. Use these expressions against many different DOMs.
          * I /rarely /use a given XPath against the same DOM (without
            intervening changes) twice.
                o I /often /use a given XPath against many, many
                  different DOMs.
          * I /even more rarely /know that when I use an XPath on a DOM
            it will not be changing prior to it being used again.
          * I /often /need to use XPath to retrieve a list of DOM nodes
            to be edited or deleted -- followed by edits directly via
            DOM APIs and more use of other XPaths ad nauseum (e.g. based
            on GUI picks).

After Xalan 2.1.0, the XPath portion of Xalan was optimized for the 
antithesis of this use case, i.e. it builds a DTM (document table model) 
for each DOM an XPath is used against -- which is a tremendous waste of 
time and memory if the XPath is all but certainly not going to be used 
against the given DOM (without intervening changes) more than once.  I 
found cases of 500% performance improvement by moving back from more 
recent Xalan versions to 2.1.0 for these use cases!  The Xalan team 
knows about this issue, but despite the fact that this directly affects 
the XPath API exposed in Java 1.5 this issue seems 
unimportant/uninteresting to them as compared to optimizing for the XSLT 
use case -- where the DTM approach makes sense since the DTM is formed 
once and acted upon by many XPaths many times.

Some time ago I looked at both JXPath and Jaxen as possible replacements 
for Xalan 2.1.0.  Unfortunately, both of these XPath libraries had major 
issues with evaluating some rather simple XPath expressions at the time 
-- and I need good fidelity to the XPath standard (at least as good as 
Xalan 2.1.0).  I believe Jaxen is at the same version now as it was when 
I last tested it, but JXPath has had an update or two since then -- so I 
was going to try again until I saw the aforementioned "TO_DO" in the 
source code.  If JXPath is not going to be a long-term contender for the 
my use cases, then I just have to continue using Xalan 2.1.0 (which I've 
move to another package using Ant -- similar to what Sun has done in 
Java 1.5 -- so as not to conflict with any other Xalan versions).

So all that said, I'd appreciate any feedback as to:

    * the intended direction of JXPath,
    * the level of commitment to the XPath standard, and
    * the level of commitment to supporting the non-XSLT DOM use case
      outlined above.

--
Jess Holle


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message