Hi Michael & all, On Sat, Nov 20, 2010 at 1:04 AM, Michael Glavassevich <[email protected]> wrote: > Functionally that's good enough, but the benefit of having the subset > processor within Xerces would be improved performance for the common > scenarios. Would be really nice if we could avoid building up DOM nodes in > the CTA processing for simple XPath expressions which don't need them. I > understand you have to build a DOM as input for Psychopath, plus possibly > some other overhead we can avoid with our own processor.
It may probably be fine as well, if we keep the current CTA evaluation as it is (i.e we first attempt to evaluate CTA XPath expressions with the Xerces native XPath parser implementation, and then fall back to PsychoPath XPath engine as a fall back option). I agree with Michael over the benefits of this approach. Another option we can probably explore is, to provide an option to users to use a JVM system property as following [1]: xerces.ctaxpath.mode=[native | full | both] with "both" being the currently implemented behavior, and can be the default for this feature. I would say the following should be meant by the above options, native: use only the native XPath subset full: use only the PsychoPath XPath engine both: use the CTA XPath evaluation as it's implemented presently (i.e use PsychoPath engine as a fallback option). in case we'll use an option "both" a warning can be displayed to users before falling back to the PsychoPath engine. In case we would like to do anything as specified above, I would propose to have this change happen post Xerces 2.11.0 release. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
