Heads-up on XSLT in FileMaker 2024

[comment]

Buried deep in the release notes for FileMaker Pro 2024 (a.k.a. version 21.0.1) is a dramatic announcement: the Xalan XSLT processor has been replaced with libsxlt. Although both processors conform to the XSLT 1.0 specification (more on this later), they do differ in several aspects. This could have an impact on your existing stylesheets:

Extension functions
If you have been relying on extension functions in the Xalan namespace, you will need to replace those with their EXSLT equivalents in their corresponding namespace:

• xalan:nodeset ==> exsl:node-set (xmlns:exsl="http://exslt.org/common")
• xalan:distinct ==> set:distinct (xmlns:set="http://exslt.org/sets")
• xalan:intersection ==> set:intersection (xmlns:set="http://exslt.org/sets")
• xalan:difference ==> set:difference (xmlns:set="http://exslt.org/sets")
• xalan:hasSameNodes ==> set:has-same-node (xmlns:set="http://exslt.org/sets")
• xalan:evaluate ==> dyn:evaluate (xmlns:dyn="http://exslt.org/dynamic")

Other extensions
Xalan also provides the xalan:indent-amount extension attribute that allows you to specify the number of spaces used for indenting the result. There is no such feature in libxslt; you will always get an indent of 2 spaces (provided the indent attribute in xsl:output is set to "yes"). The difference is probably insignificant - unless you have relied on it to produce an exactly formatted document that your target application requires. In such case you will need to post-process the output.

There are also a few nuances in the behavior of some EXSLT extension functions that both processors support that I am not going to list here.
 

The good news is that the libsxlt processor suports far many more extension functions (for example, the str:tokenize function allows us to easily process return-separated lists into individual elements). It also does not suffer from the bugs in Claris' implementation of the Xalan processor that for years have prevented us from using it to format numbers or get a correct timestamp. Still, it remains to be seen what other bugs the new implementation has: there already has been a report of CDATA sections being discarded during import.
 

Finally, it must be said that this is a colossal missed opportunity. True, the libxslt processor is a much better choice than the ancient and obscure Xalan-C. However, it is also limited to XSLT 1.0 - a standard that is now a quarter of a century old. The current version of XSLT is 3.0, soon to be replaced by version 4.0. 

Here are just a few nifty features we could have been enjoying had Claris opted for a modern XSLT processor (e.g. Saxon):

• Import JSON directly, instead of the awkward method of parsing it by script we have to use now.
• Import text files (such as fixed-length or custom-formatted files) directly.
• Use regex to parse imported data directly into target fields.
• Re-format imported dates and timestamps so they can be imported directly*.
• Change character case during import or export*.
• Export to JSON*.

 

---
(*) To be fair, this is possible in XSLT 1.0 too, albeit with much more work.

 

Edited June 13 by comment