Hi, Roger,

First, I want to thank you. You've been asking hard questions for years
(and really should be writing a blog from all of this, because I worry
you're preaching to the choir here) and it's not forgotten. I'm a big fan.

I'm going to offer up a slightly different perspective that suggests that
we may be seeing a declarative revolution taking place right in front of us.

Markdown was invented to solve a particular problem that HTML has: its
verbosity. Markdown is a (somewhat non-standardized) compact form of HTML.
With the use of AI based systems, Markdown has become the de facto standard
for web interaction with agents, and is increasingly how we also provide
content for GitHub repositories, code content and more. I'm currently
working on a Markdown format called Databooks that lets you with
markdown encased
code blocks with YAML metadata.

This is having an impact, because these tend to minimise the requirements on
having extensive Javascript layers for output. If you embed (or link) data
in this fashion, you also create a solid separation of concerns that pushes
in favor of declarative architectures. I'll be writing on this point
shortly. For now, there's more information on databooks at
https://github.com/kurtcagle/databook . and on my The Ontologist website at
https://ontologist.substack.com/p/databooks-markdown-as-semantic-infrastructu
re
and
https://ontologist.substack.com/p/databooks-part-ii-the-semantic-execution
.

Also, with databooks you can embed the XML and XSLT layers in the same
document
as well. I'll be writing extensions that support this via Saxon's Javascript
encoding.


*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@xxxxxxxxx
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>
Calendly: https://calendly.com/thecaglereport
Blogs: The Ontologist <https://ontologist.substack.com>


On Fri, Apr 17, 2026 at 11:02b/AM Roger L Costello costello@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Martynas,
>
> Thank youbthatbs a very interesting perspective.
>
> Your formulation:
>
> Webpage = Transformation(Projection(Dataset))
> Webpage = XSLT(SPARQL(RDFDataset))
>
> really resonates with the architectural direction I was trying to
> describe. Itbs a very clean way of expressing the idea that many web
> applications can be understood as selecting relevant data from a dataset
> and then transforming it into a presentation.
>
> I also appreciate your point that a large class of web applications can be
> viewed as custom UX over domain-specific CRUD APIs. That aligns closely
> with the notion in the paper that much of what we currently implement
> imperatively is fundamentally data selection and transformation, and could
> be expressed declaratively when the data model is well-defined.
>
> Whatbs especially interesting is that your example shows the same
> architectural pattern emerging with a different underlying data modelbRDF
> graphs queried with SPARQLbrather than tree-structured XML, even though
> XML-based technologies such as XSLT still fit naturally into the
> transformation stage. That reinforces the idea that the core issue is not
> XML vs. non-XML, but whether the application is organized around
> declarative data flow or imperative orchestration.
>
> Ibd be very interested in reading your posts on this. It seems like a
> natural extension of the ideas in the paper, especially in terms of
> generalizing the projection + transformation model across different data
> paradigms.
>
> Thanks again for sharing thisbitbs a great contribution to the
discussion.
>
> Best,
> Roger
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/1217935> (by
> email <>)