What 31 public XML endpoints reveal about XML in 2026

XML is often discussed as if it were one format. The 31 live endpoints in XMLDir's public directory show the opposite: XML is the transport shared by many unrelated vocabularies, each with its own root elements, namespaces, date rules, extension points, and operational failure modes.

This is a small curated sample, not a census of the web. Every endpoint was fetched when it entered the directory, and the sample is intentionally spread across standards bodies, public agencies, registries, scientific publishers, media feeds, sitemaps, and transit data. That makes it useful for observing variety, not market share.

The sample is broad before it is large

• 7 government endpoints, from public records and open-data services.
• 6 standards endpoints, including schemas and registries maintained as XML.
• 6 media feeds, where RSS and Atom remain practical distribution contracts.
• 4 package-registry endpoints and 4 science endpoints.
• 3 sitemaps and 1 transit endpoint, retained as concrete operational examples.

The root element is a clue, not an identity

A root such as urlset, feed, schema, or project often narrows the answer immediately. Generic names do not. Both DocBook and JATS can use article, while Response means little without the SAML protocol namespace. A reliable detector combines the local root name with every namespace declared on that root and treats ambiguous namespace-free documents cautiously.

File extensions add even less certainty. .xml can hold a Maven project model, a SAML response, an XSD, a JATS article, or test results. .plist may not be XML at all, and compressed MusicXML is a ZIP package despite ending in .mxl.

Namespaces are operational data

The directory repeatedly encounters documents where a namespace URI is the version boundary: SOAP 1.1 versus 1.2, XLIFF 1.2 versus 2.x, and SAML protocol elements versus assertion elements. Prefixes can change freely; the URI cannot. That is why stripping an apparently redundant xmlns declaration can turn valid XML into a document no domain tool recognizes.

The opposite case matters too. RSS 2.0, JATS, JUnit XML, property lists, and MusicXML commonly use namespace-free core vocabularies. A parser that assumes every serious XML format has a default namespace will mishandle a large and useful part of the ecosystem.

Well-formed is the beginning of validation

Every endpoint first has to survive XML parsing, but the expensive defects live one layer higher: a sitemap with no URLs, an Atom entry with the wrong date form, a SOAP Header after Body, an XSD attribute carrying element-only occurrence rules, or a SAML assertion accepted without checking audience and signature context.

The practical pipeline is therefore staged: parse safely, identify the vocabulary, apply its schema or processing model, then run business rules that the schema cannot express. Keeping those verdicts separate makes failures explainable and prevents a green well-formedness check from being mistaken for domain conformance.

What we will measure next

The next useful dataset is longitudinal rather than merely larger: how often roots, namespaces, node paths, and response availability change across scheduled fetches. That will distinguish stable public contracts from endpoints that only look stable in a one-time sample.

Until then, the honest conclusion is modest: public XML is not one legacy island. It is a set of durable, specialized contracts, and robust tooling starts by preserving the differences between them.