Michael,
yes, the idea of allowing one to use a SAX interface instead of expat is
very sensible.
There are several implementations of SAX for C++, but I think the
standard is still evolving; Sablotron does not support the full SAX.
What it does support is a SAX-like, 'streaming' interface, more or less
compatible with expat. It should not be hard to modify Sablot to allow
using any expat-compatible parser. In fact, when constructing a result
tree in memory (which usually does not happen though), Sablotron behaves
as a parser and calls its own expat callbacks.
Michael Koehne wrote:
> my idea is based on the fact that XSL is often in the middle of the
> chain. e.g.
>
> database -> reportgenerator -> wrapper -> xsl -> xhtml2html
>
> so anything processed by XSL, is produced by a program, and anything
> that will be produced by XSL, needs postprocessing (<br/>, utf, ...)
> befor it can be displayed as HTML. Most important, there is no need
> that the original is XML, it may be UN/EDIFACT or hidden inside a database.
I don't think that the result of an XSLT transformation typically needs
any postprocessing before being displayed as HTML: if you use
<xsl:output method='html'>, things line <br/> will be treated as the
browser expects.
Best,
Tom
