Some interesting uses of XML

Recently, a proposal to remove XSLT (an XML-based stylesheet language) from the HTML spec was put forward by the Chrome team and has begun to gain some traction. Opinion on this move seems to be divided - some agree that XSLT is past its use-by date, whereas others view this as just the latest act in Google's war on the open web. One interesting blog post frames the move in the context of other times Google has sought to cripple or discontinue open, XML-based standards.

I found it interesting that many of the responses to that post (on, eg, HackerNews, lobste.rs, etc) focused on how bad XML is as a technology. The suggestion by many seems to be that XML *itself* is past its use-by date, that nobody really uses it anymore, and in 2025 we should all be using JSON instead.

Don't get me wrong: I really like JSON, especially for APIs. When I am exploring a new API and I find JSON instead of XML I am happy. But XML is still used a lot, and many of the technologies that are (or could be) core to the open web are based on XML. Here are some XML-based standards I find interesting. I don't use them all, and they vary in importance and popularity, but they all have their uses and if they were to disappear overnight I think we would be worse off.

RSS / Atom

These two standards may need no introduction amongst this audience as they are quite well-known ways to syndicate content on the web. Traditionally the main use case for RSS (I refer to RSS here for brevity but this all applies equally to Atom) has been news websites and blogs, allowing any feed reader that supports these standards (and there are many) to access the underlying content. More recently, RSS has been used in the podcast world, allowing users to subscribe to podcasts in a way that is more resilient to vendor lock-in than, for example, following them on Spotify.

The great thing about RSS, in my opinion, is the control it gives users over how and when they consume content. There are RSS-based feed readers for every conceivable platform, written in many different languages. Some are focused on simplicity whereas others are heavily customisable. They can fetch content on-demand or periodically. They can download content for offline use. And a good RSS reader can be a one-stop shop for all your online reading needs: all your news and blogs in one place, and if you see a new feed you like, you just add that to your existing reader. I have even (shameless plug) written a Python app that fetches a bunch of feeds and sends me a "digest" email summarising the new entries once per day.

And yet, there is a common perception that RSS today is dying or dead. I don't think that is true, but certainly it is nowhere near as popular as it used to be. The turning point was arguably the decision by Google to kill off Google Reader, a hugely popular browser-based RSS reader, in 2013. Since then, the popularity of RSS has been on a downward trend. This in turn has led to many news websites and blogs either discontinuing their RSS feeds or removing them from view, which compounds the problem. However, though the once-ubiquitous RSS subscribe buttons have disappeared from many platforms, often they do actually make RSS feeds available. You may just have to search for them separately, or use a browser addon that exposes a subscribe button where it can locate an RSS feed for a web page.

OPML

So RSS allows you to track syndicated content on the web. But how do you track your RSS feed subscriptions? That's where OPML (Outline Processor Markup Language) comes in. It is a simple XML-based format for "outlines", defined as "a tree, where each node contains a set of named attributes with string values". Today, OPML is mainly used by RSS feed readers to store lists of subscribed feeds, optionally sorted into categories.

OPML is widely supported by RSS readers, so if you want to move from one reader to another, it is easy to take your subscription list with you.

The interesting thing about OPML is that it doesn't seem to have been made specifically for describing lists of RSS feeds, it is generic enough that it could conceivably have been used for a large range of other things, and in fact if you decided today to write, from scratch, a specification for describing lists of RSS feeds, you would probably come up with something quite different. And yet, that is largely what OPML is used for today. It almost feels like an accident of history.

GPX & friends

Those of you with an interest in running, cycling or hiking may be familiar with the GPS Exchange Format (GPX). It is a simple format for displaying GPS data. The basic "unit" in a GPX file is the waypoint, which contains at least latitude and longitude data and optionally time, elevation and certain other data. GPX can be further extended to allow more types of information to be stored (such as heart rate, cadence, etc). Waypoints are usually grouped together into tracks, which describe a path.

Originally developed by a company called Topografix, the schema has been stable for many years and the format is now widely supported by navigation and fitness tracking software. Personally I have found myself using GPX a lot, both to store details of runs and hikes I have done and to download and display walking routes on my phone. I found it invaluable when walking the Camino de Santiago last year. There are also some great websites out there that will let you download GPX files for hundreds or even thousands of walking routes, and thanks to the ubiquity of GPX you can then load these in pretty much any map app that you want.

There are other XML-based formats in this space, too. Garmin's Training Center XML (TCX) format is also aimed at recording physical training sessions such as running and cycling. It is similar to GPX but supports more activity-related data (heart rate, cadence, etc) out of the box. Keyhole Markup Language (KML) is a format developed for displaying geographical data in Google Earth (then known as Keyhole Earth Viewer) but is now supported on some other platforms too.

XMPP

XMPP (the Extensible Messaging and Presence Protocol), originally known as Jabber, is a communication protocol designed for instant messaging, amongst other things. As well as being open, it is also decentralised by design, in a similar vein to email - anyone can host their own XMPP server.

The open and decentralised nature of XMPP means that people can communicate even if they are signed up to different servers and use different clients - again, similar to email, but a world away from WhatsApp and other modern instant messaging platforms that fight as hard as they can to keep their users isolated from other platforms (though, ironically, WhatsApp actually uses XMPP internally). Like RSS, XMPP was also dealt a heavy blow in 2013, when Google announced it was moving away from XMPP for its own instant messaging service.

Today, XMPP is still used by many around the world to communicate, and is increasingly finding use in the "Internet of Things" world for machine-to-machine communication. But as an instant messaging protocol it pales in significance compared to WhatsApp and other corporate platforms. Interestingly, the Digital Markets Act in the EU requires certain large messaging platforms to become interoperable, and some are choosing to leverage XMPP for this purpose. However I have yet to see this spark a noticeable shift in the way people use it in practice.

OFX

OFX (Open Financial Exchange) is a standard for exchanging financial data and performing transactions. It allows financial and transaction data to be exchanged between institutions, or accessed by consumers, in a standardised way. It is apparently used by over 7,000 financial institutions.

For an individual, one of the most interesting use cases for OFX is getting their own financial data from their banks for use in personal accounting or budget management software, which often supports OFX imports. I understand that in the US this process can be entirely automated in many cases, by having your accounting software connect to your bank to download the OFX data. In Europe, the process is not quite as straightforward, as banks generally don't permit automated access like that, but many (though far from all) of them will allow you to manually download your account data in OFX format. You can then import that data into, for example, GnuCash or (with the help of external scripts) beancount or ledger.

XSLT

This is the language whose proposed removal from the HTML spec has given rise to the latest round of XML bashing and defending. Technically XSLT is language for describing transformations to apply to XML documents, so it is a bit different to the other formats discussed here (but XSLT is also, itself, based on XML). It's fair to say it is probably a lesser-known feature of many browsers. It has some interesting use cases, mainly to do with styling of XML documents so that a user can visit a .xml file directly in their browser and see the information presented in a nice human-readable way instead of raw XML.

Regulatory reporting

At least in Europe, XML is favoured by many regulators as a data reporting format.

XBRL

This is not one I have used personally, but XBRL (the eXtensible Business Reporting Language) is a standard way to describe and exchange certain "business information" - most commonly financial information, like the information you would find in a company's financial statements.

Companies in many jurisdictions are now required to tag their financial statements using inline XBRL (iXBRL). In the EU, this initiative is known as the European Single Electronic Format (ESEF). It is intended to increase corporate transparency and allow regulators, investors and other interested parties to access key business information in a harmonised manner.

EU financial regulation

EU law imposes reporting obligations on many participants in the financial markets, and this reporting must generally be done in XML, according to schemas published by the regulators. Examples of EU regulations which require XML-based reporting include:

• the Markets in Financial Instruments Regulation (MiFIR), which requires reporting of information about financial instruments to the Financial Instruments Reference Data System (FIRDS);
• the European Markets Infrastructure Regulation (EMIR), which requires reporting of derivatives to trade repositories;
• the Securities Financing Transactions Regulation (SFTR), which requires reporting of securities financing transactions to trade repositories;
• the Securitisation Regulation, which requires information about securitisations to be made available to regulators and certain others, in some cases via a securitisatio repository.

I am sure there are others, but those are some examples I have found. Of interest is that ESMA makes much of the FIRDS data available to the public, and that is also delivered in XML format.

Conclusion

The point of this post was really just to share some interesting stuff I've encountered over the years and not to get into a debate over the merits or future of XML. However, clearly the rumours of XML's demise have been wildly exaggerated. In some domains, such as regulatory reporting, it is very much going strong and in all likelihood its use will only continue to grow. In other areas, it continues to be used as the basis for widely used open standards, but these open standards may be less visible than they used to be. And in some cases the standards themselves are under threat and at risk of fading into irrelevance.

It's not so much the software that's the problem - most of the above formats can be handled using widely available open source software (or are simple enough that such software could be developed if there was a pressing need). But in order to stay relevant they need to continue to be used by content producers and gatekeepers. If news websites, bloggers and podcasters stop using RSS to syndicate their content, if Garmin and whoever else makes fitness trackers these days stop allowing GPX exports of activity data, if banks stop allowing OFX exports of financial data, etc, then these standards will die. And unfortunately many of those institutions may well decide that supporting open standards is not in their financial interests, unless there is a very clear consumer demand for them (or, in rare cases, they are compelled to support them by regulation).

People who like the idea of an open web should oppose this, and I think it's a mistake to focus on the specific format of these standards. It doesn't really matter that RSS is based on XML rather than JSON. What matters is that it exists, it is open and it is widely supported. In many areas, the realistic alternative to the open, widely-supported XML standard is not an open, widely-supported JSON standard - it is no open standard at all.

Some interesting uses of XML was published on 2025-08-19