Cart
[Home] [By Thread] [By Date] [Recent Entries]
> Is holding the document in memory not an option? Because if you can hold > it all in memory, it's simple enough to build a tree representation of the > thing, then walk the tree with your handlers, then throw away the tree. I thought about that at first, and I could do it easily over expat (or SAX). In fact, I could even keep the same API I came up with, because then I'd just be dealing with a DOM-like representation. However, for "large" data-files (several megabytes worth), this could be a problem, because the in-memory representation could be many megabytes larger (consider a 3D model with 10,000 vertices, each one with a <Vertex></Vertex> pair). I suppose I could minimize the amount of extra memory usage by using hash tables, but I tend to prefer to streaming solution. I was going under the assumption that for this type of use, namespaces and validation probably aren't necessary, so there aren't that many advantages to layering over expat. > If that isn't an option, then I agree that you have a combination of: > 1) A nice interface paradigm (you could even generate a stub of the program > from a DTD!); and, > 2) Quite a challenge getting an event-based parser to work with it because > of control-flow issues. Thanks, and yeah, it would be/is a real effort to match this idiom to expat. > Here's a nutty idea -- Try threads. Run the parser and expat as two Ouch! :-) You get an 'A' for creativity! -Paul -- Paul Miller - stele@f... 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...)
|
