Revisiting XML in the age of AI

XML and the semantic web were a big part of my career between 2000 and 2020. XML Schema? Done. Schematron? Got it. RDF Schema? Been there. Even though one could validly argue that these standards were (overly) complicated, their promise was always up there. It felt like we were building the future.

And then I stopped caring. There was no defining moment. I just let it go. Other technologies became more interesting. Often, simpler solutions performed better. Why carry all the baggage of XML when you have JSON?

By now the ICT world has been completely upended by AI. Like so many people, I almost have a feeling of nostalgia, of lost worlds. Not that everything was great back then, but different. Something you grew up with. But now it is gone.

Or is it? What does XML look like today, in the context of the tidal wave of ever-increasing AI capabilities? Is there still a role for XML in 2026? What has changed?

These are some thoughts, loosely organised.

The main take-away is that any modern day frontier LLM is perfectly able to do high-level XML work. Asking for a particular XPath, debugging a complicated XSLT stylesheet, dealing with obscure XML Schema features? It just works. This used to be specialised knowledge, but it is fully and completely democratised. The baseline has been raised massively. This is amazing.

I was a bit surprised by this. A common line of reasoning is that LLMs perform best when there is a large amount of training data. For example, it is commonly said that LLMs are much better in Python than in COBOL because of all the Python code out there. I thought that things like XSLT and XML Schema were sufficiently niche that LLMs would struggle, but I was wrong. Maybe there was a lot more material available for training than I thought, or maybe the whole line of argument is bull (and COBOL is no longer safe either).

Also, I found that LLMs are occasionally too smart for their own good. There are multiple ways to interact with XML programmatically. This ranges from DOM and SAX in Python or Java to XSLT in its different varieties (and there are some more candidates). One noticeable characteristic of these approaches is that they all have a "sweet spot". Sometimes, by virtue of its design XSLT could do things in 2 lines that would cost 100 lines of Python, or vice versa. An experienced coder knows when to pick one approach, and when to switch strategies. LLMs don't seem to do this. They seem to have a tendency to persist in staying with a language choice when the problem they are asked to solve is slowly moving out of that language's "sweet spot". This could be a temporary issue as LLMs get smarter by the day. Today, the solution is either to accept convoluted code and not worry about it or explicitly tell the LLM to change course.

Of course, explicitly telling an LLM to do something else requires a certain understanding of the thing the LLM is doing under the hood. I find it hard to judge how much "implicit" knowledge one needs to successfully work with LLMs when asking for XML-related stuff. I do notice that I continually tweak, deny, and suggest. This strategy seems to work. I haven't tried following the LLM instead of guiding it. This means your mileage may vary. In general, I still think there is some value in at least grasping the basics of XML and XSLT. It will make you a substantially better prompter. Just consider yourself lucky that you don't have to go through the weird and exotic kind of bugs that we had to go through.

Regarding the "is there still value in XML?" question, I would like to give a qualified positive answer. A key feature of XML is the difference between markup and content. Markup structures the text, and gives meaning. I think this is still valuable in (high-value) content. Markdown has its uses. So does JSON. But neither is perfect for mixed content where we want to be able to assign meaning to fragments, especially when there could be conflicting opinions or history. It is not just the ability to annotate text inside the same resource by means of elements and attributes, but also the fact that XML has a standardised language for locating positions or ranges.

The distinction between markup and text is also something we can use to our advantage when introducing LLMs. It is easy to write constraints that say that the text should stay unchanged, whereas the LLM has more freedom to operate on the tags.

Finally, a small irony. Anthropic's own prompting guide recommends XML tags to structure prompts: wrap the instructions in <instructions>, the context in <context>, each document in <document>. No schema, no namespaces, nothing has to be well-formed. Just tags around text, so the model knows what is what. That is exactly the part of XML I would call still valuable.

LLMs have thoroughly upended the traditional XML world. But it is not because of LLMs that XML has faded away from new projects in the enterprise. There was already a growing sense of disillusionment with XML around 2015. I don't think XML will rise from the ashes back to a prominent position, but there is some value in the design principles that made XML what it is. And there is a massive amount of XML out there in data warehouses, file systems, databases, etc. It would be silly to throw that out.

Maybe history will repeat itself. XML itself was a subset, a simplification of SGML and things like HyTime. There could be room for another simplification that fits well in the current age of LLMs and agents. It is something I will be exploring on these pages.