On Wed, Nov 24, 2010 at 12:39 AM, Michael Glavassevich <[email protected]> wrote: > Hi Mukul, > > Mukul Gandhi <[email protected]> wrote on 11/19/2010 07:02:40 PM: > >> 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'm really not a fan of using system properties to configure the parser. See > my last response on a request [1] to add one to Xerces. Users should be > setting their preferences per parser/validator instance (through JAXP API > setProperty() calls) so that they don't affect the configuration of > parsers/validators being used by other applications within the JVM.
Agreed. This can cause lot of issues in scenarios where multiple applications are running on the same app server. Thanks, Hiranya > > Also not sure we want to expose this complexity (i.e. the choices we make > internally on which XPath processor to use) to the user. Ideally Xerces > would make the best choices for each of the XPath expressions in their > schema and then the user doesn't need to worry about such details. > >> 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] > > Thanks. > > [1] http://issues.apache.org/jira/browse/XERCESJ-1455 > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [email protected] > E-mail: [email protected] -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
