[
Lists Home |
Date Index |
Thread Index
]
> * have the SAX stream kept cached for the lifetime of the document
> (or have some kind of weak reference perhaps) since they are in memory
> anyway (though unreachable), allowing backward-looking XPaths; or
XPath comes up here and came up in several of the other responses. Perhaps
someone could answer what class of XPaths, if known prior to document parse,
can not be satisfied during the document parsing?
<root>
<child name="C1">Foo</child>
<child name="C2">Bar</child>
</root>
If, before parsing, we know that we need to satisfy
"/root/child[@name='C2']" Why could this not be satisfied? Maybe coming up
with a common SAX->XPath->Results Filter which had a standard mechanism
(e.g. Interface?) for passing back XPath results as encountered in the
process of a SAX stream would be a good plan.
It strikes me that even the preceding-sibling and ancestor axes could be
handled with a simple stack. This would still limit memory consumption and
the objects in the stack could be reused for different "branches".
If all of this was embedded in an interface so that you could register
XPaths before the document parse, and then receive callbacks (or store) the
results of those XPaths you would have something pretty nice. Does this
already exist?
Cheers,
Jeff Rafter
|
