XSLT is fully adapted to XML/XML(fo or other target schema) since it was
the design basis…
My experience is:
− good xslt is (relatively) easy to design as soon as you master the
underlying data model
− xsltproc is REALLY REALLY fast for xslt 1 processing
− if you want something smarter, go for java with saxon/xerces, which is
performant too…
I'm the devil's advocate but what's your need to use ConTeXt. I have not
read all your threads but if you just need:
− to produce pdfs from xml data
− without advanced typesettings
you could use xslt to produce DocBook 5 xml file, include them using
On Sun, Nov 14, 2010 at 4:31 PM, Hans Hagen
wrote: On 13-11-2010 4:14, Peter Davis wrote:
On 11/13/10 6:03 AM, Renaud AUBIN wrote:
Uh ? Give FOP a try… http://xmlgraphics.apache.org/fop/1.0/index.html Could you describe your target chain ? XML → FO → PDF ?
Actually, I could write some XSLT to convert the XSL-FO into TeX or ConTeXt. But I was thinking it might be beneficial to use ConTeXt to process the XML (XSL-FO) directly ... get it all under one roof, so to speak.
faster too
Interesting point. I initially assumed it would be faster to do all my XML processing in ConTeXt, but it occurred to me that perhaps using XSLT to or even home-grown XML processing, I could generate a stream of TeX that could be processed while I'm still producing it. So one process might be looking at successive data records and generating TeX for the various pages, and another process could be simultaneously running TeX to typeset those pages.
Plausible?
Thank you.
-pd
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________