Dropping support for older JSON Schema spec versions (drafts)

[gregsdennis]

I've started a discussion amongst the JSON Schema team (you're welcome to weigh in as well) around deprecation of older versions of the specification.

The logic is that by only supporting a couple of the latest versions in libraries, users (like you) will be urged to update their schemas to the newer versions in order to keep upgrading the library.

I would like to implement this in JsonSchema.Net, supporting drafts 7 and 2020-12 since these are the most likely candidates for long-term support (LTS).

What are your thoughts?

[abrousseau001]

Good morning @gregsdennis. I have been using your tool for an API that I am currently working on, mostly the validation of a JSON from an outside service. I think that supporting later drafts is a good thing and will help ensure that your tool isn't pulled too many ways. Maybe drop back to draft 6 as there are plenty of tools out there that haven't been updated some of the newer draft specifications and in industries like government it takes a while to move towards anything modern (I am speaking from experience...).

[gregsdennis]

@abrousseau001 I currently only support as far back as draft 6. When I was writing this (as a replacement for Manatee.Json) I opted not to support draft 4 since it was not compatible with later drafts. Draft 6 is a subset of draft 7, though, and fully compatible.

[gregsdennis]

There are some futher proposals in the works to move JSON Schema toward more of a "living spec" release style. If we do move to something like that, this library will major rev when the next version is released and drop previous "draft" versions. I'll keep a tag for this major version so that I can create bug fixes if needed.

[abrousseau001]

I really appreciate that @gregdennis. I would rather have a set of specifications that are changes over years rather than a living specification for JSON schema, but c'est la vie. Bleeding edge changes are difficult for certain industries that are notorious for already being behind. JSON is a great replacement for some of the things that used to be done exclusively in XML, but a spec that isn't constantly changing. Adam

…

On Thu, Sep 8, 2022, 6:35 PM Greg Dennis ***@***.***> wrote: There are some futher proposals in the works to move JSON Schema toward more of a "living spec" release style. If we do move to something like that, this library will major rev when the next version is released and drop previous "draft" versions. I'll keep a tag for this major version so that I can create bug fixes if needed. — Reply to this email directly, view it on GitHub <#310 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2BMTIG6IMFXZLCBST6D4TV5JS4VANCNFSM547KBSUA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gregsdennis]

It would be changing/evolving, but with a commitment to stability. If you like you can read about the proposal here: https://github.com/orgs/json-schema-org/discussions/234

[SGStino]

It seems I've just ran into this issue with #497, meaning any interaction with OpenAPI schemas would be fully out of scope of this library if it keeps moving forward only?

In an ideal world, kubernetes would be on OpenAPI V3.1, using JSON Schema 2020-12, but as of today, this is not the case, as V3 just barely made it into GA in kubernetes 1.27:
Kubernetes 1.27: Server Side Field Validation and OpenAPI V3 move to GA

That would mean we'd have to use json-evertying-but-something-else for schema validation in kubernetes related use-cases 😢?

[gregsdennis]

@SGStino please join me in slack. I may have an upcoming solution for you.

[mdekrey]

I found this project while working on an OpenAPI project at PrincipleStudios/principle-studios-openapi-generators. Unfortunately, as the other folks above, we also need to support a variety of versions: we'll want to consume API documents from external providers, so we won't be able to maintain all of them ourselves.

While I don't think that these libraries should need to support older versions directly, I would hope that older spec versions could be supported by other contributors or within the projects that need them. If some framework was put in place for project consumers to override the dialect (setting all custom vocabulary and overriding keywords) on a per-schema basis, I'd be much more comfortable: according to the current JSON Schema specifications, the meta-schema can be specified using the $schema when referencing external documents.

Such a framework could allow for publishing of "vocabulary" libraries that support older versions but can otherwise be mostly for archival purposes (allowing this project to keep looking forward!), but would also help significantly for supporting OpenAPI 3.0 and earlier.

[SGStino]

If this is anywhere near complete, the conversion between the two is something along the lines of:
https://gist.github.com/SGStino/9ebc264211adcb673edb2d5a7cf03776

I'm not following any references, the whole schema needs to be a single document, since my use case was Kubernetes CRD related.

[gregsdennis]

Since OpenAPI has entered this conversation, I feel it's necessary to mention another project of mine: Graeae.

Right now it's just OpenAPI document models (basically a replacement for OpenAPI.Net), but it's built on top of JsonSchema.Net. OpenAPI v3.0.x and v3.1 are both supported. I'm planning on adding some code generation next.

[gregsdennis]

I think the direction forward for this is to include previous-draft compatibility extension libs.

The main library will support the JSON Schema stable spec, and the satellite libs will add draft support.