@ndw Hopefully the <oXygen/> devs will implement it properly. #DocBook #XSLT

Sunsetting the XSLT 1.0 DocBook Stylesheets. Occasionally, I observe issues opened on the XSLT 1.0 stylesheets. That makes me uncomfortable, because I don’t think anyone is ever going to fix them. #XML #DocBook #XSLT

https://so.nwalsh.com/2026/03/31-xslt10

Sunsetting the XSLT 1.0 DocBook Stylesheets

Occasionally, I observe issues opened on the XSLT 1.0 stylesheets. That makes me uncomfortable, because I don’t think anyone is ever going to fix them.

So… a weblog by norm

https://justinjackson.ca/xslt

#XSLT makes #RSS #feeds readable for normies. #Chrome is removing it by 2026. Here's why that matters for podcasters and the open web.

Don't kill my pretty RSS feed (XSLT)

XSLT makes RSS feeds readable for normies. Chrome is removing it by 2026. Here's why that matters for podcasters and the open web.

Justin Jackson

I have updated the Go-XML suite (a parser, XPath and XSLT) and started the documentation at

https://doc.speedata.de/goxml/

The XSLT processor is still work in progress, 21.8% of the official test suite pass. So all basic stuff will work!

#xslt #xml #xpath #golang

My supervisor: run #XSLT transformation remotely with #Apache #Ant.
Me:

#apacheSoftwareFoundation #asf #opensource

»PhoenixmlDb.Xslt« – neuer Prozessor für #XSLT 3.0/4.0 auf .NET-Basis:
https://www.nuget.org/packages/PhoenixmlDb.Xslt
PhoenixmlDb.Xslt 1.0.15

XSLT 4.0 transformation engine for PhoenixmlDb

We *NEED* to save #xslt !

I read this article (https://wok.oblomov.eu/tecnologia/google-killing-open-web/) and cannot thing but the fact there’s a precise will to kill the free internet and make it a product.

Google is killing the open web

The juggernaut is taking advantage of its dominant position to enclose and destroy the commons.

wok

RE: https://oldbytes.space/@drscriptt/116219403988667257

TIL I learned about #XML namespaces `select`ing them in #XSLT <xsl:… select=“…”/> statements.

What was particularly entertaining was the fact that the nodes weren’t prefixed.

Instead a namespace was set at — I don’t know what to call it — the same way the stylesheye is referenced in a <? … ?> statement up above the <!DOCTYPE/>.

Once I figured that out and how to select it, things started clicking.

TIL that #xsltproc (on my system) only supports #XSLT version 1.1.

I learned this because the `replace( … )` function apparently requires XSLT version 2.0.

I want the `replace( … )` function because #IANA put two comma separated addresses in one record while all the others are a single address.

The node the addresses are in is named “address” which seems singular to me.

But IANA put `192.0.0.170/32, 192.0.0.171/32 ` in an <address/> node.

Thanks IANA. 😒

<registry>
<registry>
<!-- … -->
<record>
<address>…</address>
<!-- … -->
</record>
<!-- … -->
</registry>
</registry>

No, I have no idea why <registry/> is nested the way that it is.

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml

I’m still annoyed that Chrome and Firefox are dumping xml+#xslt support. I don’t want to redo everything in json or whatever. I don’t want to code what xml+xslt do out of the box with no code. I moved the parsing and transform to PHP and it works fine, but it means it takes a few seconds before the page loads. Doing it in the browser *feels* faster because I can load the rest of the page instantly. Anyway, don’t mind me, just ranting.