[Home] [By Thread] [By Date] [Recent Entries]

Subject: Re: Re: If XSLT is declarative, why doesn't it feel that way?
From: "Alan Painter alan.painter@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Apr 2026 12:38:37 -0000
 I wanted to suggest that "onion-skin" approach is probably a form of
"composability" where modules (functions, templates) can be used and
re-used at different levels.

XPath 3.1 functions are also composable, with the option of composing new
functions from other functions.

On Mon, Apr 20, 2026 at 2:04b/PM Roger L Costello costello@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Folks,
>
> Ken, thank you again for your thoughtful follow-up. I appreciate it.
>
> Your clarification helped me see that there are really two distinct points
> in what you are describing, and I had initially focused on only one of
them.
>
> The first is the layering modelbthe centralized core with onion-skin
outer
> layers for specialization. That, by itself, is a powerful way to manage
> variation across multiple consumers.
>
> But your second pointbthat data-driven outputs are naturally addressed
> using declarative methodsbfeels even more fundamental.
>
> I had been thinking in terms of the familiar model:
>
> input b program b output
>
> and, from that perspective, it seemed natural to say that all programs are
> binput-driven.b
>
> But I now see that this misses an important distinction.
>
> In imperative systems, the program controls the flow and pulls data as
> needed.
>
> In declarative systems like XSLT, the structure of the input determines
> what processing occursbthe system reacts to the data.
>
> That is a very different mental model.
>
> Itbs not that imperative systems cannot be written in a push-like
> stylebthey canbbut doing so requires explicit design (dispatch logic,
> control flow, orchestration). In XSLT, that behavior is intrinsic: pattern
> matching and template application make the input itself the driver of
> processing.
>
> That helps explain why declarative approaches can feel different in
> practice, even if both ultimately operate on input to produce output.
>
> Taken together, your two points make the picture much clearer:
>
>    - Declarative processing is a natural fit when output is driven by
>    structured input.
>    - XSLT becomes especially compelling when that data-driven core must
>    support multiple differentiated outputs through layered specialization.
>
> In that light, I can see why a small example might fail to make the case,
> while a layered, multi-client system makes the advantage much clearer.
>
> This is a very helpful perspectivebthank you.
>
> Best,
> Roger
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/552232> (by
> email <>)

Current Thread
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member