> I think JSON Schema could have been a bit simpler, but it's still nowhere near to making the same mistakes as XML Schema.

Agree with every single one of your points, and this in particular. Thankfully, there are some heroes out there developing excellent tooling to make working with JSON schema easier. I've been making good use of Ajv[1], and highly recommend it to anyone having to deal with JSON payloads and schemas in a javascript environment. (I'm not affiliated with Ajv in any way, just happy with it.)

Working without a schema is much faster when getting started, obviously, but once things solidify in my experience a schema will help more than it costs and excellent tooling goes a long way in easing that transition from schema-less POCs to stable high quality implementations.

[1]: https://ajv.js.org

I used to resent the changes between the draft JSONSchema, but on reflection, almost all of them have been, IMO, extremely well chosen.

> Developers don't like complexity.

Judging by the code that is in front of me right now, I'm pretty sure they really do like it... or at least make lots of it.

They like to produce complexity, else they get bored while writing the code. But they don't like OTHER developer's complexity.

There’s a crude expression about smells and feces that applies here.

I used to struggle to understand why other people didn’t like using all the clever abstractions I came up with. I felt unappreciated and thought I needed to learn how to communicate better. It turns out I was communicating just fine. What I needed to learn was how to accept feedback.

"If I had more time I would have written a shorter letter" (Pascal, apparently).

Yeah they (including younger me) loved abstractions and complexity I wrote or I read about.

But it’s complex and difficult to grasp, so it’s not fun when you have to get into someone else’s mind, or even to get back into your own thinking after period of a sense of that project/architecture

Most new software devs go through that phase. A few decades ago, it was about the Gang of 4 design patterns. We were all reading that book and then looking for every possible place we could implement those patterns, even when they made absolutely no sense.

I'm so sorry for the teams I worked with in those days. The worse is I felt the folks around me were worse devs for not doing the same. It's so embarassing in hindsight.

The rule is "K.I.S.S (and add more RAM !!!)"

Strongly agree - I've worked with ONC RPC, CORBA, SOAP, XML & XSD, XSLT etc. and I much prefer the relatively straightforward nature of JSON and JSON Schema. Yes it's not perfect - but for me it is more than good enough.

Edit: Of course, there is no direct equivalent of XSLT in the JSON world - which pretty much counts as a feature to me.

One thing I am wondering is whether the protobuf folks have a better development environment overall, or a worse one. Is the schema-to-self-validating-serialization-code approach going to win just as JSON won over XML?

This is what I was thinking, but no, skeptical. Protobufs are far more efficient, but dump the human readability for the data transfer, and that is where the logging and debugging happen quite a bit.

As to code generation, if you use someone’s package for confirm_my_schema(thisjson) isn’t that basically code generation just moved somewhere else?

not all jsonschema validators are codegen/macros, so some of them are relatively unperformant and come with a lot of code baggage.

Nor XPath.

I think XPath is actually one of the nicer bits of the XML universe - there is a JSON equivalent in JSONPath that I have used a bit.

This. Back in the XML days, I had to spend way to long reading XSLT and WSDL specs just to do basic things.

JSON Schema takes 15 minutes to learn and it's a heck of a lot better than writing my own validator.

I remember I was enjoying XSLT; I used it to create templates and, in the end, valid XHTML pages. I thought that's the future.

At some point I made a news-articles site and I took that approach rather than databases: the owner would write XML files for each article that would be pretty simple: e.g. with tags like `title`, `image` (left, right, hero)`, some asides and some basic formatting for the body of the article, and XSLT, templates and CSS would make it a proper page. All the magic happened in the browser. I still think that's pretty cool.

That's pretty much what it was designed to do. You could push it pretty far too. Relational databases at the time all implemented XML types, so you could have XML all the way down, and XSLT is how you'd go from point A to point B.

But in the end, simpler alternatives prevailed.

It is a functional language, and the cool kids are really into those.

So what makes JSON Schema better is that nobody will "build an enormous ecosystem of tools on top" of it?

It depends the (complexity of the) JSON schema to mainpulate.

You don't need to?

"[humans] don't like complexity"

> Developers don't like complexity.

This may be true, but they also can't resist it's temptation.

As long as we build tools that are composable, developers will continue to build complexity on top of them. I fear that json's fate is sealed.