What XSLT 2.0 and 3.0 can do better than XSLT 1.0

[MonkeybreadSoftware]

XSLT (Extensible Stylesheet Language Transformations) has been a core technology for XML data transformation since the early 2000s. While XSLT 1.0 laid the groundwork, subsequent versions — 2.0 and 3.0 — significantly expanded the language’s capabilities, power, and usability.

You can use XSLT 3.0 in Xojo with MBS Xojo Plugins and our Saxon classes. Please check the MBS Xojo XML Plugin. The built-in XSLT in Xojo itself is only doing XSLT 1.0.

Here’s a breakdown of what you can do in XSLT 2.0 and 3.0 that you simply *can’t* do in 1.0.

1. Data Types Beyond Strings

XSLT 1.0 is essentially string-based. Everything is treated as a string or node-set, which limits complex operations.

XSLT 2.0+ introduced a full suite of data types from XML Schema: numbers, booleans, dates, times, durations, QNames, and more. You can now perform real arithmetic, date calculations, and type validation directly in your transformations.

2. Grouping with `for-each-group`

In 1.0, grouping data (e.g., grouping items by category) requires convoluted workarounds using keys and Muenchian methods.

XSLT 2.0 introduces the `for-each-group` instruction, making grouping declarative, readable, and much more powerful — with options like `group-by`, `group-adjacent`, and `group-starting-with`.

3. Regular Expressions

XSLT 1.0 has no regex support at all.

XSLT 2.0+ adds functions like `matches()`, `replace()`, and `tokenize()` using XPath 2.0's regular expression capabilities, allowing sophisticated string manipulation tasks directly in the stylesheet.

4. Multiple Output Documents

XSLT 1.0 can only produce a single output result.

XSLT 2.0+ allows you to generate multiple output files from a single transformation using `xsl:result-document`. This is huge for batch processing or generating reports, indexes, or web pages in one go.

5. User-Defined Functions

In 1.0, there's no way to define reusable functions — just templates and recursion.

XSLT 2.0+ introduces `xsl:function`, enabling clean, modular programming practices. You can now write pure functions with parameters, helping structure complex transformations more cleanly.

6. Sequence Handling

XSLT 2.0 and 3.0 support sequences — ordered collections of items (nodes, strings, numbers, etc.) — and provide operators to filter, map, and manipulate them. This is a paradigm shift from 1.0’s node-set limitations and opens up a functional programming style.

7. Try/Catch Error Handling (3.0)

Only in XSLT 3.0, you get `xsl:try` and `xsl:catch`, allowing robust error handling within stylesheets. This is critical for building reliable, fail-safe transformations.

8. Streaming Support (3.0)

When dealing with massive XML files, XSLT 3.0 introduces streaming, enabling transformation of data as it’s read without loading the full document into memory. This is a game-changer for performance and scalability.

9. Higher-Order Functions (3.0)

XSLT 3.0 supports higher-order functions — meaning functions can be passed as arguments, returned from other functions, and stored in variables. This unlocks truly functional programming patterns, like `fold-left`, `filter`, and `map`.

10. Packages and Modularity (3.0)

With XSLT 3.0, you can organize your code into packages — making it easier to build large-scale applications with reusable components and better namespace isolation.

Conclusion

While XSLT 1.0 still powers many legacy systems, modern XSLT versions bring a major leap in functionality, performance, and developer ergonomics. XSLT 2.0 introduced rich typing, better grouping, user functions, and multiple outputs. XSLT 3.0 went even further, enabling streaming, modular code, and robust error handling.

If you’re still working with XSLT 1.0, it might be time to explore what the newer versions have to offer — especially if you’re facing performance bottlenecks, code complexity, or evolving data processing needs.

[comment]

This is the second time you are posting a comparison between XSLT 1.0 and XSLT 2.0 and 3.0 and just like the first time it is full of inaccurate and false statements.

 

5 hours ago, MonkeybreadSoftware said:

XSLT 1.0 is essentially string-based. Everything is treated as a string or node-set, which limits complex operations.

This is absolutely and unequivocally wrong. XSLT 1.0 recognizes the following data types, defined in the XPath 1.0 specification:

• node-set
• boolean
• number
• string

The XSLT 1.0 specification adds:

• result tree fragment

as another data type (although it's no more than a special case of node-set).

True, in XSLT 2.0 there are more data types - most notably date, time and dateTime. But that doesn't mean you cannot "perform real (as opposed to what?) arithmetic, date calculations, and type validation" in XSLT 1.0.

 

5 hours ago, MonkeybreadSoftware said:

In 1.0, grouping data (e.g., grouping items by category) requires convoluted workarounds using keys and Muenchian methods.

There is only one Muenchian method - and whether it's a "convoluted workaround" is a matter of opinion.

True, XSLT 2.0 introduced built-in grouping which is often more convenient. Often, but not always.

 

5 hours ago, MonkeybreadSoftware said:

XSLT 1.0 can only produce a single output result.

Technically, it's true. But if you are running FileMaker Pro 2024 or later, you already can produce multiple outputs in a single transformation because the libxslt processor supports both the EXSLT exsl:document extension element as well as the multiple output documents method added in the XSLT 1.1 specification.

 

5 hours ago, MonkeybreadSoftware said:

In 1.0, there's no way to define reusable functions — just templates and recursion.

This is true. But is is also true that a named template is not much different from a user-defined function. And again, the libxslt processor introduced in FMP 2024 does support defining custom functions using the EXSLT extensions.

 

5 hours ago, MonkeybreadSoftware said:

XSLT 2.0 and 3.0 support sequences — ordered collections of items (nodes, strings, numbers, etc.) — and provide operators to filter, map, and manipulate them. This is a paradigm shift from 1.0’s node-set limitations and opens up a functional programming style.

Not really. A "sequence" is just an expansion of the "node-set" concept to allow items other than a node and duplicate items. Hardly a "paradigm shift" and certainly XSLT 1.0 is also a functional programming language.

 

Here is my conclusion:

As I said in the previous round, there are very few things you cannot accomplish using XSLT 1.0 - esp. with the rich support of extensions that the built-in processor provides (see my post here). The most important point remains the question of performing the transformation as an integral part of importing and exporting records. Currently that's only possible with the built-in XSLT 1.0 processor (please correct me if I am wrong on this).

 

Edited Wednesday at 11:16 AM by comment

[MonkeybreadSoftware]

Well, first I am happy to see a reply to this. Looks like you know XSLT better than me. And I didn't notice your previous reply in February. Sorry for that, too.

[comment]

BTW, you (or was it ChatGPT?🙂)  missed what is probably the most significant difference to a Filemaker developer:

XSLT 3.0 can parse JSON input directly and transform it into any format, including Filemaker's own XML schema. This opens up another path to consuming JSON data: instead of a script laboriously parsing the input into individual records you can convert the input to XML and then have Filemaker import the result using the standard Import Records command.

This would have been very nifty to have integrated into FMP's native import process (as I already pointed out here). Unfortunately, that is not the case and the first part must be performed outside of Filemaker using a 3rd party XSLT 3.0 processor.

 

Edited Wednesday at 02:43 PM by comment

[MonkeybreadSoftware]

That sounds interesting. We integrate Saxon library into FileMaker via MBS FileMaker Plugin.

 

The JSON input sounds interesting. Let me check if I can make this an option for FileMaker.

You may use Saxon to do XLST 2/3, XPath queries and similar to preprocess data to then feed to the XML import in FileMaker. Or you use our XML.Import or XML.InsertRecords functions.