|
Subject: Re: [xsl] 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 |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| [xsl] Re: If XSLT is declarative, w, Roger L Costello cos | Thread | Re: [xsl] Re: If XSLT is declarativ, Martynas Jusevičius |
| [xsl] Jaxen 2.0.1 released, Elliotte Rusty Harol | Date | Re: [xsl] Re: If XSLT is declarativ, Martynas Jusevičius |
| Month |