Nick Wellnhofer is stepping away from libxml2 after a decade of unpaid maintenance. He’s forking it under the AGPL, but that will probably scare off most corporate users.
Meanwhile libxml2 is still everywhere. Without someone with real backing, a core piece of infrastructure is about to go unmaintained.
Once again, the open-source funding problem is laid bare: the internet runs on the unpaid evenings of a few people until they burn out (add relevant reference from XKCD, obviously).
If you think you need libxml2, think again. XML is a complex beast. Do you really need all those features? Maybe a much smaller, more easily maintained library would suit your needs while performing better at the same time!
For instance, consuming XML and creating it are two very different use cases. Zooming into consuming it, perhaps your input data has more guarantees than libxml2 assumes, such as the nonexistence of meta definition tags.
Its a shame that xslt seems to be struggling so much at the moment. If xslt 3 support was fully implemented in libxml2 (and therefore xsltproc and browsers) then it would be by far the most sensible option for designing anything to do with getting text onto the web.
* XSLT is still the only native templating option for HTML pages that runs natively in the browser (but just now you are limited to XSLT v1.0 which as a number of drawbacks and limitations)
* XSLT/XML is still best at text markup. In particular interpolation. There is no simple way to represent marked up text in, say, JSON.
* Content federation (atom, rss) is still very dependent on XML.
Surely somebody somewhere has money to pay for a greybeard to fix XSLT for us? It seems far to fundamental to be left to wither on the vine.
12 comments
[ 4.4 ms ] story [ 37.2 ms ] threadMeanwhile libxml2 is still everywhere. Without someone with real backing, a core piece of infrastructure is about to go unmaintained.
Once again, the open-source funding problem is laid bare: the internet runs on the unpaid evenings of a few people until they burn out (add relevant reference from XKCD, obviously).
For instance, consuming XML and creating it are two very different use cases. Zooming into consuming it, perhaps your input data has more guarantees than libxml2 assumes, such as the nonexistence of meta definition tags.
* XSLT is still the only native templating option for HTML pages that runs natively in the browser (but just now you are limited to XSLT v1.0 which as a number of drawbacks and limitations)
* XSLT/XML is still best at text markup. In particular interpolation. There is no simple way to represent marked up text in, say, JSON.
* Content federation (atom, rss) is still very dependent on XML.
Surely somebody somewhere has money to pay for a greybeard to fix XSLT for us? It seems far to fundamental to be left to wither on the vine.