XML parsing memory overhead concerns

[Clark C. Evans]

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 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;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)