I worry any head-to-head comparison with an imperative language programmer regarding any given single task will degenerate into complaints about verbosity and "too many angle brackets".

Regards,
--Paul

Imperative languages are designed to dictate the outputs (pull model).

Declarative languages are designed to react to the inputs (push model).

XSLT outshines imperative approaches when you leverage import precedence with the ability to declaratively override behaviours with onion-skin outer layers that supplement or inhibit inner-layer behaviours.

XSLT was designed for publishing where these layers can interact and provide fine-grained control of a read-only core with selective outer solution-specific details. In publishing, the author of the XML is in control of the output, not the programmer. The publishing task has to react to the arrival of content in order to produce the output. Outer-layer behaviours can intercept the handling of arrived content and behave differently as necessary to override default or built-in behaviours.

Consider as an example the publishing services at https://RealtaOnline.com where at the bottom of the home page you can see two dozen standards organizations each getting their own customized national presentation of standardized content. There is a single core set of declarative behaviours supporting NISO-STS XML presentation. Each client is supported with their dedicated onion skin. When core behaviour is enhanced, every client benefits. When any client wants specialization, other clients are not affected.

Onboarding a new client takes hours to get their own cover sheets, headers, footers, fonts, geometry, etc.

This is the benefit of the declarative approach: the core need not know how it is being leveraged. There is, however, an obligation for the core to be written in the way to be specialized.

And this isn't reserved for publishing ... in your real-world situation it is the essence of leveraging the push model of input processing and which component (input or program) is driving the content of the output that should guide your choice of implementation.

In your new project, if you have the need to leverage common behaviours for multiple differentiated outputs, your use of XSLT should be readily justified.

If, however, you have a single task that is single purpose ... well, then I suppose the declarative style comes down to personal preference, familiarity, and plans for maintenance.

At 19/04/2026 11:53 +0000, Roger L Costello costello@xxxxxxxxx wrote:

Hi Folks,

I'll be starting a new project soon. The current system is a Java-based web application, and I'd like to move it toward a less imperative, more declarative architecture.

On paper, this seems straightforward: use technologies like XSLT, XPath, and XQuery to express transformations declaratively.

But I'm running into a practical problem.

If I show Java developers their code alongside equivalent XSLT, I already know what the reaction will be:
    * "This is just another programming language."
    * "It has iteration, functions, recursion--how is this fundamentally different from what we already have?"
    * "Why should I replace code I understand with code I don't?"

At that point, the argument that "XSLT is declarative" doesn't land. It feels like a theoretical distinction rather than a practical one.

Which leads me to a more uncomfortable question:

If a language is declarative, but most developers do not experience it as declarative, does that distinction actually matter?

In other words, is "declarative" a property of the language--or of how the language is perceived and used?

Because in practice:
    * XSLT is often written in a way that looks and feels procedural.
    * Developers map it mentally onto loops, conditionals, and function calls.
    * The promised shift in thinking ("what" rather than "how") never really happens.

And if that's the case, then a proposal like:

"Let's replace a Java implementation with XSLT because it's declarative."

is unlikely to succeed--not because XSLT is weak, but because the benefit is not obvious to the people being asked to adopt it.

So I'm trying to understand:
    * How do you make the declarative nature of XSLT visibly obvious to someone who doesn't already believe it?
    * Are there patterns, examples, or constraints that make XSLT clearly different from imperative code?
    * Or is the harder truth that some declarative technologies--such as schemas (e.g., XML Schema), data models, and rule-based systems (e.g., Schematron)--communicate their declarative nature more directly than others?

I'm not questioning the theoretical classification of XSLT.

I am questioning whether that classification is sufficient to drive adoption in real-world systems.

Curious to hear how others have dealt with this.

Best,
Roger
<http://www.mulberrytech.com/xsl/xsl-list>XSL-List info and archive
<http://lists.mulberrytech.com/unsub/xsl-list/96802>EasyUnsubscribe (<>by email)

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$50 (5 hours free!) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |