|
Subject: Re: [xsl] Declarative Web Applications: A Modern Architecture From: "Martynas Jusevičius martynas@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Fri, 17 Apr 2026 15:15:26 -0000 |
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 <>)
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| [xsl] Declarative Web Applications:, Roger L Costello cos | Thread | Re: [xsl] Declarative Web Applicati, Roger L Costello cos |
| [xsl] Declarative Web Applications:, Roger L Costello cos | Date | Re: [xsl] Declarative Web Applicati, Roger L Costello cos |
| Month |