Rather than just build my own blog on it, I wrote it up for others to use and I've published it on GitHub https://github.com/vgr-land/vgr-xslt-blog-framework (2)
Since others have XSLT on the mind, now seems just as good of a time as any to share it with the world. Evidlo@ did a fine job explaining the "how" xslt works (3)
The short version on how to publish using this framework is:
1. Create a new post in HTML wrapped in the XML headers and footers the framework expects.
2. Tag the post so that its unique and the framework can find it on build
3. Add the post to the posts.xml file
And that's it. No build system to update menus, no RSS file to update (posts.xml is the rss file). As a reusable framework, there are likely bugs lurking in CSS, but otherwise I'm finding it perfectly usable for my needs.
Finally, it'd be a shame if XSLT is removed from the HTML spec (4), I've found it quite eloquent in its simplicity.
(1) https://news.ycombinator.com/item?id=44393817
(2) https://github.com/vgr-land/vgr-xslt-blog-framework
(3) https://news.ycombinator.com/item?id=44988271
(4) https://news.ycombinator.com/item?id=44952185
(Aside - First time caller long time listener to hn, thanks!)
BTW, as I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation that they may want to consider contributing to one or more browsers. (It is a JIT that generates machine code directly from XSLT and several other data transformation and policy languages, and then executes it).
I don’t think XSLT 1.0 is all that complicated. It’s a declarative language for transforming trees into trees or strings in an arbitrary manner, and you could argue that problem statement is too wide, but if you’re OK with it then I don’t think there’s any inappropriate complexity in the solution.
The surface syntax is bad, true, but that’s because of its verbosity, not its complexity. Once you put a bit of an Algol veneer on it[1], it becomes perfectly palatable.
[1] https://juniper.github.io/libslax/slax-manual.html
One of the nice things about Atom is that you can declare whether text constructs (e.g. title, content) are text (good if there’s to be no markup), HTML encoded as text (easiest for most blog pipelines), or HTML as XML (ideal for XSLT pipelines).
Is there something (besides (lack of) client support) that makes RSS better suited for podcasting?
I think the reason that RSS is used can be summed up as: Apple is lousy at developer relations.
They didn’t invent podcasting (name or technology), but they were the first major player to do stuff with it. Although consensus was already strong that RSS was technically terrible and Atom had existed for over a year (though it was not finalised) and was even fairly popular, Google especially having embraced it⸻ Apple chose the old-and-inferior RSS as their foundation. And then stuck their heads in the sand and didn’t talk to anyone, ever. Because that’s Apple’s style: throw stuff out there, let people do what they want with it, don’t attempt to be a community leader.
So what did everyone else do? Feeds had to be RSS, of course, to appease Apple. And then other apps implemented RSS, just RSS, like Apple had done, because what’s even the point of using Atom if it won’t work on the biggest platform? General-purpose feed readers didn’t have much specialised functionality, and had a few major players and a long tail of other clients; it was a much more well-distributed field, all things considered. But podcasting was, as I understand it, much more only one player for a while, then only up to two or three; and it depended on more specialised functionality. So it was never as democratic as general web feeds.
Over time podcast feeds ended up a horrible mess of repeating the same logical field 3–6 times in differently-named elements for different platforms, as they all added their own namespaces and mostly-identical-but-sometimes-slightly-different data fields¹. Because people were using it as an actual data format with domain-specific fields, they were more likely to just use an XML parser and talk just RSS, rather than a feed library which would be RSS-/Atom-neutral.
I believe that at some point Apple did implement Atom (not sure when), but it was too late, too much other stuff didn’t support it and so no one used it and so they ripped it out again a couple of years ago, and podcasting is set in stone using the inferior RSS.
I should write this up further at some point: the tragedy of podcast feeds.
—⁂—
¹ This stupid pattern can be seen on the web too. <meta name=description>, <meta property=og:description>, <meta name=twitter:description>, something in a JSON+LD block…
A quick glance at Atom though says to me its worth an attempt to refactor.
(I did also make an RSS version of it, https://temp.chrismorgan.info/2022-05-10-rss.xsl, including handling RSS’s stupid date format as perfectly as possible for some reason. It would actually be a useful guide for reversing that process, too…)
For maximum enthusiasm in this direction, make posts actual Atom Entry Documents. Will it benefit anyone? … well, I suppose it could be convenient for tooling to make a feed by just concatenating documents.
Well yeah I hope not! That's what a programming language is for, to turn data into documents.
> I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.
It then dawned on me that the MVC framework for XML is where XML is the model (or data or database table). And XSLT is the viewer in the rear. Meaning the web browser can browse database information.
I never appreciated this very much before. The web has this incredible format to see database information in raw form or a styled form.
I still want to see development of it in reverse, and I hope to find better use cases now that I understand this paradigm.
But you can kind of achieve what you want by treating the initial XML as a "view definition/configuration", and the referenced XSLT as a "view builder", and referencing your "model" as an external document via XPath document and applying to the XSLT template(s). i.e. you create configurations of your view that apply external data.
did you know that XSLT was shown to be Turing complete ? https://staff.emu.edu.tr/zekibayram/Documents/papers/XSLT_Tu...
On the other side, I find XML/XSD still much better than JSON. JSON is way too simple...
[1]: https://github.com/whatwg/html/issues/11523#issuecomment-318...
//Edit: Rephrased "PRs" to "Discussions".
There’s some rarely used tech that few have talked about in a long time. Tech giants have decided somewhat unilaterally to get rid of it because it’s barely used and has had security flaws.
There’s a discussion to be had about that specifically but most people didn’t care a jot about XSLT until it was threatened. What they do care about is tech giants controlling the fate of the internet. That’s a far bigger issue than can be solved in a GitHub discussion, but it doesn’t stop anyone trying.
[1] https://github.com/whatwg/html/issues/11578
// XSL $xsl_doc = new DOMDocument(); $xsl_doc->load("file.xsl");
// Proc $proc = new XSLTProcessor(); $proc->importStylesheet($xsl_doc); $newdom = $proc->transformToDoc($xml_doc);
// Output print $newdom->saveXML();
Because if you can remove any server processing, it's just the perfect solution for simple websites.
Dead Comment