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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Push and Pull?

[ Lists Home | Date Index | Thread Index ]

SAXDOMIX [1] could be classified as semi-random-access,
push-flow-control-interface. It enables you to parse a document in the SAX
model, and switch when desired to the DOM model to build partial trees that
are pushed into a controller. It is semi-random access because you have full
random access on the partial trees, but sequential access between them.

dom4j also implements this idea, in a less generic way (but much more simple
and easy to use), and calls it 'tree pruning' [2].

This approach is quite interesting for XML document with a fixed-depth
repetitive structure, such as a list of elements with a complex structure.
It simplifies your code by making it possible to use tree accessors (imagine
how it would be great with dom4j XPath accessors !), instead of having to
deal with a stack and/or a state-machine, without forcing the whole document
to be loaded in memory.


[1] http://www.devsphere.com/xml/saxdomix/

N.B. the anchor contains a '?', so the link is not valid in Outlook Express.

----- Original Message -----
From: "Clark C . Evans" <cce@clarkevans.com>
To: "Sterin, Ilya" <Isterin@ciber.com>
Cc: <xml-dev@lists.xml.org>
Sent: Friday, January 25, 2002 8:01 PM
Subject: Re: [xml-dev] Push and Pull?

> On Fri, Jan 25, 2002 at 11:29:51AM -0700, Sterin, Ilya wrote:
> | >In SAX, the parser is has the
> | >control loop and thus this makes SAX parsers easy to write.  In
> | >DOM the control loop is owned by the library's user.
> |
> | That said, it again brings us down to that SAX parsers all (most)
> | follow the push model, and DOM based follow the pull model.
> DOM [1] uses a random-access,     pull-flow-control interface.
> SAX [2] uses a sequential-access, push-flow-control interface.
> XPP [3] uses a sequential-access, pull-flow-control interface.
> | > I've only just begun playing with random access push
> | > models... this is more or less events that can be replayed
> |
> | For the push model to be replayed, probably means that it
> | will have to keep a parts in memory, or reparse all over again?
> Yes.  To offer random access an interface will probably elect
> to keep an in-memory representation.  Although a random access
> interface could be done over a database (see Tamino), etc.
> | This means that we are back to in memory parsers right, or is
> | there some other concept behind it?
> Right.  The examples above give you 3 permutations, one
> could develop an interface which used random-access but
> push-flow-control.  I started to put together an interface
> for this about a year back... it had a way for events
> to be "re-played".   I stopped after I didn't see an
> obvious application of the technique.
> ;) Clark
> [1] http://www.w3.org/DOM/
> [2] http://www.saxproject.org/
> [1] http://www.extreme.indiana.edu/soap/xpp/
> --
> Clark C. Evans                   Axista, Inc.
> http://www.axista.com            800.926.5525
> XCOLLA Collaborative Project Management Software
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>


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

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