Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Inversion of control (was: DOM's javascript roots (was Re:
 --- Michael Kay <mike@s...> 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
