XSLT good choice for web framework?

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?

The popularity of existing XSLT-based Web Content Management Systems such as Umbraco and Symphony (SharePoint's already had a mention here) provides good evidence on the suitability of XSLT for a web framework.

If anything, XSLT is on the up. Its good to see established XML solutions companies still adopting it in numbers, for example, MarkLogic added XSLT capabilities to their XML database product some time ago.

The W3C XSLT-3.0 Recommendation was published in June 2017, showing continued interest and investment in XSLT's future.

There are also some useful new open standard extensions for XSLT (and XQuery) such as the EXPath project whose function libraries include extensive HTTP and Zip features.

[Update] With the launch of Saxon-CE (now open source), XSLT 2.0 processing can now be done both server-side and client-side. It also potentially gives 2.0 capabilities to frameworks previously limited to XSLT 1.0.

Language extensions in Saxon-CE mean XSLT templates can now be bound to user-events using simple XPaths and 'event modes', there's also much better JavaScript interoperability when needed.

Interesting that SharePoint 2010 has fully empraced XSLT. XSLT has legs...fear not.

I've used an in house framework that relied on XSLT to produce all it's HTML (and terrifyingly RTF and other formats too) and that's left me with some fairly strong opinions on the subject.

XSLT is a great language for transforming one XML format into another where both are well defined.

If your source data is XML then it's handy for transforming it into XHTML fragments but when you start to stray into templating engine territory things start to get a bit messy.

As with everything it's just a tool and if you use it for what it's good at it'll work well, if you use it at every opportunity you're probably abusing it and if you use it to generate RTF files you're committing a crime against nature.

If your application relies on transforming XML data then by all means, that's what's XSLT is dedicated for and it does a decent job except that the code can be quite verbose.

I've never really heard complains about problems with SAXON as an XSLT implementation.

Maybe looking into SXML, SXSLT, SXPath et cetera is worth considering though.

As far as XSLT being dead, as I notice it's still climbing and not really past its peak, though I do notice more voices that are starting to see the design flaws in XML, XML used as a data storage format to me is an unusual decision, XML is a good data-presentation format, and especially on the web, it's faaar to verbose to as a container to transmit information too but it does it job to present information.

XML does have what some people would call design flaws though.

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.

Nothing really wrong with it...

But depending what you are doing it may not provide you with enough hooks to do what you want.

If your concern is that your customers are resistant/unwilling to maintain XSLT (even though XSLT is a standard and is a widely adopted technology for the transformation of XML), need you tie your product specifically to XSLT for XML transformation tasks? If it is possible (and painless) to abstract out the appropriate XML translation/transformation parts in your framework (i.e., XML in → XML out), perhaps you could allow for different implementations to perform the same tasks; not just XSLT, but XQuery, Java (SAX+DOM), whatever...

Such a design might even be beneficial if you ever decide to ditch the 'devil's format' and adopt something else ;-)

EDIT: An aside, but are you aware of XProc?