Hi Ajith, On 4/23/07, Ajith Ranabahu <[EMAIL PROTECTED]> 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 <[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]
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
