Strengths

This technology stack has some peculiar strengths.

Security advantages of the architecture

Client-side processing means no data exfiltration, ever!

This can be tested by using any of these applications off line with no network connection, using only the page saved in your browser cache. Everything runs because all the necessary data transmissions have been accomplished when the page with its scripts and resources are first loaded. The browser then provides the application runtime for processing whatever data the user chooses to make available, without relying on any other system anywhere. Since the network connection is no longer needed, it can be closed and the application runs the same.

Separation of concerns

As described on the Architecture page, a typical application is designed using a combination of complementary resources deployed in layers, each of which provides a distinct if related set of design problems.

• HTML/CSS/Javascript/page interactivity
• XSLT supporting HTML view
• XML source (tag set / model / constraints / usage scenario)
• browser environment with XSLT and ECMAScript support

Assuming each of the separated concerns is addressed adequately, their strong separation provides for easier more sustainable maintenance. It is worth questioning whether this assumption applies - or not. XSLT is fantastic if you have XSLT expertise available and as long as the stack holds up.

One purpose of this repository and Demo portal is to serve as a test of the latter dependency in this statement -- does the stack hold up?

As long as that can be shown, and assuming XSLT skills are at hand, the strong separation between the 'machine' (in this case, the browser combined with its on-board XSLT engine), the 'source data', the 'stylesheet', and the 'page', makes extension and maintenance over time possible. Each layer can be simpler and more consistent on its own terms. The bottom layer is a commodity and the second layer up is typically also supported by standards such as TEI, DocBook, DITA, NISO JATS, NISO STS, OSCAL and others.

The separation also makes it possible to deliver similar functionality within different application contexts, when useful, because code bases are more portable. Tweaking a CSS is often easier than changing an XSLT; but the same XSLT might also be used to good effect in a different use case, paired with very different CSS.

Integration with web tech / HTML

Relatively strong integration between XML/XSLT and web technologies continues to demonstrate the higher-order benefits of network effects acting at several levels, once we begin practicing meaningful data interchange. In particular, because CSS and Javascript are better than they used to be, these applications are better than they used to be. More generally, in the technical infrastructure supporting the data lifecycle, any advance at any level provides for improvements at all levels. This is entirely because of adherence to non-proprietary standard specifications, both by data creators and by the tools developers we rely on.

Small code bases

XSLT is a verbose language if character count is the measure. Nevertheless because it is declarative and because its processing model is highly optimized for the use case (document transformation, typically entailing map, filter and reduce operations in some combination), XSLT applications can frequently be small and succinct even when XSLT itself is not.

Obsolete, obsolescent, or stable?

Intriguingly, XSLT 1.0 provides implicit assurance because the technology is relatively stable, especially when compared to alternatives. Even while XSLT continues to evolve (through versions 3.0, 3.1, 4.0?), XSLT 1.0 remains as defined. No new development of the core technology means no new bugs and no new vulnerabilities.