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 model

That'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.

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]

Reply via email to