Re: [jxpath] Future of JXPath and DOM???
So if such an optimization was added there would be a way to by-pass it as well? [This can't just be if Xalan is not present -- as Xalan is present for other reasons.] -- Jess Holle Dmitri Plotnikov wrote: 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]
Re: [jxpath] Future of JXPath and DOM???
Dmitri Plotnikov wrote: 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. Dumb question (which I probably figured out last time I tried this stuff, but have no notes/recollection of): Is there an equivalent of Xalan's one-size-fits-all XObject xobj = xpath.execute(...) mechanism in JXPath? I'm looking for a CompiledExpression.getValue() that returns an Object for which: 1. I know the various possible return types when this is applied to a DOM. 2. The result is the most appropriate (as per the XPath standard) of the following: * NodeList or NodeIterator -- or something from which I can easily implement one or both of these interfaces * Boolean * Number * String [I assume callers will apply includes castes within their XPath expressions as necessary where they expect a non-node result.] Is there such a beast? The one-API fits all (beans, JDOM, DOM, etc) approach makes this a bit hard for me to decipher. -- Jess Holle
Re: [jxpath] Future of JXPath and DOM???
Jess, First of all, this discussion is probably better suited to the commons-user mailing list. As far as your specific questions are concerned, getValue() will always return a primitive value (Number, Boolean or String) when applied to DOM. selectSingleNode() will return either a primitive value or a DOM Node. Regards, - Dmitri Jess Holle [EMAIL PROTECTED] wrote: Dmitri Plotnikov wrote: 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. Dumb question (which I probably figured out last time I tried this stuff, but have no notes/recollection of): Is there an equivalent of Xalan's one-size-fits-all XObject xobj = xpath.execute(...) mechanism in JXPath? I'm looking for a CompiledExpression.getValue() that returns an Object for which: 1. I know the various possible return types when this is applied to a DOM. 2. The result is the most appropriate (as per the XPath standard) of the following: * NodeList or NodeIterator -- or something from which I can easily implement one or both of these interfaces * Boolean * Number * String [I assume callers will apply includes castes within their XPath expressions as necessary where they expect a non-node result.] Is there such a beast? The one-API fits all (beans, JDOM, DOM, etc) approach makes this a bit hard for me to decipher. -- Jess Holle
Re: [jxpath] Future of JXPath and DOM???
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]
Re: [jxpath] Future of JXPath and DOM???
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]
Re: [jxpath] Future of JXPath and DOM???
Jess, Sorry, I misspoke. Of course, what I wanted to say was that JXPath has always supported Xerces, which is the XML parser bundled with Xalan. Thus, it can work side-by-side with Xalan. - Dmitri Dmitri Plotnikov [EMAIL PROTECTED] wrote: 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 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]
Re: [jxpath] Future of JXPath and DOM???
Hi, I am also looking at the same optimization, but not in a way that Xalan handles the xpath, but in such a way that a metamodel (DOM or your own) can optimize the query implementation itself. I was thinking of having a nodepointer recognizing the model, and having the option to pass the jxpath expression to the actual model implementation. Right now I don't have ideas on the actual implementation, but any ideas from others on the subject are welcome. Any thoughts of such an implementation? Michael Jess, Sorry, I misspoke. Of course, what I wanted to say was that JXPath has always supported Xerces, which is the XML parser bundled with Xalan. Thus, it can work side-by-side with Xalan. - Dmitri Dmitri Plotnikov [EMAIL PROTECTED] wrote: 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 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,
