> 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/