Haven't seen this much interest in XML/XSLT in 20 years.
replies(1):
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!)
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: The "simpleness" made it easy for producers/consumers with unstructured languages (ie JS,Python,PHP,Ruby,etc) to participate in the ecosystem without feeling that things were "bloated" (technically a drawback perhaps but pushed popularity)
2: DTD was put into the standard, but from my recollection most stuff was defined with XSD in practice (so a separate standard), so now implementations needed to carry both deprecated stuff and another layer. (Then again, sure you could generate bindings with XSD).
3: We needed 3 versions of Swagger/OpenAPI to come to a somewhat good standardized binding API (it itself depends/extends JSON Schema), but it's there today and we don't need to consider deprecated libraries,etc and can just point our code-generators to the schema documents and get automatic bindings.
So in practice you basically have no fragility today even if there is binding generator bugs, but that feels more of an implementation issue than a systematic error, and if anything it shows that schema generators.
Now one could argue that the "free-ness" of the JSON Format made schema generators needlessly cumbersome, and maybe that's true to a certain extent but it's still not nearly as bad as trying to interpret ASN.1 files despite all the standards (there it is.. "good luck trying to find the correct IDL files").