Why support template-like output in Amara?

When I posted "Sane template-like output for Amara", Sylvain Hellegouarch asked:

I feel like you are on about to re-write XSLT using Python only and I wonder why.

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 preferences.

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 browser.

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.

[Uche Ogbuji]

via Copia

6 responses

Hi Uche,

First of all, thanks for clarifying things.

I do see your point in the above example of model logic. This makes a really good point when dealing with heterogeneous (non XML specific) data. It shows me you are not trying to replace XSLT with Amara but simply to help where XSLT would not suit.

Regarding the point of bringing developers who dislike XML into the X-technology world, I think it's useful but I hope you won't try too hard. Whatever tools you could bring to them and how hard you may try, if they have a bad feeling about XML & co., you won't be able to change their mind.

I "categorise" people who don't like XML into three sections :

* Those who never tried and simply judge-before-you-taste.

* Those who tried XML but didn't use it for the right purpose. Some people only see XML as a language used by some dark J2SE application servers for their configuration file. They don't realise that XML is also a meta language that has brought some other fantastic tools to store, describe, transform, validate, query data.

* Those who simply react to the hype XML had had in the last 5 years. A bit like when you here during months that a movie you haven't seen at the cinema is fantastic and that you should really watch it. You get so tired of hearing it that you don't want to watch it.

That being said, Amara might be the right tool to convert some of those people.

In any case, I've already started to use Amara for my own applications and I will try its templating feature as well.

One last question though, you finish your article with :

"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."

Does XSLT2 answer that issue?

- Sylvain

— Sylvain Hellegouarch

Hi Uche,

This is an excellent post that brings out some important points. I do wonder however if the solution can be solved utilizing a base of underlying functions that can then be implemented via 2 mechanisms:

- The XSLT (potentially 2.0 given 1.0 support already exists) engine which will properly invoke the necessary sequence of functions to process and transform the input XML.

- Amara, which will invoke a similar combination of functions, however in a way more in line with the Python architecture and programmers mentality.

Being a novice Python programmer, at best!, makes it difficult to suggest this solution with a whole lot of confidence... as such, I won't and simply leave it as something that, if possible, might be worth consideration as it will give leave the door open for the reverse situation, e.g. someone like myself who sees the value Amara and Python offer but given my background would prefer to work with XML via XSLT (2.0 preferably of course :D) except in cases where its obvious the platform offers a much simpler and elegant solution. In cases like this (which is sounds as if this particular situation qualifies) I am definitely more interested in the fastest way in and out of a process than I am in firing up the transformation object to perform something that is rediculously easy using the platform API.

Cheers :)

<M:D/>

— M. David Peterson

Isn't one of the key bugs/features of XML the fact that it assues data are hierarchical in shape?

For a healthy chunk of cases this is true, else XML would die a quick death, but this basic shape issue seems central to the question of why XML isn't universally loved.

— Chris Smith

Chris,

XML doesn't really assume that data is hierarchical. XML itself is hierarchical, but you're free to represent other shapes of data as well (e.g. flat like Apple plists or graph like RDF and even hyperlinked XHTML).

Whether or not XML is suitable, I think, is not often a mere matter of the shape of the data.

— Uche

One potential reason that python programmers do not like XML is that XML is a very bad choice for great many situations in which it is currently used.

People who advocate XML often do so to bypass limitations and problems inherent to their programming language. Since Python has a lot fewer of these the Python solutions turn out to be orders of magnitute simpler than any XML based one.

I have programmed in XSLT transformers for two years (that time is over thank goodness). In my opinion it is an awful solution for anything bigger than a trivial html page. It has nearly no support for meanigful, maintaiable modularity,what it has is a simplistic pattern matching and template calling approaches that resemble programming languages from the 60s... obvioulsy these all leads to an error prone tedious development.

As far as templating goes Zope Page Templates are much better than XSLT, but Cheetah beats them all. At the end of the day it is the length and clarity of the code is what matters.

— Toothybyte

Toothbyte,

I think your argument is incomplete. You can help with that. You say:

"People who advocate XML often do so to bypass limitations and problems inherent to their programming language."

Can you cite examples of good developers who do this? There are plenty of good developers who advocate XML, so you should have plenty of fodder. I should say, I've never once in my many years working in XML heard of such a reason in advocacy.

XML is largely independent of the language you use to process it. It should be: data is often independent of code. So I can't get a meaningful hold on your argument.

I have 10 years' experience with Python and 6 years' experience with XSLT. What that leaves me with is an appreciation of the fact that they do different things and have different strengths.