Re: [xsl] Advantages and disadvantages of XSLT

["Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hello,

Random Saturday-morning observations:

XSLT (and XDM-based processing in general) effectively isolates the
parsing-strings problem from the transformation problem. The difference is
not and cannot be absolute, but it is important.

If you do not have a new parsing problem, there is no reason to be parsing
at all. Use XML and XSLT. (Or, today, use JSON and XSLT if you like.) As
mentioned, innovations like iXML continue to open new doors even when it
comes to parsing.

Constraints such as "how big can your documents be" are not about XSLT,
they change over time, and they are often mitigable. The problem is usually
not in the tools.

In my toolbox I think of XSLT not as a hammer or a chisel, but more like a
lathe. Or a Blanchard copying lathe, if you like, which works on
information.

You can build a house without a lathe, and you probably wouldn't build a
house with only a lathe. But once you have a lathe, you find things to use
it for.

The question "what is it good for" can be answered with examples (many),
but by the nature of it these will always be debatable around the edges. I
am not so interested in the complicated edges as in the beautiful center.

Regards, Wendell



On Sat, Feb 15, 2025 at 8:31b/AM Martin Honnen martin.honnen@xxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> 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.
>
>
>

--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...