You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Michael Glavassevich <mr...@ca.ibm.com> on 2010/11/19 20:34:57 UTC

XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

(Changing the subject line ...)

Hiranya Jayathilaka <hi...@apache.org> wrote on 11/19/2010 02:01:00 PM:

...

> If the XPath subset has been completely removed from the spec, it
> probably makes sense to just use the Psychopath parser in all
> scenarios. Otherwise XPath processing becomes a two-step job:
>
> step 1: Identifying whether the XPath falls in the (now deprecated)
subset
> step 2: Parsing the tokens
>
> WDYT?

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.

> Thanks,
> Hiranya

...

> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Sat, Nov 20, 2010 at 5:32 AM, Mukul Gandhi <mu...@apache.org> wrote:
> Hi Michael & all,
>
> On Sat, Nov 20, 2010 at 1:04 AM, Michael Glavassevich
> <mr...@ca.ibm.com> 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.

Yes. I also believe that we shouldn't make this change with a release
coming up very soon. Also the publicly available version of the
specification still has the restriction on the allowed XPath
expressions. So we should be fine at the moment.

Thanks,
Hiranya

>
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>



-- 
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Mukul Gandhi <mu...@apache.org>.
On Wed, Nov 24, 2010 at 9:58 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> That's how we should add new configuration parameters when there's a need
> for them, but I was really suggesting that we not add one at all and just
> let Xerces figure out the best thing to do based on its analysis of the
> user's schema.

Thanks, Michael. I agree.



-- 
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Mukul,

Mukul Gandhi <mu...@apache.org> wrote on 11/23/2010 07:36:32 PM:

> Hi Michael,
>    I agree with you.
>
> Are you suggesting that we can probably design and implement a new
> Xerces specific property, something like those described at
> http://xerces.apache.org/xerces2-j/properties.html for selecting the
> XPath flavor (something like "native, full & both" that I wrote
> earlier) for XML Schema 1.1 CTA evaluations?

That's how we should add new configuration parameters when there's a need
for them, but I was really suggesting that we not add one at all and just
let Xerces figure out the best thing to do based on its analysis of the
user's schema.

> Though I'm also fine with keeping the current implementation as it is
> (i.e use Xerces native XPath support as default, and fall back to
> PsychoPath engine if the XPath expressions are more generic). We might
> also wait for Xerces adopters to show enough interest in this matter,
> before we do such a design change into Xerces.
>
> On Wed, Nov 24, 2010 at 12:39 AM, Michael Glavassevich
> <mr...@ca.ibm.com> wrote:
> > 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.
> >
> > 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.
>
> >
> > Thanks.
> >
> > [1] http://issues.apache.org/jira/browse/XERCESJ-1455
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
>
>
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Mukul Gandhi <mu...@apache.org>.
Hi Michael,
   I agree with you.

Are you suggesting that we can probably design and implement a new
Xerces specific property, something like those described at
http://xerces.apache.org/xerces2-j/properties.html for selecting the
XPath flavor (something like "native, full & both" that I wrote
earlier) for XML Schema 1.1 CTA evaluations?

Though I'm also fine with keeping the current implementation as it is
(i.e use Xerces native XPath support as default, and fall back to
PsychoPath engine if the XPath expressions are more generic). We might
also wait for Xerces adopters to show enough interest in this matter,
before we do such a design change into Xerces.

On Wed, Nov 24, 2010 at 12:39 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> 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.
>
> 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.

>
> Thanks.
>
> [1] http://issues.apache.org/jira/browse/XERCESJ-1455
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org




-- 
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Wed, Nov 24, 2010 at 12:39 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> Hi Mukul,
>
> Mukul Gandhi <mu...@apache.org> wrote on 11/19/2010 07:02:40 PM:
>
>> Hi Michael & all,
>>
>> On Sat, Nov 20, 2010 at 1:04 AM, Michael Glavassevich
>> <mr...@ca.ibm.com> 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: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
> Thanks.
>
> [1] http://issues.apache.org/jira/browse/XERCESJ-1455
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org



-- 
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Mukul,

Mukul Gandhi <mu...@apache.org> wrote on 11/19/2010 07:02:40 PM:

> Hi Michael & all,
>
> On Sat, Nov 20, 2010 at 1:04 AM, Michael Glavassevich
> <mr...@ca.ibm.com> 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.

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: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Thanks.

[1] http://issues.apache.org/jira/browse/XERCESJ-1455

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: XPath 2.0 support for CTA (was: [jira] Resolved: (XERCESJ-1433) ...)

Posted by Mukul Gandhi <mu...@apache.org>.
Hi Michael & all,

On Sat, Nov 20, 2010 at 1:04 AM, Michael Glavassevich
<mr...@ca.ibm.com> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org