Re: [xml-dev] performant templating language for XML

[Joe Dane <joe.dane@gmail.com>]

I spent some time looking for just such a beast, and ended up
disappointed.  Eventually, I rolled my own, a SAX based (don't hurt
me!) processor for mostly-XHTML templates.

in your case, you mention a "transformation" that has to happen, but
you don't say how the transformation is expressed, or if it can be
done statically.  if the transformations don't depend on any runtime
information, you might be able to run the transformation offline, or
if that's infeasible you can transform at runtime into a cache of some
sort.  in either case, XSLT performance (or lack thereof) won't be a
problem.

however, I've got to say that your requirements don't seem to be so
strict that you should be ruling out XSLT, even if you have to run the
transform online.   my experience is that the performance problems in
an XSLT approach are often due to the environment surrounding the
transformation, and not the transformation itself.  in any case, while
XSLT will always add some amount of overhead, the win in terms of 
productivity can be pretty large.

in my case, XSLT was sub-optimal, but not because of performance
problems.  a distinction often made on this list is that between
implementors and users.  but I'd guess many people deeply into XML are
both: they are users of one or more XML technologies (DOM, SAX,
XQuery, XSLT, etc.) but they are implementors of whatever system is
making use of those technologies.  and so they have their own base of
users, and like all implementors they want to make life easy for their
users.

in my case, my users were going to be a number of designers.  these
are intelligent people, and could have (and sometimes actually have)
learned enough XSLT to manage.  but what I wanted was a system in
which they could work in the most productive way they can, which means
letting them use the tools they are used to using. in short, I wanted
to let them come up with (X)HTML mockups, and I didn't want to break
those mockups up into separate <xsl:template> sections when it came
time to actually implement the system.

the typical approach is that the designers come up with a mockup and
give this to some sort of coder.  the coder inserts whatever
additional stuff is needed to replace the mocked up content with
dynamic content, and also the various control (if, loops, etc.)
constructs.  the result might be JSP, ASP, Velocity, etc., but
certainly not XML.  Or HTML, for that matter.  the designer cannot use
the coder's result in making design changes, so the whole process has
to start over again, and the pages end up a tangled mess of various
languages.

XSLT would make (and has made, when I've used it in this context) the
situation much much better.  but there are still at least two things
that are irritating.  the first I've already mentioned: the mockups
usually need to be sliced up into XSLT templates, and the resulting
stylesheet is not longer viewable as HTML.  perhaps the process of
moving from mockups to stylesheet could itself be automated, though.

the other irritation is that it's too difficult to bind XSLT
stylesheets to values in the "host language".  the host might have
access to a list of items, say, and I want to generate a <ul> in the
stylesheet.  this is doable, of course, but seems harder that it
should be, and at any rate is dependent on the XSLT processor used.

my reply has gone on a little longer than I expected, so I'll finish
this up by mentioning TAL, which is used by Zope/Python and which is
actually pretty close to what I ended up implementing.  TAL is just
HTML (or I suppose any sort of XML) with some additional attributes to
control logic  and dynamic value substitution.  I think that the
Cocoon people are experimenting with something similar as well.

-- 

joe