[justincormack]

databases are not structured documents, you can export them eg in JSON perfectly well. Or for that matter in SQL as is the usual practise. Marked up structured text is a different matter, XML still has a use case there.

[patrickg]

I was a bit unclear. When I get database dumps, I get them as Excel files or as an XML document.

Most of the times the documents I get are hierarchically structured.

Yes, JSON could be fine as well. But it simply lacks a standard toolchain which XSLT ans its ilk proides.

I am not trying to defend XML in any way. I just want to say the two things:

a) my customers never deal with JSON, but often with XML, so JSON (and other formats) are not an issue for me b) There is a very nice toolchain for XML, including formatters, tranformation tools, database publishing tools (my very own: https://speedata.github.io/publisher/index.html) and many others. I have not found such a toolchain for other formats.

[justincormack]

But XML does not map well to a database dump. A database is a set of sets of tuples. It is not generically hierarchical. It maps to a set of csv files say, as a transfer medium, but it is designed to be manipulated through relational calculus, which is not easily mapped to xslt.

You are using tools not because they map well to the problem space, but because they are the tools you have, which your customers want, and which you are familiar with, but that does not mean they are actually mapping well to the domain.

[patrickg]

Actually the XML part is the one that maps best to the problem space. I deal with structured documents (such as part/title/paragraph ... or product group/product/components). The database part (usually Excel sheets or SQL based stores) are the ones that are "insufficient".