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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -----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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
