• From: Tatu Saloranta <cowtowncoder@y...>
• To: 'XML List Developers' <xml-dev@l...>
• Date: Tue, 3 Oct 2006 16:49:03 -0700 (PDT)

--- Philippe Poulard
<Philippe.Poulard@s...> 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 

• Follow-Ups:
  • RE: Disk-based XPath Processing
    • From: "Michael Kay" <mike@s...>

• References:
  • Re: Disk-based XPath Processing
    • From: Philippe Poulard <Philippe.Poulard@s...>