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

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

Indeed it is very different.


> 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.
>
>
And when those two concepts are put together, one can see that the
onion-skin layer specialization reacts to the input data before the core
has the opportunity to react to the input data.

This is why the core is oblivious to any specialization an onion-skin might
do.

The core can be read-only sacrosanct code, reacting to input data in the
default manner, unaware that the onion-skin layer has intercepted the
arrival of input data and done its own processing.

This is illustrated in my diagrams used at
https://www.xml.com/articles/2017/01/01/what-is-xslt/#d0e136 where:
- figure 3 shows the core stylesheet reacting to the arrival of pushed
nodes from the source tree where processing node "2" has default behaviour
  - https://www.xml.com/media/images/buildt.width-1280.png
- figure 4 shows the importing onion-skin layer intercepting the processing
of "2" source nodes with 2-prime behaviour and the default behaviour is
unaware it has been ignored
 - https://www.xml.com/media/images/buildti.width-1280.png
- figure 5 shoes the importing onion-skin layer intercepting the processing
of "2" source nodes, doing some 2-prime behaviour, and then continuing on
with the default core behaviour that is unaware it has been augmented
- https://www.xml.com/media/images/buildtii.width-1280.png

I drew these diagrams for my XSLT 1 lectures around 1998 I think, back when
XSLT 1 still was in draft form.

Both push/pull and import precedence are day-one concepts for XSLT that
remain today to be very important models for stylesheet writers to
comprehend and leverage.

Your original question, Roger, regarding declarative/imperative approaches
is not new and has been around since last century! And XSLT has been
answering that question for XML since last century!

Thank you, again, for bringing this to the forefront again for the next
generation of stylesheet writers. If they look at XSLT only through the
lens of their imperative programming upbringing, they will see no benefit
and only frustration. They need to understand the principles upon which
XSLT was designed and deployed.


>    -
>
> 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/96802> (by
> email <>)
>


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