Re: [xsl] Advantages and disadvantages of XSLT

["G. Ken Holman g.ken.holman@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

For me, without question, the import tree and import precedence is a 
tremendous advantage of XSLT.

I have had numerous clients who, themselves, have numerous clients. 
Writing core XSL-FO stylesheets and then tweaking the core with 
onion-skin layers overriding the core (or each other) to create 
different customized layouts is very powerful.

The two largest projects where I leveraged this are for the US 
intelligence community back in 2005:

http://www.pdfpower.com/XML2005Proceedings/ship/18/Holman-18.HTML

... and my active work these days for https://RealtaOnline.com 
servicing multiple national and regional standards bodies in the 
publishing of NISO-STS and JATS from a single core with onion-skins 
for multiple layers:

https://www.realtaonline.com/customers/

https://www.ncbi.nlm.nih.gov/books/NBK591971/

... where such is important because of the layered nature of multiple 
expected results of a single stylesheet execution with layered input data:

https://www.ncbi.nlm.nih.gov/books/NBK610635/

The inherent structure of XML is a nested hierarchy. The import 
facility in XSLT implements a nested hierarchy of stylesheet 
behaviours. These two example projects supported dozens of distinct 
visual results from a core of stylesheets and multiple onion-skins.

I couldn't do what I do without import precedence, and I haven't 
worked with any other language that has such a concept.

In 2002, long before the intelligence project, I created the XSLStyle 
documentation methodology that exposes the (sometimes very large) 
XSLT import tree to help in maintenance of a set of stylesheets for a 
software vendor with multiple clients:

https://cranesoftwrights.github.io/resources/#xslstyle
https://cranesoftwrights.github.io/resources/xslstyle/index.htm
http://fgeorges.blogspot.com/2009/02/xslstyle-and-oxygen.html

A disadvantage of this facility? Not many XSLT developers leverage or 
even know of xsl:import and so have not exercised the mindset needed 
when creating and maintaining very (very!) large stylesheet 
libraries. It takes the declarative nature of XSLT to the next level 
in nurturing a declarative nature of XSLT stylesheet fragments 
interacting with each other.

I hope this is enlightening. I wish more developers knew about this 
(and that more developers were able to support very large stylesheet 
libraries that exploit this facility).

. . . . . . . Ken

At 15/02/2025 12:28 +0000, 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.
>
> 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.
>
> 3. XSLT has a "limited set of data structures available in the XDM 
> data model." This means that it's difficult--well-nigh, 
> impossible--to implement an XSLT processor--or any processor--in 
> XSLT. On November 3, 2024, Michael Kay wrote: "I have written a 
> number of papers over the years on the potential for writing an XSLT 
> processor in XSLT: see for example
>
> https://www.saxonica.com/papers/xmlprague-2019mhk.pdf
>
> The main difficulty in doing it is the limited set of data 
> structures available in the XDM data model. XSLT has always been 
> designed as a special-purpose programming language rather than a 
> general-purpose language, and writing compilers is not one of those 
> special purposes."
>
> What other advantages and disadvantages does XSLT have?
>
> /Roger