Peter B. West wrote:
taking a very isolated path. My motivation can be summed up in the slogan SAX SUX. I couldn't understand why anyone would persist with it for any complex tasks, e.g. FOP.Actually I cannot say I fully agree with this, because I don't see nothing complex in SAX processing model. And being xslt fan I'm obviously push-model fan.
...
significant difference makes XmlReader much easier to use for most Microsoft developers that are used to working with firehose (forward-only/read-only) cursors in ADO.Well, lets consider pull model pros and contras:
+ easy to use by developer
+ benefits by kind of structural validation
+ more?
- it glues processing to a particular xml structure, what is not so bad for vocabularies with well-defined and stable content model. The question is whether xsl-fo is a such kind of a vocabulary? I think it doesn't. As a matter of fact xsl-fo even inexpressible in dtd or schema, besides of possibility of extensions.
- is there performance penalty? I used to think that easy to use stuff always costs something.
- more?
Note also that the structure of the code does its own validation. It generates the simple-page-master subtree according to the content modelThat's good, but it's not full-fledged validation unfortunately. To many "own validation" is bad I believe. If we need validation it must be done by specialized validation module and validation should not be scattered throughout the whole code.
(region-body,region-before?,region-after?,region-start?,region-end?)
And final question - what's wrong with SAX besides of possible complexity?
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
