JSON Schema: Define upgrade/downgrade language agnostic declarative transformation rules for all JSON Schema dialects

[benjagm]

Project title

Define upgrade/downgrade language agnostic declarative transformation rules for all JSON Schema dialects.

Brief Description

The Alterschema project defines a set of JSON-based formal transformation rules for upgrading schemas between Draft 4 and 2020-12, and all dialects in between. These rules are defined using JSON Schema and JSON-e and live within the Alterschema project.

We would like to revise these rules, extend them to support every dialect of JSON Schema (potentially including OpenAPI's old dialects too), and attempt to support some level of downgrading.

Instead of having these rules on the Alterschema repository, we want to have them on the JSON Schema organization for everybody to consume, including Alterschema itself.

Revising the rule format should consider currently unresolved edge cases in Alterschema like tweaking references after a subschema is moved.

Expected Outcomes

A new repository in the JSON Schema organization with upgrade/downgrade rules defined using JSON.

Skills Required

Understanding of various dialects of JSON Schema and their differences.

Mentors

@jviotti

Expected Difficulty

Medium

Expected Time Commitment

350 hours

Related project in the JSON Schema org: https://github.com/json-schema-org/community/issues/599

[MeastroZI]

@benjagm Sir, as your title states "language agnostic," does it mean we can't even use JavaScript? If yes, then JSON-e is not appropriate for handling nested objects, as JSON Schemas is. So is there is freedom to use any alternative of JSON-e ? If I have misunderstood it then please guide me on the right track.

[jviotti]

@MeastroZI

as your title states "language agnostic," does it mean we can't even use JavaScript?

It means that the rule definitions must be language agnostic, so that more than one project, in arbitrary languages, can implement them.

If yes, then JSON-e is not appropriate for handling nested objects, as JSON Schemas is

Not sure what you mean here. Can you provide an example? Alterschema is currently implemented in JSON-e and handles almost every case, with some obscure outliers aside

So is there is freedom to use any alternative of JSON-e ? If I have misunderstood it then please guide me on the right track.

Yes, I think leaving JSON-e behind for this is a good idea, but whatever we replace it with should be JSON too. Coming back to some of the edge cases I'm currently facing with Alterschema, the problem is that JSON-e will do generic templating, but you cannot understand what the rule actually did. It carries very little semantics.

I'm thinking we can define a JSON DSL (maybe similar to JSON Patch?) that supports certain base transformations that carry the necessary semantics to address the final problems we are seeing

[benjagm]

Thanks for your interest! Lets continue the discussion in this issue inside the JSON Schema project: https://github.com/json-schema-org/community/issues/599

[benjagm]

Thanks a lot for joining JSON Schema org for this edition of GSoC!!

Qualification tasks will be published as comments in the project ideas by Thursday/Friday of this week. In addition I'd like to invite you to a office hours session this thursday 18:30 UTC where we'll present the ideas and the relevant date to consider at this stage of the program.

Please use this link to join the session: 🌐 Zoom 📅 20124-02-29 18:30 UTC

See you there!

[benjagm]

🚩 IMPORTANT INSTRUCTIONS REGARDING HOW AND WHERE TO SUBMIT YOU APPLICATION 🚩

Please join this discussion in JSON Schema slack to get the last details very important details on how to better submit your application to JSON Schema.

See communication here.