Re: [xsl] Re: If XSLT is declarative, why doesn't it feel that way?

["Martynas Jusevičius martynas@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

One more thing to note is that declarative languages such as XSLT are
domain-specific rather than general-purpose. They operate on the XDM data
model which allows users to consider the problem space at a higher level of
abstraction. The language specification and conforming implementations
provide these abstractions out of the box.

In other words, although I cannot formally prove it, XSLT offers fewer ways
to manipulate XML data than a general-purpose language such as Java -- and
that is a good thing :)

On Mon, Apr 20, 2026 at 2:38b/PM Alan Painter alan.painter@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>  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)
>>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3206323> (by
> email <>)