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

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

Answer 2

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.

Answer 3

Nothing really wrong with it...

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

Answer 4

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.

Answer 5

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?

Answer 6

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 last call working draft for XSLT-3.0 was published in Dec 2013, 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.