Re: (dsssl) OT: parsed vs event model

["Joerg F.Wittenberger" <Joerg.Wittenberger@xxxxxxxxx>]

>>>>> "KS" == Kendall Shaw <kshaw@xxxxxxxx> writes:

KS> Hi, I hope this is not seen as an abuse of the list.

KS> I'm trying to describe the value of groves/DOM etc. vs. event
KS> model parsing and I find my self unable to come up with much other
KS> than contrived examples. Can you give examples of common
KS> situations where it is useful to have access to:

IMHO this is not so much a matter of having access to whatever, but
what implication it has for the programming style.  The problem I
observed with the API definitions for event based interfaces is
exactly that they implicitly define a process.  Even from your
question it's visible: "... vs. event based *parsing* ..."  there is a
processor implied, which parses a serialized presentation of the
document tree or traverses the tree by some other means.  In other
words, there is a process.  This has some implications, when you want
to enforce code quality (functional programming - yes, after so many
thousend years of human experience in math, there is no procedural
math anymore): you need some way to "fetch" the next event when
needed.  Unfortunatley the vent based APIs are to my knowledge defined
in a way, that you can not do that (easily).

Actually I would love to see an code example how to get just the next
event out of a SAX parser by calling a function.  I tried this once to
no success.

I'm myself very much interested in all comparisons as you are about to
do, because I can't decide, which modell is better over all.  Both
modells allow for lazy evaluation, whereby the event based model seems
to be a slightly better fit (let alone the API flaw mentioned above).
Automatical reordering of calculations, though rarely done in software
available in source code, is also possible in both the modells, which
solves the "access to: ... before ... has been processed" questions.
While this is also a matter of delayed evaluation, the tree modell
seems to be the more "natural" way to describe this situation.

KS> 1. Children before their content has been processed.

I want to implement an <xslt:template match="para[./key]" >

So I need to know that this para has a child "key" somewhere (possible
the last child), when I encounter the start of the para element.

KS> 2. Right siblings, right siblings of an ancestor etc.

I want to number all the pages of a document in the "<n> out of
<total>" way.

/Jerry

-- 
The worst of harm may often result from the best of intentions.

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist