OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: pulling with expat - success!

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Miller <stele@fxtech.com>
  • To: xml-dev <xml-dev@ic.ac.uk>, sml-dev@egroups.com
  • Date: Mon, 20 Dec 1999 08:39:50 -0500

"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
details.

The basic design goes like this:

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

<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

</loop>

5. When there are some events in the queue, an event is pulled off and
handled
	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@fxtech.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS