Re: [xsl] XML/XSLT for web templating

Subject: Re: [xsl] XML/XSLT for web templating
From: "Anthony B. Coates (XSL-List)" <abcoatesecure-xsllist@xxxxxxxxxxx>
Date: Mon, 08 Oct 2007 15:39:49 +0100
My personal opinion is that templating systems like Velocity easier to use
than XSLT when you have to produce text rather than XML/HTML, but
sometimes harder to use for generating XML/HTML.  It depends how closely
the structure of the input data represents the structure of the output
document.  That said, if you are in a place where everyone knows JSP and
not XSLT, there may be a genuine advantage with using a JSP-based
approach.  It's not always appropriate to retrain large numbers of staff
unless you can identify a real business advantage in doing so.

Where XSLT wins out over JSP is in the ease with which it handles XPaths.
If your transformations involve lots of XPath expressions (explicitly or
implicitly), then XSLT might mean less code to write.  If your
transformations only depend on individual element/attribute names, and not
XPaths, then JSP might not be such a bad choice for users who already know
it.

Cheers, Tony.

On Mon, 08 Oct 2007 15:11:30 +0100, Alessandro Bologna
<alessandro.bologna@xxxxxxxxx> wrote:

Dear collegues,

I was wondering if there is  anybody on this list who could share some
experience (opinions are very welcome too) on using XML/XSLT (2.0) as
the templating technology for very large news/information web sites, vs
using a more common Java/JSP,/Velocity or Freemarker solution.

As a background information, and to better contextualize this request,
we have already implemented a prototype, and it's beautifully working in
production).

In this implementation, contents are available as XML documents, in the
form of external feeds(Atom, RSS, PRISM etc) and RESTful web services
that access a JCR/JSR-170 repository.
Templates are basically XHTML documents, augmented with XML markups that
allow to navigate the content XML (using an XPATH style addressing of
the content XML elements) and to present specific elements as well. A
library of XSLT (2..0)  rules is used to process the templates, to
access the XML using the document function and finally to create the
resulting XHTML documents.

A minimalistic template may look like this:
<x:template name="article" target="browser">
<html xmlns="http://www.w3.org/1999/xhtml"; xmlns:x="http://foo.com/x";>
<head>
<title x:node="article/tout/headline"/>
</head>
<body>
<x:header/>
<h1 x:node="article/headline"/>
<div id="body">
<x:render x:node="article/body"/>
</div>
<x:footer/>
</body>
</html>
</x:template>

The transformation happens in pipelined stages, so that it's really easy
to render the XML in intermediate formats, and do the final
presentation(s) at the last stage. I forgot to mention that the output
can be targeted at different devices (such as pdas, cellphones, desktop
browsers etc) or media (RSS etc).

I have been strenuously advocating this approach, because I see in it a
a lot of potential:

1. templates are XML documents, therefore they can be processed (meta-
templates) still using XSLT
2. the XSLT implementation of the tag has easy access to the template
document and to the content document, so that it can, for instance,
provide a different presentation if inside a <h1> or inside a <title> or
a <div id="body">
3. it's really easy to author and validate these documents using
basically any tool (including dreamweaver, eclipse, XML tools etc).
4. new presentation rules can be created without altering the existing
code (using import precedence and/or more specific matchers)
5. The XSLT itself can be processed and validated still using XSLT
(meta-processing)
6. XLST 2.0 provides a much better set of tools for generic processing,
modularity, data control and makes it a feasible task for average
programmers to maintain this code

So, I have been advocating this choice, implemented the prototype, and
still, I face a huge resistance based on the "fame" of XSLT of being:

1. Too slow (i proved it wrong already, but still, just yesterday
somebody was telling about Freemarker being 15 times faster than XSLT at
rendering docbook, and I know that Robert Koberg has something to say
about that... :)
2. Too difficult because programmers only know imperative programming,
understand only imperative programming, and are willing to learn only
imperative programming
3. Too unknown ("everybody knows JSP...")
4. Too old ("XSLT is dead, or at least I heard so")
5. Nobody uses it for this purpose (really? pre-cooked HTML from XSLT is
so unheard of?)
6. Too hard to maintain ("it becomes very messy very soon")
7. Too hard to read ("XML is not meant for programming..., #if () is so
much more readable")

So the alternative is Velocity, Freemarker or JSP and an XML/Java
binding solution (such as JAXP), and this alternative is considered more
scalable, more robust and more flexible. In other words, the push is for
templates made of:
<%=article.headline %> (or <# or <@ depending on the poison that you
choose) .

I apologize for this long email, and I realize that this may not be the
appropriate forum for such an inquiry (please list-owner feel free to
censor it if it's the case), but at this point I really need (after
months of useless advocacy on my side) some opinions and experience and
real world examples, if anybody has one to contribute.

Best regards
Alessandro Bologna




-- Anthony B. Coates Senior Partner Miley Watts Experts In Data +44 (79) 0543 9026 Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312, UN/CEFACT TMG, MDDL, FpML, UBL.

Current Thread