I just had to comment on the irony of this comment being embedded in a document that is delivered via HTTP and very close to valid XML.
Even if XHTML died on the wayside, HTML is imho a stereotypical example where XML is a good fit. Most of the complexity has valid use cases, and it's mostly obvious what should be an attribute and what should be content of the tag. And at least in HTML 4 you even had a doctype tag filling the role of specifying the schema used. Of course SVG is a better showcase for some other aspects of XML, with every editor putting their own metadata in, nicely partitioned into separate namespaces.
In broad strokes, I suppose you're right to see the irony. Even with that, we need specific client applications (aka browsers) to translate that into something readable.
(X)HTML can be pretty readable, if it's formatted well. If it wasn't, JSX wouldn't be a thing.
I think it's not so much about readability but about complexity. XML is meant to represent complex data, like complex rich text or nested vector graphics. That makes XML complex, conceptually, visually, and in implementation. If you use it to represent something that could have been a csv you're going to have a bad time (as everyone had in the 90s).
> HTML is imho a stereotypical example where XML is a good fit
Indeed, this was what XML was created for. From W3C's XML specification:
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.
Honestly, what's absurd is GP comment's cluelessness.
I remember playing with an invoice data in XML sending it via email and opening it in a browser being beautifully shown in all it's visual glory using an XSLT directive in just one line at the top of the data file. Absolutely amazing. I wondered all the implications and applications of just transmitting data that knew how to present itself to the user
I have a project which can work on 3D objects imported from STL files. My file format has more metadata and much more detailed information w.r.t. a standard STL file, and all the data and the metadata can be written in a way which is both readable and modifiable by a human if needed be.
Having the same tags many times means the file can be nicely compressed, it's being XML means it can be verified independently with a schema (and the schema can be defined as a remote location over HTTP if needed be), too.
You can always store data more efficiently with binary formats, but XML DOM parsers allows to access arbitrary parts of the tree instantly, so working with it is both easy and fast at the same time.
Agreed. That and knowledge representation (ontologies) is another good use case for XML, since JSON can't natively represent attributes (has-a relationships).
I'm in a similar sphere with XML and ontological representation. I've inherited maintenance of an ontology (of sorts) that has been used in social sciences since the 1940s. Can I ask what domain you are in? How do you like to represent your ontologies? SKOS?
Even if XHTML died on the wayside, HTML is imho a stereotypical example where XML is a good fit. Most of the complexity has valid use cases, and it's mostly obvious what should be an attribute and what should be content of the tag. And at least in HTML 4 you even had a doctype tag filling the role of specifying the schema used. Of course SVG is a better showcase for some other aspects of XML, with every editor putting their own metadata in, nicely partitioned into separate namespaces.