Jess, JXPath has always supported Xalan through JAXP DOM APIs. What you may have seen in the source code of JXPath is some attempts to optimize JXPath when it is used specifically in combination with Xalan. You would not be interested in that optimization, because it would only be applied to static DOM and take advantage of DTM. Try using JXPath and let us know how it works out. - Dmitri
Jess Holle <[EMAIL PROTECTED]> wrote: P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
