XSLT good choice for web framework?

Question

I've always thought of XML (and SGML before that) data as the devil's format. I'm of the old database and flat files school. Nonetheless, we are developing a commercially-available web product who's framework is based off of translating/transforming XML data in chains.

As we're interviewing for positions as well talking to potential customers, they love the concept of what it will do but are weary of supporting XSLT long-term. One person even called it the proverbial "dead." Dead like COBOL, Unix, and C or dead like Apple Business BASIC?

Anyway, I'm curious if building a web framework on XSLT is really not cutting edge enough (oddly) for companies. Are there inherent XSLT implementation problems that make this venture something worth reconsidering?

Answer 1

XSLT is a set of rules to transform a tree into another tree. To use it effectively, you should think about it that way.

Some benefits of the XSLT for me:

1. Every HTML coder I can rely on, can write XSLT transformations (I can easily outsource the HTML coding), but there is not a lot of them who can easily deal with ASP.Net controls, Mako templates, Django, JSP, Smarty templates and other engines at the same time.
2. When used correctly XSLT is self-sufficient. I can provide the HTML coder with an input XML, negotiate about the XSLT processor, and develop XSLT transformations separate from the application itself.
3. XSLT environment is sandboxed, HTML coder almost can not open a security hole himself.
4. XSLT is not bound to XML: you can write your own adapter to deliver data to XSLT and register your own output handler. That is not an option for solutions based on libxslt (php, python) though.

But that means, that you should not break the flexibility. I did see environments when complex instances with a lot of side-effects in behaviour were passed to a Saxon transformation and the input tree was used only to initiate the process. There was no way to develop separately from the complex application server, and you had to deploy your stylesheet for 5 minutes just to see if the output is correct.

UPD: Some best-practices of mine:

The main thing, as I said, is to keep XSLT transformation separate. Libxslt+exslt, msxsl+native extensions, etc. should suffice for the transformation. If XSLT is missing some power tools, I prefer to do it in the calling code and pass to the transfromation within the input tree.

The application should build an XML (or a tree) of a predictable (documented) structure. For each page I am interested in:

1. I generate an XML (or write it manually if it is not yet easy to obtain);
2. prepare the resulting HTML I am going to obtain as a separate static file;
3. define an XSLT transformation (from several pages this may be the same).

Then I put everything in a VCS and create a batch file to apply to each XML the corresponding XSL, so that result would overwrite the static HTML files.

Now running svn diff html-folder (or similar) will show me if any transformation broke the HTML, and where exactly. I make changes in XSL, and run the batch again. Once the HTML is the same, I commit.

Each change in XML document structure should lead to updating the corresponding XMLs and XSLTs, so that HTML would stay the same. Each requested change in HTML should lead to the corresponding change in XSLTs. HTML coder can work in isolation and I can see if anything went wrong.

The pages in the application, where I use the XSLT usually accept a GET parameter like showinput=1 to return the bare input tree without an applied transformation, so that I could save it and add to VCS as another special case.

Concering caching, when I need it I usually cache the ready HTML page. Frequently changing parts of pages are loaded with client scripting.