Hi Roger,

LinkedDataHub has followed this approach for a while now, except that it
uses RDF as the data model and SPARQL as the query language, but the same
principles apply, including XSLT transforms.
https://atomgraph.github.io/LinkedDataHub/

My claim is that a majority of webapps are simply custom UX over
domain-specific CRUD APIs, and can be generalised using the following
function:

  Webpage = Transformation(Projection(Dataset))

For LinkedDataHub, this can be made more specific:

  Webpage = XSLT(SPARQL(RDFDataset))

The codebase is basically an implementation of this function.

Ibve written quite a few blog and LinkedIn posts on this topic, if youbre
interested.

Best,

Martynas
atomgraph.com

On Fri, 17 Apr 2026 at 17.01, Roger L Costello costello@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Folks,
>
> You are building a web application.
>
> It needs to:
>
>    - accept requests
>    - process data
>    - apply transformations and business rules
>    - return results
>
> In most systems today, this logic is implemented using imperative code.
> You write controller methods, service classes, and orchestration logic that
> prescribe step-by-step *how* the system should behave.
>
> But not all technologies work this way.
>
> Some technologies allow you to describe *what* you want, rather than *how*
> to do it.
>
> These are declarative technologies.
>
> One area where declarative technologies are especially well developed is
> the XML ecosystem.
>
> In the XML ecosystem, this includes:
>
>    - XSLT for transformation
>    - XQuery for querying and composition
>    - XPath for selection
>    - validation languages such as XML Schema and Schematron
>
> These technologies are powerful, expressive,
andbimportantlybdeclarative.
>
> They allow you to define:
>
>    - what a transformation should produce
>    - what data should be selected
>    - what rules must be satisfied
>
> without specifying procedural control flow.
>
> Now consider what happens when you turn this logic into a web application.
>
> You want users (or other systems) to send data to your application and
> receive results in return. In other words, you want to expose declarative
> processing logic as a web application.
>
> At this point, something subtle but important happens.
>
> Instead of continuing in a declarative style, you often switch to an
> imperative one.
>
> You introduce a web frameworkboften Java-basedband begin writing code
that:
>
>    - receives HTTP requests
>    - parses input
>    - invokes transformations
>    - manages control flow
>    - constructs responses
>
> Your XSLT or XQuery logic becomes a component inside a larger imperative
> system.
>
> The center of gravity shifts.
>
> The declarative core becomes surroundedband often overshadowedbby
> procedural glue code.
>
> This is the standard approach today. It works. It is widely used. It is
> well supported by tools and frameworks.
>
> But it raises an important question:
>
> *Is this the right architectural model?*
> ------------------------------
>
> *A Missed Opportunity*
>
> The XML community explored a different path many years ago.
>
> Frameworks such as Servlex, based on the EXPath Web Application
> Specification, demonstrated that it was possible to build web applications
> declaratively.
>
> In that model:
>
>    - HTTP requests are mapped declaratively
>    - application flow is expressed as pipelines
>    - transformations and queries remain first-class
>    - the entire application is described, not programmed step-by-step
>
> An application might look like this:
>
> HTTP request
>   b declarative routing
>   b XProc pipeline
>   b XSLT / XQuery / validation steps
>   b HTTP response
>
> In this model, there is no large imperative wrapper. There is no need to
> manually orchestrate each step in code. The structure of the application is
> visible, explicit, and composable.
>
> These ideas wereband still arebpowerful.
>
> Yet they did not become the dominant approach.
>
> The industry moved in a different direction.
>
> Despite the lack of active development in some of these frameworks, the
> underlying approach has not disappeared. In fact, declarative web
> application models based on XML technologies continue to be used
> successfully in production environments. Long-lived systems built on these
> ideas have demonstrated stability, low maintenance requirements, and the
> ability to evolve over time without extensive rework.
> ------------------------------
>
> This mailing list has a size limitation. If you want to see the whole
> paper, email me.
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3206323> (by
> email <>)