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 model-the 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 point-that data-driven outputs are naturally addressed using
declarative methods-feels even more fundamental.
I had been thinking in terms of the familiar model:
input $B"*(B program $B"*(B output
and, from that perspective, it seemed natural to say that all programs are
$B!H(Binput-driven.$B!I(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 occurs-the system reacts to the data.
That is a very different mental model.
It$B!G(Bs not that imperative systems cannot be written in a push-like
style-they can-but 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 perspective-thank you.
Best,
Roger