Advanced XSLT

XSLT 1.0 for developers who know XSLT 2.0-3.1

Limitations are strengths as long as they are not limiting.

This page will help to define boundaries around what kinds of processing are 'reasonable' to implement in unaided (unextended) XSLT 1.0.

In part this is so that you will know when you should switch to SaxonJS or another XSLT 3.0 processor.

Summary guidance for advanced XSLT coders

While quite limited in its capabilities, XSLT 1.0 has a "sweet spot" of applications that work well within those limitations. For such applications, the opportunity to deploy and use a more lightweight, less capable means in preference to a more capable means, has positive security implications (cf also Controls). Whether your application can be developed under XSLT 1.0 at all is essentially a question of how well it fits into this sweet spot, which is very difficult without in-depth knowledge of all versions of the language, and their differences.

In order to make this analysis easier this page intends to clarify the issue by summarizing the feature sets of the languages, in the context of wider questions regarding what kinds of applications, uses and operations are especially easy, or especially difficult, with this technology.

There are two other ways of determining whether a particular application is suited for XSLT 1.0

• ask someone with the relevant experience whose opinion you respect
• try it and see if you hit a wall - usually you know quickly

All three approaches can be used in combination.

Keep in mind that the syntax of versions of the language is close enough that migration is generally straightforward when it is possible at all. Migrating an XSLT 1.0 stylesheet to an XSLT 3.0 environment is easy. So is the reverse - except when it is impossible (when XSLT 1.0 simply has no practical equivalent for an XSLT 3.0 feature).

What XSLT 1.0 has

• Tree model for XML (source and result) with built-in recursive tree traversal logic
• "Every node visited for free" - by default, everything comes through
• Pattern-based node matching for templating results
• Query ('random') access to data via XPath
• Externalized parsing and serialization - develop to model, not syntax
• Follows functional programming paradigm (process encapsulation/isolation)

What XSLT 1.0 does not have

Quick list of the most important features added to XSLT after 1.0, that are not available in XSLT 1.0 --

• Temporary trees - hence XSLT 1.0 does not support internal pipelining
• Native grouping as supported by xsl:for-each-group (grouping by value, adjacency etc.)
• Support for regular expressions via functions and xsl:analyze-string
• Advanced XPath, with many other useful functions and operators
• Dynamic context: variable references in match patterns; tunnel parameters; xsl:next-match
• (more to be listed?)

In particular, this means that unlike its successors, XSLT 1.0 is not well suited for inferential, heuristic processing, i.e. upconversion as it is called, where information must be added or interpolated. It is still very good for filtering and mapping operations -- down-conversion or "going downhill" .

Why wasn't this done 20 years ago?

Simple answer: it was. In various ways and at various times, repeatedly.

If this wasn't much noticed, it may be due to other more pressing problems requiring attention.

At the same time, over 20 years

1. The maturation of Javacript, CORS (cross-origin resource sharing) policies and support for asynchronous calls has finally made the web safe for XSLT. Typescript as a development language improves this climate further.
2. At the same time, browsers have matured: HTML is (a little) better; CSS is (significantly) better; support for local operations and safe interactivity is better.

Combining these two developments, an application that permits a user to process a file locally -- one of the best use cases for XSLT in general -- is finally possible. In 2002 this capability was only sketched onto boards as a feature to have some day.