Speaking of "correctness"... It seems to me people almost never mention that while schema verification can detect a lot of issues, in the end it cannot replace actual content validation. There are often arbitrarily complicated constraints on data that requires custom code to validate.

This is analogous to the ridiculous claim that type checking compilers can tell you whether the program is correct or not.

Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were often large and non-trivial to maintain. There were magic libraries in languages like Java and C# that let you map XML to objects using a million annotations, but they only supported a subset of XML and if your XML didn't fit that shoe you'd get 95% of the way and then realize that there was no way you'd get the last 5% in, and had to rewrite the whole thing with some awful streaming XML parser like SAX.

JSON, while not perfect, maps neatly onto data structures that nearly every language has: arrays, objects and dictionaries. That it why it got popular, and no other reason. Definitely not "fashion" or something as silly as that. Hundreds of thousands of developers had simply gotten extremely tired of spending 20% of their working lives producing and then parsing XML streams. It was terrible.

And don't even get me started on the endless meetings of people trying to design their XML schemas. Should this here thing be an attribute or a child element? Will we allow mixing different child elements in a list or will we add a level of indirection so the parser can be simpler? Everybody had a different idea about what was the most elegant and none of it mattered. JSON did for API design what Prettier did for the tabs vs spaces debate.

The browser supported XML as much as Javascript. Remember that the "X" in "AJAX" acronym stands for XML, as well as "XMLHttpRequest" which was originally intended to be used for fetching data on the fly in XML. It was later repurposed to grab JSON data.

Javascript was not a reason XML was abandoned. It was just that the developer community did not like XML at all (after trying to use it for a while).

As for whether the dev community was "right", it's hard to comment because the article you linked is heavy on the ranting but light on the contextual details. For example it admits that simpler formats like JSON might be appropriate where "small data transfers between cooperating services and scenarios where schema validation would be overkill". So are they talking about people storing "documents" and "files" in JSON form? I guess it happens, but is it really as common to use JSON as opposed to other formats like YAML (which is definitely not caused by Javascript in the browser winning)?

Personally I think XML was abandoned because inherent bad design (and maybe over-engineering). A simpler format with schema checking is probably more ideal IMHO.

Ergonomics of input are important because they increase chances of it being correct, and you can usually still keep it strict and semantic enough (eg. LaTeX is less layout-focused than Plain TeX)

Yes let's not even get started on implementations who do <something value="value"></something>

> XML is notoriously expensive to properly parse in many languages.

I'm glad this is the top comment. I have extensive experience in enterprise-y Java and XML and XML is anything but cheap. In fact, doing anything non-trivial with XML was regularly a memory and CPU bottleneck.

That's to say nothing of all the syntax decisions you have to make now. If you want to do infix math notation, you're going to be making a lot of choices operator precedence. The article is using a lot of simple functions to explain the domain, but we also have switch statements—how are those going to expressed? Ditto functions that don't have a common math notation, like stepwise multiply. All of these can be solved, but they also make your parser much more complicated and create a situation where you are likely to only have one implementation of it.

If you try to solve that by standardizing on prefix notations and parenthesis, well, now you have s-expressions (an option also discussed in the post).

That's what "cheap" means in this context: There's a library in every environment that can immediately parse it and mature tooling to query the document. Adding new ideas to your XML DSL does not at all increase the complexity of your parsing. That's really helpful on a small team! I agonized over the word "cheap" in the title and considered using something more obviously positive like "cost-effective" but I still think "cheap" is the right one. You're making a cost-cutting choice with the syntax, and that has expressiveness tradeoffs like OP notes, but it's a decision that is absolutely correct in many domains, especially one where you want people to be able to widely (and cheaply) build on the thing you're specifying.

> The more capabilities you add to a interchange format, the harder that format is to parse.

There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink.

There was a thread here the other day about using Sqlite as an interchange format to REDUCE complexity. Look, I love Sqlite, as an application specific data-store. But much like XML it has a ton of capabilities, which is good for a data-store, but awful for an interchange format with multiple producers/consumers with their own ideas.

CSV may be under-specified, but it remains popular largely due to its simplicity to produce/consume. Unfortunately, we're seeing people slowly ruin JSON by adding e.g. commands to the format, with others than using those "comments" to hold data (e.g. type information), which must be parsed. Which is a bad version of an XML Attribute.

Since Raku suports both OO and Functional coding styles, and has built in Grammars, it is very nice for DSLs.

What hurt XML was the ecosystem of overly complex shit that just sullied the whole space. Namespaces were a disaster, and when firms would layer many namespaces into one use it just turned it into a magnificent mess that became impossible to manually generate or verify. And then poorly thought out garbage specs like SOAP just made everyone want to toss all of it into the garbage bin, and XML became collateral damage of kickback against terrible standards.

  grammar InvoiceDSL {

    token TOP {
        ^ <invoice>+ % \n* $
    }

    token invoice {
        <header>
        \n
        <line>+
    }

    token header {
        'invoice' \h+ <id=string> \h+ 'for' \h+ <client=string>
    }

    token line {
        \h**4 <entry> \n?
    }

    token entry {
        | <item>
        | <tax>
        | <discount>
    }

    token item {
        'item' \h+ <desc=string> \h+ <price=num> \h+ 'x' \h+ <qty=int>
    }

    token tax {
        'tax' \h+ <percent=num> '%'
    }

    token discount {
        'discount' \h+ <percent=num> '%'
    }

    token string { \" <( <-["]>* )> \" }
    token num    { \d+ [ '.' \d+ ]? }
    token int    { \d+ }
  }

JSON just works. Every language worth giving a damn about has a half-decent parser, and the syntax is simple enough that you can write valid JSON by hand. You wouldn't hit the edgy edge cases or the need to use things like schemas until down the line, by which point you're already rolling with JSON.

XML doesn't "just work". There are like 4 decent libraries total, all extremely heavy, that have bindings in common languages, and the syntax is heavy and verbose. And by the time you could possibly get to "advanced features that make XML worth using", you've already bounced off the upfront cost of having to put up with XML.

Frontloading complexity ain't great for adoption - who would have thought.