Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

The JSON Schema organization is requesting feedback from users out there about the stability guarantees it should be enforcing on the next release of the specification.

If you feel you can contribute, please read https://github.com/orgs/json-schema-org/discussions/295 and share your thoughts.

The current options are:

- The specifications that have been published to date provide no stability guarantees, but we will be adding explicit guarantees with the next publication.

- Apply the stability guarantees starting with the most recent publication (draft 2020-12) so that the next publication contains no breaking changes.

I have been trying to get anyone to use it since I discovered FasterXML/Jackson could generate it.

I have not worked for an organization with public APIs. Not a single one of the APIs I work on is completely stable. Figuring out what our APIs do requires techniques from archeology, anthropology, and sociology.

Here's my gripe with jsonschema...

In most cases where I want to do some validation on JSON I find that I usually have a class/struct/object that represents the payload and I want to unpack JSON into it (or dump that class to JSON). Ultimately, there are already nice tools to do this (eg; marshmallow on the python side). So unless I'm crossing language boundaries writing a separate jsonschema and using that is more work and I have to keep it up to date.

And in the cases where I want to cross language boundaries at this point there's less and less of a compelling case to go with JSON and not eg; flatbuffers/protobuf/thrift/capnproto since you're writing a schema anyways.

Soon we'll have JSLT. JSON Query, JSON Pointer, JSON signatures etc are already there.

And I say that as a conscious XML user. We are going in circles. At least XML has comments.

Regarding explicit guarantees, I'd consider a "forward-compatible" way such that when - and if - a breaking change needs to be introduced, it's possible to automatically convert old JSON schemas into the new one. JSON Schema version which would select which processing to choose could be an option, but not sure if there couldn't be better.

As is often the case, good domain knowledge can help to choose which features are "real" and can stand and which are more doubtful and have a higher chance to fall out of favor later.