XML is great for its intended purpose - structured text with metadata.

For other purposes like configuration files or rpc, the element/attribute distinction is superfluous and just lead to overly verbose syntax.

Unfortunately the hype cycle is such that when a technology becomes fashionable it becomes used even in contexts where it is not appropriate. This in turn leads to a backlash against the overall technology, not just against inappropriate use of it.

XML is awful for structured text with metadata. Half of the time you don't know whether your object properties were -or should be- stored as element attributes, element children or a CDATA block when trying to access it programmatically.

Defining a sane schema fit for all the places and use cases where it will be needed is an exercise in frustration. Lightweight markup won for structured text because it is simple to use, and you can expand it in a piecemeal fashion as needed. See Worse-is-better and the adoption of the C language for how this happens.

This happens even for well-designed lightweight markup; everybody prefers Markdown over asciidoc because you only need to learn like 5 syntax elements to get it up and running, even if it forces you to to add by hand later all the functions that were already available in asciidoc.

Since you talk about objects with properties, I assume you are thinking about serializing an object graph to XML. I agree the element/attribute distinction and mixed content is not very useful in this context. JSON or similar is fine for such data.

Structured text with metadata is something like this:

    <b>Hello, <a href="foo.org">world</a>!</b>

The element/attribute distinction and mixed content is useful here.

Btw. CData-blocks are purely an escape mechanism on the syntactic level. It should be completely transparent on the application level (e.g. like backslash escapes in a JSON string).

One of the problems that XML aims to solve is that you can get two XML documents and combine elements of them into a third one, maintaining the right semantics, even if each of the documents use the `<foo>` tag to mean different things. It accomplishes this with namespacing.

In my experience, it's a headache to handle namespaces in XML, e.g. when trying to refer to tag names in an XPath query.

That is one example of how XML goes beyond S-expressions. I still don't think it's a particularly hard problem.

There's no reason why any of that couldn't be replicated with JSON, YAML or even with S-expressions.

To play the devil's advocate, one of the nice features of XML is schemas.

The reason why complex formats with validation etc. don't really work out is that they are most often used for data in transit as opposed to data at rest. The correct format for typed data at rest that conforms to a schema is a SQL database and that won't change any time soon. If you're working with data in transit, schemas, validation etc. are more trouble than they're worth.

There's no reason why it couldn't be replicated, but it isn't - at least, not in any way with broad traction. It's not useful to compare something that could exist but doesn't with something that not only exists but is universal in its ecosystem. That universality is a feature in itself.