There are more ways to type (at schema and inline) and more types (see the common XSD types) available OOB in XML than JSON could ever have. Then we can introduce custom types. JSON looks rather impoverished in comparison.

Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality.

Admittedly, XML isn't the most pleasant syntax to interact with by hand.

XML syntax is fine so long as you're using a proper IDE. I manage a team of reporting analysts and all of them come from Business Analyst or Accountancy backgrounds; they write and maintain XSLT transforms just fine, once they spend a day or two getting used to IntelliJ IDEA.

XML was a great idea. At some point in the early naughts, however, XML-abuse became rampant-- too many crappy tools, too many half-assed attempts at putting square pegs into round holes. It didn't help that XML got inextricably associated with those horrible over-complicated ws-* standards that ended up sending Russian novel-sized "hello world" information exchanges.

The main idea, however, was wonderful. An information exchange format (xml itself), a way to define schemas (xsd), a transformation language (xslt), and stylesheets (xsl?). I kind of miss it.

XSL (Extensible Stylesheet Language) the stylesheet part, it included XSLT (transform), XPath, and XSL-FO (XSL Format Objects).

XSLT and XPath each went on to great solo careers, XSL-FO kind of fizzled when XML+XSL failed to displace HTML+CSS.

XSL:FO is great for turning into PDFs though.

There's also XQuery for transformations and XSD/RelaxNG for schemas, the whole combination of XML database, WYSIWYG (via XSLT) XML editor and output transformations is very powerful, every journal we published and every site we ran at the British Medical Journal was generated that way.

I miss XSLT every time I see megabytes of JavaScript converting some JSON into a soup of HTML to display in browsers. A bunch of JavaScript with a bunch of overwrought "components" is serving as a very complicated templating system.

A lot of really stupid JavaScript could be done fairly easily with XSLT natively inside a browser engine. An XML document can point to its own XSL(s) so get rendered to the appropriate delivery format or just used directly as data.

I don't miss it. I had several projects where it seemed like a good idea. I pushed it as a good idea. I really wanted it to work. Some developers (usually the sharper bulbs) got it. A lot of developers really struggled with it. Especially the folks who were 'front end' developers. Even in the 2000's, when everything was trying to go XML, staffing those roles was hard.

Tooling was XSLT's Achilles heel. Too many tools had no or poor XSLT support. What's confusing to me is a lot of the JavaScript templating today has equally bad tooling yet everyone's in love with it.

Doesn't that suggest that tooling wasn't the issue after all?

The lack of tooling for XSLT and modern JavaScript stuff are on different sides of the adoption curve. XSLT lacked tooling on the upside of the curve so it never hit critical mass. Its other problems could have been solved had it hit critical mass and seen wider adoption.

> Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality.

No, I'm pretty sure that if they have only used XML syntax as a data rep and not XML-associated tooling like XSD, they are quite aware that when thet say they hate XML they are talking about syntax.

OTOH. I am surprised at the number of people that seem to thing “has a schema language that can be used to specify structure beyond just the basic raw language” distinguishes XML from other data representation languages.

Or, more generally, the way that “if you don’t like XML, maybe your problem is you aren’t using enough of it” has become an edgy contrarian position rather than steretypical establishment enterprise consultant thing it was 15 or so years ago.

JSON-LD can express any RDF datatype, and some XSD types (though not all) have standardized matches in RDF.

The quotes in XML don't make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. XML schemas will give you all the type information and automatic validation you can swallow. Typing in XML is far richer than in JSON. There's even a date type!

You mean an .xsd?

JSON has .avro, I thought.

It's all data. Validation logic is sold separately.

> The quotes in XML don’t make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison.

JSON, like XML, has several schema languages, which have widely-available libraries for generating host language typings, validation, etc.

> Typing in XML is far richer than in JSON. There’s even a date type!

JSON Type Definition has timestamp, JSON Schema has date, date-time, time, and duration.

The nice thing about XML being an extensible markup language is that schemas (and metadata like xsi:type) could be easily written inline, making the document fully self-contained.

I haven't personally tried such a stunt, but I'd bet it's possible to do that with JSON Schema, too, if the schema resolver tolerates the same self-references style in `$schema`. My experience with the tooling is "lol, yeah right" but shrug seems reasonable

    {
      "$schema": "#/$theSchema",
      "$theSchema": {
        "$schema": "https://json-schema.org/draft/2020-12/schema",
        "$id": "MySchema",
        "type": "object",
        "properties": {
          "productId": {
            "description": "The unique identifier for a product",
            "type": "integer"
          },
          "productName": {
            "description": "Name of the product",
            "type": "string"
          },
          "price": {
            "description": "The price of the product",
            "type": "number",
            "exclusiveMinimum": 0
          }
        }
      },
      "productId": 1,
      "productName": "An ice sculpture",
      "price": 12.50
    }

JSON Schemas exist too. The most common being the eponymously named type: https://json-schema.org/

I've seen JSON schemas describe things like date types and plenty more. If you are including schema metadata alongside XML, then for a fair fight you can include JSON schemas, too.

You've got to learn XML and XSD first, then you'll see that's not what you're looking at at all.