Like I said, the proprietary preprocessor we use at my work
is tag-based, and is quite pleasant for working with XSLT,
HTML and other tag-based input and output. We've been using
it less and less for raw string-based HTML generation, and
more for a "glue" of sorts to coordinate the other
technologies that do the brunt of the hard work. It does a
wonderful job of, say, taking in a SOAP request, feeding the
XML payload into an XSL transformation that generates SQL
code to verify the business information in there, taking the
FOR XML AUTO result of that SQL query and transforming it
into its own code (which can generate e-mails, do file I/O
manipulation, etc.), which it can then run. It's procedural,
sure, but only where it needs to be procedural. (Michael
Ludwig's comment about SQL relevant here.)
My thinking is that the right tooling for this job is not pure XSLT, but
XSLT+XProc. XSLT is designed as an XML transformation language, and I think
it's a mistake to try and get it to cook your breakfast for you. XProc, by
contrast, is designed as a language for integrating different technologies
and making them work together: XForms, XQuery, XSLT, and if you need them,
components written in low-level Java or C# code. I think you do need a level
of the system that can sequence work in a defined order (because when you're
talking to users, the order in which you do things matters), and that means
a purely functional language isn't ideal for everything
James talked about building a Java framework for doing this integration
task, and for the high end applications that may continue to be necessary,
but I'm optimistic that for the other 95%, XProc will meet the requirement.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--