RE: [xml-dev] Inversion of control (was: DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM / etc. failed?))

[Tatu Saloranta <cowtowncoder@yahoo.com>]

--- Michael Kay <mike@saxonica.com> wrote:

>  
> > That's pretty hard-core. ;-)
> > (due to SAX imposed "involuntary
> > inversion-of-control")
> 
> Perhaps it's voluntary? Saxon makes heavy use of
> push pipelines internally,
> by choice.

Well, SAX direction was definitely voluntary from
parser implementors: it is obviously easier that way,
when your parser can drive parsing (as opposed to
request from driving app driving it). And it also
happens to be acceptable for 2 major use cases: Tree
model building, and pipelined transformations (XSLT);
there is nice symbiosis there.

But for other use cases -- for example,
recursive-descent traversal -- event mode is
ass-backwards. Even though it is harder to chain
things in pull mode (essentially requiring output from
apps that use pull parsing to use pushing output
model), it is also unnecessarily clumsy to use pull
parsing in basic forward traversal, the ubiquitous,
simple and efficient way of traversing data such as
infoset.

While I have written event dispatchers (just as pretty
anyone who has had to work on bare SAX API), it is
monkey work best avoided. Like climbing up the tree
ass first. Better delegate that monkey work to parser
implementors.

> I'm coming to the conclusion that anyone who puts
> the main processing loop
> in their own program is being unreasonably
> egocentric. XML applications
> should be written so they can be placed on a
> processing pipeline. I don't

Why? If I am doing data binding, it is the end of the
line. Same for parsing configuration settings or
import/exporting data of different type (object
graphs, relational data).
Pipelining only matters when you are in XIXO (Xml-In,
Xml-Out) mode.

It comes to a philosophical difference then, I guess:
for me not everything is XML; and as such I do care
about termination points (where XML gets converted to
something else). These points need not use the same
mechanism (like SAX) as what XML-to-XML interfaces
use.

> care too much whether it's a pull pipeline or a push
> pipeline, neither is
> intrinsically easier or harder to write than the
> other. Pull only makes life

Overall there may be balance; but for different actors
trade-offs are different. It is quite hard to do pull
pipelining: such a pipeline only works easily if your
events have one-to-one mapping (one input event
results in just one output); or if one uses buffering
or multiple threads (or co-routines?).

On the other hand, I find parsing side of pull
interfaces to be superior in every way. With languages
that do not have co-routines (like Java, C++, ...),
there can only be one driver. And if you are the
driver, things are easy: if not, they are not. I
assume languages with co-routines could solve this
quite elegantly, in which case push/pull-impedance
would vanish.

> easier if you're the lucky one at the top of the
> food chain. And if someone
> has selfishly occupied that position, the only way
> to extend the pipeline
> further is by push...

There is nothing selfish in happening to be the
terminus of a pipeline (or, in simplest case, there
being no need for an XML pipeline). I agree in that if
you need pipelining, push model is simple to extend.
No contest there.

While pipelines are important for transformations
within xml (infoset), their utility ends where XML
domains starts/ends.

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com