[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: pulling with expat - success!

  • From: Paul Miller <stele@f...>
  • To: xml-dev <xml-dev@i...>, sml-dev@e...
  • Date: Mon, 20 Dec 1999 08:39:50 -0500

expat startelement
"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@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...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.