Re: [xsl] Advantages and disadvantages of XSLT

["Martin Honnen martin.honnen@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On 15/02/2025 13:28, Roger L Costello costello@xxxxxxxxx wrote:
> Hi Folks,
>
> I like XSLT. It is powerful at transforming small- to medium-sized XML
documents. A few lines of XSLT code can do what hundreds of lines of Java code
does. But XSLT does have disadvantages that one needs to be aware of (and I
often forget):
> 1. XSLT is best suited for input data that is XML-formatted. It can process
non-XML-formatted data, but XSLT is clunky at this; there are better languages
for that.


If you have the skills in one of those "better" languages, I agree. But
in XSLT 3.0 with XPath 3.1 you can process JSON well, in XSLT 4/XPath 4
there will be even improved support.

And I can get a lot done for processing unstructured text with
fn:analyze-string and/or xsl:analyze-string and fn:tokenize/fn:matches.

And for a few years now we have Invisible XML to allow you to parse
other formats with XSLT/XQuery.


> 2. XSLT is good when the XML is not too large. Recall that an XSLT processor
builds an in-memory representation of the entire XML document; a large XML
document results in blowing up memory and you get an out-of-memory error--and
no amount of additional heap space helps. There is Streaming XSLT to deal with
large XML documents. It's okay. Not great. With large XML documents, it is
probably better to use SAX with a general-purpose programming language.


That also depends on your skill set, for lots of tasks (like streamed
grouping) (within the limits it is possible) I doubt that it is
easier/better to use SAX than XSLT 3.0 with streaming, once you have
learned that properly.

> What other advantages and disadvantages does XSLT have?
For some people its XML format is an advantage, others see it as a
disadvantage and invent their non XML representation. But being to able
to use XSLT to process and generate XSLT is a big advantage.

XSLT is a W3C recommendation/standard, that is an advantage in my view,
that way, even if something I had to learn with XSLT 3, I can use my
XPath 3.1/XSLT 3.0 JSON processing with any implementation, I am not
sure that is the case with stuff like JsonPath.

On the other hand, with Saxonica and Altova there seem to be only two
companies that have made the effort to implement XSLT 2 and 3 (although
it seems Oracle and IBM have (or had?) some XSLT 2 processor
implementations as part of their server products like websphere).

And Saxonica is the only company that has an open-source XSLT 3
processor with Saxon Java HE and .NET and the closed-source but free to
use SaxonJS for XSLT 3 in the browser and on Node.js.

Mukul is also doing a lot of work to have an XSLT 3 version of Apache
Xalan as an open-source product but I feel it is not quite as robust as
Saxon HE.

And XSLT 1 as native support in browsers seems like a disadvantage, not
sure there is hope for that to change.