Oleg Tkachenko wrote:
I may have referred to Dijkstra (R.I.P.) here before. I think it was he who illustrated the importance of appropriate representations by reference to Roman numerals. In the Middle Ages, before the coming of Arabic numerals and zero, long division was considered do-able, though very difficult, and was taught to the foolhardy at universities. As I recall the story, the topic was computer languages, and the moral was: if you use a tool appropriate to the problem you are trying to solve, life will be much easier.Peter B. West wrote:I don't believe is is only a matter of style. I think the detrimental effects of push for general programming are glaringly obvious.
It's just event-driven processing, how it could be detrimental?
As for the selection of a language, so for the selection of a processing model. Event-driven processing is appropriate to event-driven systems. A traffic control system is an event-driven system, as is an operating system; processing an xsl:fo document is not. The variability of xsl:fo processing is constrained within carefully defined hierarchical limits.
This shows in the simple-page-master debate. Why has this generally been implemented in violation of the spec, while I picked that violation up the first time I ran against a variant file? The children are determined by the parent, not the other way around. So within an instance of simple-page-master, I expect the first child to be a region-body. Following that, I expect a region-before, but I am not upset if it's not there. Etc. These relationships are quite naturally expressed in a manner the echoes the hierarchical ordering of the document.
How is this done with SAX? Nodes are created without context - they just happen. The node must grope around to find its parent, and the virtual tree is constructed from the children up. The parent basically only gets control when its own ENDELEMENT event occurs.
I haven't read the documentation, but it may be that they are referring to the infeasibility of moving code built around SAX to an XmlReader environment.It's in "Comparing XmlReader to SAX Reader" page[1]: "The push model can be built on top of the pull model. The reverse is not true." Too categorical statement, I think.
Having read the reference, I agree.
True enough for the HEAD line. But FOP_0-20-0_Alt-Design will continue on the same track. I have been working on it alone for nearly two years now, and for a year before it was even allowed into the code base. Part of what I was doing was pure experiment, which I was prepared to abandon, but much is there because I believe in it, including the pull code.This is not an optimisation, but a fundamental design decision. It's all or nothing. See the comments about the feasibility of moving from one model to the other.
If so, we need more opinions from others.
I don't have to persuade a boss, in advance, that my approach is right. I just have to persuade myself. Then I can let the code do the talking. It's called Open Source development.
[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcomparingxmlreadertosaxreader.aspGiven the interest in pull APIs for XML, another advantage of my code is that, when a low-level pull processor becomes available, it can be incorporated into my design with a minimum of fuss for greater efficiency.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
