[
Lists Home |
Date Index |
Thread Index
]
In the interest of completeness... I also like to break
down XML interfacs in-terms of how they represent hierarchy.
There are two fundamental options:
hierarchical iterator (event handler)
nested iterators (event handlers)
A hierarchical iterator is one that iterates over the
entire XML tree and has some notion of "depth". In a
similar way, a hierarchical event handler is one that
recieves events at all levels of the tree and has a
"begin/end" style.
Nested iterators occur when the iterator only visits a
given node's children, and subordinate iterators are
created to visit further decendents. In a similar way,
one can imagine an event handler that doesn't use begin/end,
but instead has a call-back to the parser asking for
children, and passing a subordinate event handler.
SAX uses a hierarchical event handler,
DOM uses a nested iterators,
XPP uses a hierarchical iterator.
There is nothing preventing one from making a
parser which is sequential-access, pull-flow-control,
and uses a nested-iterators. Or, a sequential-access,
push-flow-control parser using nested-event-handlers.
...
Thus, there are three ways to categorize an XML
interface...
a) Access control (random vs sequential)
b) Flow control (pull vs push)
c) Tree management (hierarchical vs nested)
Best,
Clark
On Fri, Jan 25, 2002 at 02:01:20PM -0500, Clark C . Evans wrote:
| 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>
|
--
Clark C. Evans Axista, Inc.
http://www.axista.com 800.926.5525
XCOLLA Collaborative Project Management Software
|
