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, and-importantly-declarative.
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 framework-often Java-based-and 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 surrounded-and often overshadowed-by 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"*(B declarative routing
  $B"*(B XProc pipeline
  $B"*(B XSLT / XQuery / validation steps
  $B"*(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 were-and still are-powerful.
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.