Re: XML parsing memory overhead concerns
On 16 Dec 1999, Stephen R. Savitzky wrote: > This is probably similar to what I'm using: the parser's API is basically > a tree traverser: it has methods like: > > toNextSibling > toFirstChild > toParent > ... and a bunch of methods to examine the current node. > > Though it's DOM-like, you never actually have to build the whole tree. So, some random access storage is needed with this technique? > It does have the feature (some might call it a bug) that you're processing > large chunks of the document before you know that it doesn't validate. > Since I deal with human-written documents I consider it a feature, since it > permits graceful error recovery. Not a problem. > I believe there's a low-level module in expat that can handle the lexical > part of the parsing but still be called in pull mode. Or you could use > "full" expat if you have threads (i.e. run expat as a coroutine). Why not have expat build the sub tree you are interested, put it in memory. You can then "pull" from this? > But like you, I'd really like to see a traversal-oriented (pull) parser API > to go along with the current event-oriented (push) ones. There are times > when it's just the right thing to do. I'd like to hear *much* more about this. Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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