You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Angel Todorov <at...@gmail.com> on 2007/04/12 19:51:28 UTC

[axiom] AXIOM XPath support

Hi all,

I can see AXIOM has support for XPath. But beneath it is a StAX
parser, and such pull-parsers don't have random access support for XML
documents, by design.

So my question is: Do you call build() on the OM Tree that one wants
to lookup with XPath? That is, do you cache everything in memory in
order to support such xpath operations, or you preserve the full
advantages of a pull-based parser ?

Thank you in advance.

Regards,
Angel

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


Re: [axiom] AXIOM XPath support

Posted by Dan Diephouse <da...@envoisolutions.com>.
Well it can already integrate with Axiom. Axiom can give you an
XMLStreamReader, and you can pass that off to SXC. :-)

BTW, SXC build's on Jaxen's parser so it still requires jaxen. In essence
SXC just provides a new runtime for it.

- Dan

On 4/24/07, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Great !! I'd love to see it integrated in to Axiom if it is better than
> Jaxen.
>
> Since you are the creator/father/founder/ of SXC, any idea to integrate
> it with Axiom?
>
> Thanks a lot Dan, in advance :)
>
> - -- Chinthaka
>
> Dan Diephouse wrote:
> > I realize that this is a little late in response to the original
> poster's
> > question, but you may want to check out SXC - http://sxc.codehaus.org.
> It
> > doesn't have complete XPath support, but for simple expressions it can
> > create an optimized streaming stax parser which listens for your XPath
> > expressions. Its VERY fast.
> >
> > Disclaimer: I wrote SXC :-)
> >
> > Cheers,
> > - Dan
> >
> > On 4/22/07, Eran Chinthaka <ch...@opensource.lk> wrote:
> >>
> > I assume no one had answered this email.
> >
> > Anyway, yes we build the whole object model internally to provide XPath
> > support. We have not implemented XPath on top of AXIOM or Stax. We
> > simply plugin in Jaxen document navigator mechanism to provide XPath
> > support.
> >
> > Couple of things to note here. Most of the queries that we encounter
> > requires the whole model to be build. So the 90% case looks at the whole
> > object model. If we try to optimize for the 10% case, then that might
> > lead to performance drawbacks of the system.
> >
> > These days I am looking at some of the techniques in SDI systems
> > (Selective Dissemination of Information) to be used inside Axiom. But I
> > am yet to find an efficient way to do this with a pull parser. Most of
> > them tries to exploit on the shared paths of the queries, but I think we
> > won't execute more than couple of XPaths against a given object model.
> > So if you find a better way of implementing XPath over Axiom, please do
> > let us know or even help us by implementing it.
> >
> > Thanks,
> > Chinthaka
> >
> > Angel Todorov wrote:
> >> Hi all,
> >
> >> I can see AXIOM has support for XPath. But beneath it is a StAX
> >> parser, and such pull-parsers don't have random access support for XML
> >> documents, by design.
> >
> >> So my question is: Do you call build() on the OM Tree that one wants
> >> to lookup with XPath? That is, do you cache everything in memory in
> >> order to support such xpath operations, or you preserve the full
> >> advantages of a pull-based parser ?
> >
> >> Thank you in advance.
> >
> >> Regards,
> >> Angel
> >
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
> >
> >>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >>
> >>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGLZvyjON2uBzUhh8RApcfAKCXNi6zhn7qsaWfjmlmFAn5XqYoCwCbBzx/
> koNEk9WaC68QJXZwF/e9iTE=
> =rGBz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [axiom] AXIOM XPath support

Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Great !! I'd love to see it integrated in to Axiom if it is better than
Jaxen.

Since you are the creator/father/founder/ of SXC, any idea to integrate
it with Axiom?

Thanks a lot Dan, in advance :)

- -- Chinthaka

Dan Diephouse wrote:
> I realize that this is a little late in response to the original poster's
> question, but you may want to check out SXC - http://sxc.codehaus.org. It
> doesn't have complete XPath support, but for simple expressions it can
> create an optimized streaming stax parser which listens for your XPath
> expressions. Its VERY fast.
> 
> Disclaimer: I wrote SXC :-)
> 
> Cheers,
> - Dan
> 
> On 4/22/07, Eran Chinthaka <ch...@opensource.lk> wrote:
>>
> I assume no one had answered this email.
> 
> Anyway, yes we build the whole object model internally to provide XPath
> support. We have not implemented XPath on top of AXIOM or Stax. We
> simply plugin in Jaxen document navigator mechanism to provide XPath
> support.
> 
> Couple of things to note here. Most of the queries that we encounter
> requires the whole model to be build. So the 90% case looks at the whole
> object model. If we try to optimize for the 10% case, then that might
> lead to performance drawbacks of the system.
> 
> These days I am looking at some of the techniques in SDI systems
> (Selective Dissemination of Information) to be used inside Axiom. But I
> am yet to find an efficient way to do this with a pull parser. Most of
> them tries to exploit on the shared paths of the queries, but I think we
> won't execute more than couple of XPaths against a given object model.
> So if you find a better way of implementing XPath over Axiom, please do
> let us know or even help us by implementing it.
> 
> Thanks,
> Chinthaka
> 
> Angel Todorov wrote:
>> Hi all,
> 
>> I can see AXIOM has support for XPath. But beneath it is a StAX
>> parser, and such pull-parsers don't have random access support for XML
>> documents, by design.
> 
>> So my question is: Do you call build() on the OM Tree that one wants
>> to lookup with XPath? That is, do you cache everything in memory in
>> order to support such xpath operations, or you preserve the full
>> advantages of a pull-based parser ?
> 
>> Thank you in advance.
> 
>> Regards,
>> Angel
> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: commons-dev-help@ws.apache.org
> 
> 
> 
>>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLZvyjON2uBzUhh8RApcfAKCXNi6zhn7qsaWfjmlmFAn5XqYoCwCbBzx/
koNEk9WaC68QJXZwF/e9iTE=
=rGBz
-----END PGP SIGNATURE-----

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


Re: [axiom] AXIOM XPath support

Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Ajith,

On 4/23/07, Ajith Ranabahu <aj...@gmail.com> wrote:
>
> Hi,
> Here is what I think of this
>
> 1. I believe it is fundamentally impossible to implement full XPath
> spec on a streaming parser model for the simple reason that the parser
> 'forgets' whatever it did. Xpath has constructs that refer back to
> nodes that it parsed. Also in a more generic manner you expect to run
> more than one Xpath query on the XML which is impossible in a pure
> streaming parser. Bottom line is if you need full XPath support then
> you obviously need an object model.


I think you're thinking a little too narrowly here.  In the next release I'd
like to add a caching mode to to SXC. When we compile an xpath expression we
can realize that we will have to cache certain nodes. For instance, if I
have the expression /a/b/c/../d - I can know that I have to cache all of
(b). Using the compiler we can just put this in as one of the constraints.
Then whenever we encounter /a/b/c, we can backtrack and check if there
exists a ../d.

I think ultimately you can support both streaming xpath event triggers and
the non streaming cases. Because its all compiler based, the compiler can
just magically take care of it and find the optimized parser for the
particular set of expressions that you're listening for as you move over the
document. And if you never enocunter /a/b you don't have to cache anything
at all.

Its just a matter of finding the time to implement these features. Y'all are
welcome to help out :-)

2. If you do not want the full functionality of XPath and your
> scenarios are more like 'one query at a time' - then it is possible to
> do a straight XPath like implementation on a streaming parser (like
> Dan's SXC). Once again these would only have a subset of XPath
> constructs.


So ultimately it depends on what you want to do :)


I disagree. See above :-)

Ajith
> On 4/23/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > I realize that this is a little late in response to the original
> poster's
> > question, but you may want to check out SXC - http://sxc.codehaus.org.
> It
> > doesn't have complete XPath support, but for simple expressions it can
> > create an optimized streaming stax parser which listens for your XPath
> > expressions. Its VERY fast.
> >
> > Disclaimer: I wrote SXC :-)
> >
> > Cheers,
> > - Dan
> >
> > On 4/22/07, Eran Chinthaka <ch...@opensource.lk> wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > I assume no one had answered this email.
> > >
> > > Anyway, yes we build the whole object model internally to provide
> XPath
> > > support. We have not implemented XPath on top of AXIOM or Stax. We
> > > simply plugin in Jaxen document navigator mechanism to provide XPath
> > > support.
> > >
> > > Couple of things to note here. Most of the queries that we encounter
> > > requires the whole model to be build. So the 90% case looks at the
> whole
> > > object model. If we try to optimize for the 10% case, then that might
> > > lead to performance drawbacks of the system.
> > >
> > > These days I am looking at some of the techniques in SDI systems
> > > (Selective Dissemination of Information) to be used inside Axiom. But
> I
> > > am yet to find an efficient way to do this with a pull parser. Most of
> > > them tries to exploit on the shared paths of the queries, but I think
> we
> > > won't execute more than couple of XPaths against a given object model.
> > > So if you find a better way of implementing XPath over Axiom, please
> do
> > > let us know or even help us by implementing it.
> > >
> > > Thanks,
> > > Chinthaka
> > >
> > > Angel Todorov wrote:
> > > > Hi all,
> > > >
> > > > I can see AXIOM has support for XPath. But beneath it is a StAX
> > > > parser, and such pull-parsers don't have random access support for
> XML
> > > > documents, by design.
> > > >
> > > > So my question is: Do you call build() on the OM Tree that one wants
> > > > to lookup with XPath? That is, do you cache everything in memory in
> > > > order to support such xpath operations, or you preserve the full
> > > > advantages of a pull-based parser ?
> > > >
> > > > Thank you in advance.
> > > >
> > > > Regards,
> > > > Angel
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.3 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > >
> > > iD8DBQFGKvB7jON2uBzUhh8RAkJEAJ9yqlA0nstaPTqjLJ29+Y/tMwT3RwCdF03i
> > > /jAVEytjTZuXHGrhfuwxNW0=
> > > =9Fqs
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
> --
> Ajith Ranabahu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [axiom] AXIOM XPath support

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
Here is what I think of this

1. I believe it is fundamentally impossible to implement full XPath
spec on a streaming parser model for the simple reason that the parser
'forgets' whatever it did. Xpath has constructs that refer back to
nodes that it parsed. Also in a more generic manner you expect to run
more than one Xpath query on the XML which is impossible in a pure
streaming parser. Bottom line is if you need full XPath support then
you obviously need an object model.

2. If you do not want the full functionality of XPath and your
scenarios are more like 'one query at a time' - then it is possible to
do a straight XPath like implementation on a streaming parser (like
Dan's SXC). Once again these would only have a subset of XPath
constructs.

So ultimately it depends on what you want to do :)

Ajith
On 4/23/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> I realize that this is a little late in response to the original poster's
> question, but you may want to check out SXC - http://sxc.codehaus.org. It
> doesn't have complete XPath support, but for simple expressions it can
> create an optimized streaming stax parser which listens for your XPath
> expressions. Its VERY fast.
>
> Disclaimer: I wrote SXC :-)
>
> Cheers,
> - Dan
>
> On 4/22/07, Eran Chinthaka <ch...@opensource.lk> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I assume no one had answered this email.
> >
> > Anyway, yes we build the whole object model internally to provide XPath
> > support. We have not implemented XPath on top of AXIOM or Stax. We
> > simply plugin in Jaxen document navigator mechanism to provide XPath
> > support.
> >
> > Couple of things to note here. Most of the queries that we encounter
> > requires the whole model to be build. So the 90% case looks at the whole
> > object model. If we try to optimize for the 10% case, then that might
> > lead to performance drawbacks of the system.
> >
> > These days I am looking at some of the techniques in SDI systems
> > (Selective Dissemination of Information) to be used inside Axiom. But I
> > am yet to find an efficient way to do this with a pull parser. Most of
> > them tries to exploit on the shared paths of the queries, but I think we
> > won't execute more than couple of XPaths against a given object model.
> > So if you find a better way of implementing XPath over Axiom, please do
> > let us know or even help us by implementing it.
> >
> > Thanks,
> > Chinthaka
> >
> > Angel Todorov wrote:
> > > Hi all,
> > >
> > > I can see AXIOM has support for XPath. But beneath it is a StAX
> > > parser, and such pull-parsers don't have random access support for XML
> > > documents, by design.
> > >
> > > So my question is: Do you call build() on the OM Tree that one wants
> > > to lookup with XPath? That is, do you cache everything in memory in
> > > order to support such xpath operations, or you preserve the full
> > > advantages of a pull-based parser ?
> > >
> > > Thank you in advance.
> > >
> > > Regards,
> > > Angel
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >
> > >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGKvB7jON2uBzUhh8RAkJEAJ9yqlA0nstaPTqjLJ29+Y/tMwT3RwCdF03i
> > /jAVEytjTZuXHGrhfuwxNW0=
> > =9Fqs
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>


-- 
Ajith Ranabahu

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


Re: [axiom] AXIOM XPath support

Posted by Dan Diephouse <da...@envoisolutions.com>.
I realize that this is a little late in response to the original poster's
question, but you may want to check out SXC - http://sxc.codehaus.org. It
doesn't have complete XPath support, but for simple expressions it can
create an optimized streaming stax parser which listens for your XPath
expressions. Its VERY fast.

Disclaimer: I wrote SXC :-)

Cheers,
- Dan

On 4/22/07, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I assume no one had answered this email.
>
> Anyway, yes we build the whole object model internally to provide XPath
> support. We have not implemented XPath on top of AXIOM or Stax. We
> simply plugin in Jaxen document navigator mechanism to provide XPath
> support.
>
> Couple of things to note here. Most of the queries that we encounter
> requires the whole model to be build. So the 90% case looks at the whole
> object model. If we try to optimize for the 10% case, then that might
> lead to performance drawbacks of the system.
>
> These days I am looking at some of the techniques in SDI systems
> (Selective Dissemination of Information) to be used inside Axiom. But I
> am yet to find an efficient way to do this with a pull parser. Most of
> them tries to exploit on the shared paths of the queries, but I think we
> won't execute more than couple of XPaths against a given object model.
> So if you find a better way of implementing XPath over Axiom, please do
> let us know or even help us by implementing it.
>
> Thanks,
> Chinthaka
>
> Angel Todorov wrote:
> > Hi all,
> >
> > I can see AXIOM has support for XPath. But beneath it is a StAX
> > parser, and such pull-parsers don't have random access support for XML
> > documents, by design.
> >
> > So my question is: Do you call build() on the OM Tree that one wants
> > to lookup with XPath? That is, do you cache everything in memory in
> > order to support such xpath operations, or you preserve the full
> > advantages of a pull-based parser ?
> >
> > Thank you in advance.
> >
> > Regards,
> > Angel
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGKvB7jON2uBzUhh8RAkJEAJ9yqlA0nstaPTqjLJ29+Y/tMwT3RwCdF03i
> /jAVEytjTZuXHGrhfuwxNW0=
> =9Fqs
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [axiom] AXIOM XPath support

Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I assume no one had answered this email.

Anyway, yes we build the whole object model internally to provide XPath
support. We have not implemented XPath on top of AXIOM or Stax. We
simply plugin in Jaxen document navigator mechanism to provide XPath
support.

Couple of things to note here. Most of the queries that we encounter
requires the whole model to be build. So the 90% case looks at the whole
object model. If we try to optimize for the 10% case, then that might
lead to performance drawbacks of the system.

These days I am looking at some of the techniques in SDI systems
(Selective Dissemination of Information) to be used inside Axiom. But I
am yet to find an efficient way to do this with a pull parser. Most of
them tries to exploit on the shared paths of the queries, but I think we
won't execute more than couple of XPaths against a given object model.
So if you find a better way of implementing XPath over Axiom, please do
let us know or even help us by implementing it.

Thanks,
Chinthaka

Angel Todorov wrote:
> Hi all,
> 
> I can see AXIOM has support for XPath. But beneath it is a StAX
> parser, and such pull-parsers don't have random access support for XML
> documents, by design.
> 
> So my question is: Do you call build() on the OM Tree that one wants
> to lookup with XPath? That is, do you cache everything in memory in
> order to support such xpath operations, or you preserve the full
> advantages of a pull-based parser ?
> 
> Thank you in advance.
> 
> Regards,
> Angel
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGKvB7jON2uBzUhh8RAkJEAJ9yqlA0nstaPTqjLJ29+Y/tMwT3RwCdF03i
/jAVEytjTZuXHGrhfuwxNW0=
=9Fqs
-----END PGP SIGNATURE-----

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