[Home] [By Thread] [By Date] [Recent Entries]

Subject: Re: Declarative Web Applications: A Modern Architecture
From: "Martynas Jusevičius martynas@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 18 Apr 2026 10:08:11 -0000
Hi Paul,

On Sat, Apr 18, 2026 at 4:27b/AM Paul Tyson phtyson@xxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Martynas, I like what I've seen of your work at atomgraph. But XML and RDF
> are complementary technologies that address different (but overlapping) use
> cases. There should never be an either-or question when developing
> solutions in this space. The only debate should be about how to put them
> together to meet the given requirements.
>
I wasn't trying to pit the technologies against each other :) I agree they
are complementary. I use RDF/XML as the "bridge" format between the two
worlds. Some consider transforming RDF/XML with XSLT crazy, but they're
probably thinking about the open-ended general structure allowed by the
spec. However, using a constrained "plain" output profile makes it much
more manageable.


> RDF is no more "web-native" than XML. Every XML document on the web has a
> base URI that can be used to form URIs addressing every feature of the
> document, to whatever granularity is desired.
>
I have to push back on this claim :) Yes, all documents on the web have
base URIs. However, in XML URIs are just one of the XML Schema datatypes,
whereas in RDF they are the primary resource identifiersba class of nodes
distinct from literals altogether.

That is why Linked Data and the Semantic Web are based on RDF, not XML. In
XML, there is no standard way to describe an entity identified by a URI,
for example. Yes there can be conventions, but they would live outside the
specifications.
With RDF Linked Data, this would simply be achieved by dereferencing the
URI while accepting any RDF format (self-describing data).
With SPARQL query, that would be DESCRIBE <uri> - regardless of the URI or
the dataset.



> On 4/17/26 13:29, Martynas JuseviC ius martynas@xxxxxxxxxxxxx wrote:
>
> You're welcome :)
>
> I think one of the\xA0advantages of RDF over XML is its web-nativeness,
> namely that URIs are first class citizens in the data model. This way, the
> request URI is the same key as the entity ID in the database,
> collapsing/flattening the controller in MVC and making the MVC paradigm
> much more generic.
>
> I wrote about this recently:\xA0
> https://www.linkedin.com/feed/update/urn:li:activity:7442533331113627648/
> I also wrote this blog post series some years ago:\xA0
> https://atomgraph.com/blog/data-driven-software-architecture-1/
>
> I started myself with XML/XSLT but drifted to RDF close to 20 years ago :)
>
> Best,
>
> Martynas
>
> On Fri, Apr 17, 2026 at 8:02C"b,B/PM Roger L Costello costello@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> Hi Martynas,
>>
>> Thank youC"b,bthatC"b,b"s 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. ItC"b,b"s 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.
>>
>> WhatC"b,b"s especially interesting is that your example shows the same
>> architectural pattern emerging with a different underlying data
modelC"b,bRDF
>> graphs queried with SPARQLC"b,brather 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.
>>
>> IC"b,b"d 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 thisC"b,bitC"b,b"s 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/3206323> (by
>> email)
>>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/1043515> (by
> email)
>
> 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
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member