When I posted "Sane template-like output for
I feel like you are on about to re-write XSLT using Python only and I
I mean for instance, one of the main reason I'm using XSLT in the
first place is that whatever programming language I am using, I don't
need to learn a new templating language over and over again. I can
simply extend my knowledge of only one : XSLT, and then become better in
that specific one.
It also really helps me making a difference between the presentation
and the logic upon data since my the logic resides within the
programming language itself, not the templating language.
Therefore, although your code looks great, I don't feel confident
using it since it would go against what I just said above.
This is a question well worth further discussion.
The first thing is that I have always liked XSLT 1.0, and I still do.
Nothing I'm doing in Amara is intended to replace XSLT 1.0 for me.
However, there are several things to consider. Firstly, Python
programmers seem to have a deep (and generally inexplicable) antipathy
towards XML technology. I often hear Pythoneers saying things like "I
hate XML because it's over-hyped and used all the time, even when it's
not the best choice". Well, this applies to every popular software
technology from SQL to Python itself. Nothing new in the case of XML.
But never mind all that: Pythoneers don't like XML, and it very often
drives them to abuse XML (perhaps if something you dislike is
ubiquitous, using it poorly seems a small measure of revenge?) Anyway,
someone who doesn't like XML is never going to even look slant-wise at
XSLT. One reason for making it easy to do in Amara the sorts of things
Sylvain and I may prefer to do in XSLT is to accommodate other
The second thing to consider is that even if you do like XSLT (1.0 or
2.0), there are places where it's best, and places where it's not. I
think the cleanest flow for Web output pipelines can be described by the
following diagram. I call this the rendering pipeline pattern (no not "pattern" as in big-hype-ooh-this-is-crazy-deep, but rather "pattern" as in I-do-this-sorta-thing-often-and-here's-what-it-looks-like).
Aside: I've been trying out OpenOffice.org 2.0 beta, and I'm not sure
what's up with the wrong-spelling squiggly on the p word. I also wish I
didn't have to use screen capture as a poor man's export to PNG.
Separation of model from view should be in addition to separation of
content form presentation, and this flow covers both. For my purposes
the source data can be a DBMS, flat files, or whatever. The output
content is usually an XML format specially designed to describe the
information to be presented (the view) in the idiom of the problem
domain. The rendered output is usually HTML, RSS, PDF, etc.
In this case, I would use some such as the proposed output API for Amara
in the first arrow. Python code would handle the model logic processing
and Amara would provide for convenient generation of the output XML. If
some of the source data is in XML, then Amara would help further by
making that XML a cinch to parse and process. I would use XSLT for the
second arrow, whether on the server or, when it is feasible, through the
The summary is that XSLT is not suitable for all uses that result in XML
output. In particular it is not generally suitable for model logic
processing. Therefore, it is useful for the tools you do use for
model logic processing to have good XML APIs, and one can borrow the
best bits of XSLT for this purpose without seeking to completely replace
XSLT. That's all I'm looking to do.