Parsing and walking a JSON structure is much easier and less ambiguous. It's often very clear how to represent/deserialize/serialize JSON (as-is).

The benefits of using schema are clear, you can add validation and semantics to parse (JSON) into a richer and more consistent data structure.

JSON-schema is in large parts a well designed and clear language that is meant to be read and written by humans. Compare that to DTD, XML schema.

I think in terms of raw functionality, there are very strong parallels. And even though I'm not an XML hater, I find JSON simply more pleasant to work with.

The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO.

Attributes are absolutely one of the reasons for XML's failure. They seem so innocuous, until you encounter a schema where the developer created:

  <Entity ID="12345" Type="Person">
    <Property Name="FirstName" Value="Harry" Type="String" />
    <Property Name="LastName" Value="Potter" Type="String" />
    <Property Name="DateOfBirth" Value="1/1/1980" Type="DateTime" />
  </Entity>

Nevermind if you've ever encountered XML with mixed namespaces. Then again, reading the article the bit at the end is exactly the same sort of nastiness.

I imagine if there was discipline around attributes being only used for meta-data and maybe explicit (de-normalized) references (which is arguably meta data, happy to discuss), then XML would be semantically richer by default. However like this we are left guessing the semantics if we encounter some XML.

Somewhat in contrast, HTML is generally, but not consistently, better at making this distinction, which enables clearer semantics around accessibility, HATEOAS and so on. Ironically we are kicking that value proposition into the can when driving web application rendering with JSON (like popular SPA frameworks do), so we have to re-invent meta data and communicate that with JSON-schema.

DTD however, let us not talk about that. Let us just forget it.

I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be very beautiful and simple.

Oh, and horrible DOM Apis ;). When working in semi-modern .NET parsing XML/JSON is super easy. Doing the same in JavaScript (out-of-the-box) is a drama.

I see this json schema thing also seems to use long intricate URLs that you can only copy-paste to identify things... at least in this day and age if one does ID with unwieldy blobs, it'd be good to at least use some hash to get the benefits of content addressing.

It even might not matter whether you parse it programmatically or not in some cases. Typically when looking at a given XML (or other data structure text representations) you can pattern match the semantics of what you see, but that is not always true, because everyone uses it in a different way, relying almost completely on schema and documentation to convey semantics, which in turn makes the format strictly inferior to JSON, which also doesn't have rich semantics but is simpler.

As a consequence, JSON in JavaScript is super easy. Using XML is medium-hard.

In .NET using XML or JSON is easy (not super easy).

In C++ using XML or JSON is medium-hard.

Do not know the state of the art for Go, Rust, Java, ...

As a consequence, JSON is - from a JavaScript developer perspective - the holy grail. From a .NET/Java/C++ developer perspective it is just another format.

In Java, there's the JAXB ”parser“ which translates an XML schema into (mostly) straightforward classes. Correct initial setup is the only hard part.

In XML you have to decide if you want DTD or schema enabled (which could provide default values, and could be a security risk) and where abs how you resolve the DTDs from etc. Do you resolve references? And many option options.

So JSON benefits not just from a simpler structure, but also from less optionality.

Basically, in a static typed language you decide for schema checking or not - like for Json -, serializing in structures or access in an API - like for Json.

It is just that JavaScript maps json directly in their dynamic object, array and native types. For xml that is an mismatch. For static languages both are an mismatch.

My understanding is that that's not the case. XML parsers are Pull or SAX based and it's weird as fuck.

You can abstract that out, but parser complexity isn't something to sneeze out. For one thing, parsing XML is notoriously dangerous - tons of vulns both at a design and memory management level.

What about:

- verbosity

- complexity of writing a parser

- complexity of dumping data

- DTDs

- data model which doesn't map directly to a scalar/array/associative array

... and so many other XML features that are either useless or painful just for RPC.

Parser writing and dumping of data is equally complex for both JSON and XML. The only difference is that in JavaScript JSON is so much simpler due to the dynamic nature of the language and the core library. Out-of-the-box XML parsing in JS is just stone-age. Compare that to .NET System.Xml.XDocument and Newtonsoft.Json, then you can see the simplicity how an API could look (in a static type system ;))

No one needs DTDs. No modern contract is every spec'ed in DTDs. XSDSchema has superseeded that 20 years ago. The only issue with it, is that some entry level tutorials are still mentioning it.

The data model mapping depends a lot on the target language. In JavaScript XML is not a match but JSON is. Working with JSON in C++ is equally stupid as working with XML is.

The only stupid feature in XML is namespaces. Without that, it is simple.

Strongly disagree. Sure, you can make XML which is easy to parse, but parsing arbitrary XML is hard. Namespaces (and their short prefixes), and custom entities are something that fly in my face any time I use XML but simply do not exist in JSON.

Dumping is usually OK but again, I've seen XML libraries replace short namespace prefixes with full URLs when dumping, making simple documents unreadable.

JSON however is supported in the language spec

XSD = JSONSchema

WSDL = OpenAPI

SOAP = there really isn't a direct analog maybe ""REST""

---

In any case, try creating a SOAP service and WSDL. It's literally so complex that most tutorials have to rely on an IDE to do it. Humans are simply not equal to the task.

Yes, the purpose is similar, but only those who have never used them would think they're the same.

I'd say it was the worst dev experience of my whole career, and I fought with objective-c and app stores.

Tried some ObjC development early on the iPhone. Gave up quickly.

I agree that SOAP looks like a mess. But given the right tools, it honestly just works. Never had a single issue with these APIs apart being stuck in .NET Framework land.

SOAP isn't some nice standardized language-agnostic API layer.

SOAP is .NET/Visual Studio RPC. (Not technically, but in practice, due to its complexity.)

And hey, great for you. But a lot of people want APIs to be broadly compatible.

What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?

No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology.

So it seems that people who use MS ecosystem like SOAP ... while almost everyone else who tried it calls is over-complicated, incomprehensible and "worst dev experience of my whole career"

Again, gotta call BS here. My early career was 100% SOAP and related WS-* technologies. And it was all in Java, Apache Axis and friends. Wildly popular at the time. Give it your WSDL, out pops a nice Java client. People didn’t like it not because it was difficult to use outside of the Microsoft ecosystem, they didn’t like it because it was the concepts were difficult to understand and there were many complicated technologies piggybacking off of it. It was hard to debug issues, Visual Studio or not. If you had to do something that a generated client could do, it was difficult, Visual Studio or not.

Which I would agree is most of the time - but then it doesn't and you have to try and work out what is going wrong from reams of impenetrable generated WSDL. Which is fun.

Would imagine, with the right tooling and TypeScript it wouldn't have been that bad.

I do believe there has to be some sort of common schema format, but I have no idea how this problem could be solved cleanly in practice, even after 20 years.

I really no need see the need to use a schema for JSON. The only thing it has going for it compared to SOAP/XML is the fact the it faster parsing and that it has no schema.

    {
      "type": "object",
      "properties": {
        "foo": { "type": "string" }
      }
    }

OpenAPI...I personally don't use this as much but yes there are hundred tutorials on creating definitions by hand.

At my company, we found that the auto-OAS generation tools were too brittle and didn't communicate enough information, so we actually do write our own OAS and run automation to make sure it's accurate.

That's also how our architects communicate with developers about an endpoint - create an OAS for it.

I found all OAS spec authoring tooling to be useless toys when building non-trivial real world specs.

The depths of depravity I’m forced to is as follows:

1. Data model in SparxEA because it’s the tool we have in the depths of govt. Generate XSD from tool

2. XSLT to turn the XSD into matching JSON Schema because I’m old and can still remember how.

3. Hand write the OAS with $ref into JSON schema as appropriate

4. Curate sample payloads to be educationally useful

5. Generate CURL and various code samples

6. Bundle it all into approx 80k lines of machine written wondrousness -

7. ReDoc and Mkdocs to build static website with more documentation

All the work is at data modeling, OAS sample curation and mkdocs documentation

Things I wish JSON and Schema had:

1. An equivalent of xs:decimal that JS would use number & double are just plain useless in real world commerce with dollars & cents and bulk item pricing with 3&4 decimal places

2. Has taken the time to fix rfc3399 and give Dates a Timezone suffix. Too many languages Marshall a date into datetime. How many bugs have I seen where it’s broken in the morning and works in the afternoon because the damn server is running in AU with UTC Timezone and we’re in NZ

Of course.

> At least with XML and XSD you have proper auto complete.

Tooling for OpenAPI exist. In VS Code for example.

> I really no need see the need to use a schema for JSON

Don't you see the need for precise machine readable description of JSON input and output for a REST API for validation? This is OpenAPI..

Too late for that

> We should consider […] restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies.

Too late for that and unenforceable

It's just riddled with features.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

[...] X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of “Voodoo Ergonomics” have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards. [...]

X: The First Fully Modular Software Disaster

>X-Windows started out as one man’s project in an office on the fifth floor of MIT’s Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The two computers might be VAXes or Suns, or one of each, as long as the computers were networked together and each implemented the X protocol.

[...]

X-Windows: …A mistake carried out to perfection. X-Windows: …Dissatisfaction guaranteed. X-Windows: …Don’t get frustrated without it. X-Windows: …Even your dog won’t like it. X-Windows: …Flaky and built to stay that way. X-Windows: …Complex non-solutions to simple non-problems. X-Windows: …Flawed beyond belief. X-Windows: …Form follows malfunction. X-Windows: …Garbage at your fingertips. X-Windows: …Ignorance is our most important resource. X-Windows: …It could be worse, but it’ll take time. X-Windows: …It could happen to you. X-Windows: …Japan’s secret weapon. X-Windows: …Let it get in your way. X-Windows: …Live the nightmare. X-Windows: …More than enough rope. X-Windows: …Never had it, never will. X-Windows: …No hardware is safe. X-Windows: …Power tools for power fools. X-Windows: …Putting new limits on productivity. X-Windows: …Simplicity made complex. X-Windows: …The cutting edge of obsolescence. X-Windows: …The art of incompetence. X-Windows: …The defacto substandard. X-Windows: …The first fully modular software disaster. X-Windows: …The joke that kills. X-Windows: …The problem for your problem. X-Windows: …There’s got to be a better way. X-Windows: …Warn your friends about it. X-Windows: …You’d better sit down. X-Windows: …You’ll envy the dead.

"Well, it's high noon somewhere in the world."

Get off my lawn!