XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Disk-based XPath Processing

--- Philippe Poulard
<Philippe.Poulard@sophia.inria.fr> wrote:

> Michael Kay wrote:
...
> To conclude, I'm sure that it's better to get round
> rather than trying 
> to get a straight solution hard to accomplish with
> SAX.

If I understood Saxon-SA page correctly, this is what
it does: builds trees only if and as necessary,
otherwise discards events as it goes.

For my specific use case, I would want to locate the
node(s), after which one can choose to build a
sub-tree, or do whatever operation is necessary
(including just traversing sub-tree as a sub-stream).
Not having access outside of sub-tree(s) identified by
the node(s) in question is fine; as would be
restrictions like not including overlapping result
sub-trees.

Since the whole traversal is based on (synchronized)
iterators, not SAX, it should work ok within
boundaries of never caching anything outside of
matching sub-tree. This is the other possible
trade-off (first being 'discard if you can; build tree
if you must').

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS