[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Does SAX make sense?
> * 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|