Cart
[Home] [By Thread] [By Date] [Recent Entries]
>Now I'd like to apply the same concepts to an XML parser, used primarily >when object-oriented program data is stored as XML syntax. 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. 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. Here's a nutty idea -- Try threads. Run the parser and expat as two separate threads and cross-synchronize them. Each expat handler would signal the parser thread to go (and then block until it hears back), and the ::Parse method in the parser thread would signal the expat handler to continue (and then block until the end handler signals it back). The two threads never actually overlap, but you get two processing stacks to handle the control flow issues. -Joshua Smith 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...)
|
