XML parsing memory overhead concerns
Clark C. Evans
clark.evans at manhattanproject.com
Fri Dec 17 05:12:25 GMT 1999
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:
> ... 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.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev