Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.

Endpoint Systems - Integrating Everything

Introducing the XSLT and XQuery Libraries

04/20/2026

Introducing the XSLT and XQuery Libraries

We built XSLT and XQuery parses for .NET Core and the old man yells at clouds for a minute or two

I'm very pleased to announce this today, but before I do - a rant.

Something that has been an absolute thorn in my side with the .NET ecosystem has been the near complete lack of interest or support for nearly anything and everything related to XML. You'd think that, given its prevalence in so many different applications, that it wouldn't be as bad as it is. But this has consistently gone ignored and neglected, to the point that most .NET developers these days don't really know what to do with either of these tools. Much of this, I've long suspected, is simply because it's too easy to use and that it doesn't drive sales. I suppose that, as a publicly traded company, this is a valid reason not to drive certain technological innovations - I've been around long enough to remember how every single innovation Microsoft had was either shoved into SQL Server's very expensive licensing ecosphere, or cast aside.

Well, that changes, starting today.

With some help from Claude (okay, a lot of help), we now have first class XSLT and XQuery support in .NET Core. XSLT supports versions 3 and 4, while XQuery supports versions 3.1 as well as 4 - version 4 isn't quite formalized as of yet, but we took as many of the 'good parts' as we could and included them in our release.

Why does it matter?

It matter for this one simple reason: structured data has never gone away, and XSLT and XQuery are very mature data parsing languages, and even in the face of today's RAGs and vectors and other exciting and new innovations, it's always good to have something tried, true and simple for doing what needs to be done with structured data.

I'm not asking anyone to take my word for it, nor am I going to tell you that XML is some sort of superiod data structure to JSON. What I AM trying to say is, there comes a time and a place for using both of them together for different purposes. For example, and this still gets wild reactions for some reason, but JSON is not a document. It's a data transmission format. This should be the least controversial thing to say out loud, but to a webdev it's some kind of weird heresey. No matter. I should also mention that XSLT and XQuery also support JSON, so it's not like they're exclusive or anything.

These two parsing engines (available on NuGet as libraries and CLI tools btw) are two critical components to a larger XML-based ecosystem we're calling Phoenixml, which consists of:

  • An embedded XML database engine built on LMDB called PhoenixmlDB
  • an XProc data integration platform we're calling ConduitXP that is built from the ground up as a semi-open BizTalk replacement platform
  • A web/documentation generation tool called Crucible which makes very nice static websites, sprinkled with a dash of Javascript to do text search and pretty things up a bit

There's more that will get added to that list, but those are the big ones for now. Crucible isn't all that special, but it is a nice example of how you can take Markdown files and turn it into markup with some pretty simple tooling. I'm half tempted to build something that takes YAML files and turns them into XML and vice versa, just so people have a useful way to manage that crappy file format better. I might throw that to Claude and see what we can do with them.