JSON Schema is an unofficial spec with a bunch of competitors and multiple versions, not all of which are compatible. I don't think you can compare it to XML schema validation.

I'm also not so sure about JSON being easier to map to common data structures. The lack of order guarantees within objects makes things like ordered maps quite annoying (you need to either use an array of entries with key and value, or an index within the mapped objects).

"Structured" in this case refers to being able to be directly mapped to a data structure. Think protobuf and other similar transport mechanisms. The recipient knows what structure to expect because it's not a valid XML document if it's breaking those constraints.

JSON is not, it is closer to the PHP, JS, etc "object" type, which is an ephemeral object with arbitrary member associations.

And, to be clear, this is not a value judgement. They just excel in different fields. XML tends to be easier for strongly and strictly typed languages such as C/C++, C#, Java, etc where you can use the schema to generate your structs automatically. Vanilla JSON is easier for higher level languages that don't require you to manually create a mapping/validation level. JSON Schema tries to bridge that gap to a degree, but isn't built into the standard and isn't even universal.

But, ultimately, both are perfectly sufficient for either use case. It just depends on how much massaging you want to do to make them work.

JSON Schema is largely an answer to people seeking that type of built-in validation. As I'm not a huge proponent for either (a tool is a tool and you work with it in its ecosystem), I don't have personal feelings on it's adequacy.

But, I would suspect, proponents of XML would still point to it's deeper typing system, document structure (especially the hierarchical features of it), and extremely mature ecosystem + tooling (such as XSLTs) as reasons to prefer it over JSON w/ JSON Schema.

> I just hear my coworkers always lambasting that API provider for their usage of XML

I hear this too, but often when I ask why people say things like that, it's either because XML is "outdated" or because they don't like it.

It's like programs written in C or C++: very few large projects chose those languages nowadays, often for good reasons, so the projects written in those languages are usually 10 to 20 years old. Age comes with a lot of legacy cruft and obscure behaviour, but that's not the fault of those languages per se. Or for people blasting banks for using COBOL, even though COBOL is a perfectly fine high-performance language for the niches bank mainframes serve.

I don't think that's a fair assessment. Plenty of great technologies died out for many reasons unrelated to its effectiveness.

JSON Schema has existed for maybe 6 years in theory, in practice a few years.

As for DTD: https://en.wikipedia.org/wiki/Document_type_definition

Basically it tells the system what elements are allowed in which places and what attributes they can contain.

    <!ELEMENT html (head, body)>

It was kinda-sorta eventually superseded by XML Schema that could also define what KIND of data the attributes could contain, but did exist at the top of XML/HTML/SGML documents for years.