Cart
[Home] [By Thread] [By Date] [Recent Entries]
Rick Jelliffe wrote: > > I am idly wondering whether unpooled steaming Java APIs of XML documents (e.g. SAX) > really make as much sense as we might like them to. I've been wondering why we have such absolute either-or choices in available APIs. Why not hybridized APIs that provide event streams, but let you collect arbitrary spans of content into an object model that can be more easily manipulated and accessed without needing a complete in-memory tree model of the entire document? I think both SAX and tree APIs are unweildy to work with. I'm more interested in rule-based and pattern-based approaches, but prefer not to have to build a complete in-memory model of the entire document to enable such an approach. > > It strikes me that there are two factors that undermine the benefits of streaming processing: > > * XML documents are rarely smaller than memory > * Java implementations typically only garbage collect when they get "near" > to filling their heaps. > > These two things conspire to make it that, for the lion's share of documents, > by the time the SAX stream is finished, all the SAX events will be still > in memory, though perhaps unreachable. If they are in memory, why not > make them available? > > That being the case, it seems that simple streaming such as SAX provides > don't make sense. They would be better to either > > * 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 Pooling objects using weak references incurs a small performance penalty (I've experimented a bit with such approaches, though not for SAX events). In the context of a real-world application this penalty is likely to be pretty minimal. Nonetheless, if someone is using SAX, it may be becaused they are trying to maximize performance. > > * requiring SAX clients return events to a pool (which would reduce > memory use). > > Does that sound right to anyone? The approach I'm experimenting with, right now, in my swan toolkit (http://swan.sourceforge.net) is maintaining a stack to support backward-looking XPaths and XSLT pattern-matching, melded with rules that can gather content into suitable data structures for relevant portions of a document. As part of that, I have a prefab rule one can use to gather up a fragment into a minimalistic tree API that supports XPath queries. This could easily be adapted to use a full-fledged tree API for the fragment, but I was more interested in using XPath expressions than navigating unweildy tree APIs. This is still all in a rough state. I haven't done a file release of this code, yet, and some key portions are not in CVS, yet (due to some problems I've been having with CVS integration with Eclipse). I've also been letting this languish the last few weeks, but am starting to get back into it this weekend. I've been approaching this in a rather lazy fashion (my motivation has been admittedly low), but I hope to have an alpha release of something soon.
|
