pulling with expat - success!

Paul Miller stele at fxtech.com
Mon Dec 20 13:38:48 GMT 1999

"Clark C. Evans" wrote:
> Does this code fragment help out?  It is far from
> perfect, however, the "pull" based code would call
> getNextEvent() to return the next XML event...

Thanks Clark! That was what I needed. I had my mind set on recursion and
failed to think about an event queue. I was able to slide this under my
API and seems to work well. Although memory usage will be higher than my
solution, the design is taking advantage of expat for the lower-level

The basic design goes like this:

1. XML::Parser::Parse() starts pulling events in a loop

2. expat calls startElement
	I create an Element (with the attributes) and push it on a stack
	I create a StartElement Event and push it on the event queue

3. expat calls endElement
	I create an EndElement Event and push it on the event queue. At this
point I take the top Element off the element stack (which should match
this EndElement), and store a pointer to it inside the Event. The
element stack is there only to synchronize the events with the elements.

4. expat calls characterData:
	I buffer the data into a string inside the top-most element


5. When there are some events in the queue, an event is pulled off and
	If there is a handler at the current scope, it is called
	Otherwise, a skip-to flag is set and all events that don't get us back
to the previous level are thrown away

6. When a handler is called, it pulls events from the queue and
processes them until the ending-element event that matches this element
is found

7. When a handler's Element::Parse() returns, the element is pushed onto
a delete queue (because we can still use the Element pointer in the
remainder of the handler)

8. When a handler returns, the delete queue is emptied

I've only tested with some small files, but I think the design is sound.
There is a lot more memory overhead (creating events and elements as
they are encountered) than my previous implementation, but I'm hoping to
use some memory pools for the Elements, Events, and Attributes, so the
overall run-time overhead should be minimal when it's finished.

Thanks for all the suggestions!

Paul Miller - stele at fxtech.com

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)

More information about the Xml-dev mailing list