JSON Schema Draft07 ->Draft2019

[DaTebe]

Hi everyone,

Problem Statement 🛑

1. I've used the code example, which works as expected. But if I use migrate.draft2019 from your example, no $schema is set. Is this expected behavior?

2. Another problem would be, that I need to migrate a lot of draft07 to at least draft2019. But I guess your are only handling draft-04 to newer ones?

What I have tried 🛠

1. used ajv-cli migrate
2. wrote own nodejs code using your json-schema-migrate.

Behavior

• No changes in $id fields (e.g. removing # and /).
• No update of $schema field.

Wishes 🎁

• migrate from draft07 to draft2019

I'm not an JSON Schema expert, so I'm really not sure if this all is expected behavior or not.

Kind regards,
Daniel

[epoberezkin]

I've used the code example, which works as expected. But if I use migrate.draft2019 from your example, no $schema is set. Is this expected behavior?

Not sure I understand... The code only sets $schema if it's draft4 or if it's not set, otherwise it would be left as is.

See https://github.com/ajv-validator/json-schema-migrate/blob/master/src/index.ts#L83

I need to migrate a lot of draft07 to at least draft2019. But I guess your are only handling draft-04 to newer ones?

yes. I did think about implementing the migration matrix, but with the addition of 2020-12 it becomes much more code, maybe there is some smarter way to define this transformation declaratively, rather than further complicating the code.

It makes sense to support:

draft4 -> 7, 2019, 2020 // this is what is supported now
draft6 -> 7, 2019, 2020
draft7 -> 2019, 2020
draft2019-09 -> 2020

Happy to support the implementation

ajv-cli would then have to support --from-spec parameter

and while you are at it, you could throw in:

JTD -> 7, 2019, 2020 // always possible, with or without discriminator keyword
4, 6, 7, 2019, 2020 -> JTD // sometimes possible, for simple schemas

[DaTebe]

First Part

Not sure I understand... The code only sets $schema if it's draft4 or if it's not set, otherwise it would be left as is.

Hi, it seems that I'm just a little bit confused because the tool only goes up from draft04. So if I run:

const migrate = require("json-schema-migrate");

const schema = {
  id: "my-schema",
  minimum: 1,
  exclusiveMinimum: true,
};

migrate.draft7(schema);

The schema variable contains {$id: 'my-schema', exclusiveMinimum: 1, $schema: 'http://json-schema.org/draft-07/schema'}. That is what I assume.

If I run migrate.draft2019(schema), the result is {$id: 'my-schema', exclusiveMinimum: 1, $schema: 'https://json-schema.org/draft/2019-09/schema'}. Also something I would expect.

But if I have an JSON Schema like:

const schema = {
  $schema: "https://json-schema.org/draft-07/schema",
  id: "my-schema",
  minimum: 1,
  exclusiveMinimum: true,
};

and I'm calling the migrate.draft2019 function, I get {$schema: 'https://json-schema.org/draft-07/schema', $id: 'my-schema', exclusiveMinimum: 1}.

So it seems to update parts of the schema, but totally ignores to update $schema. You did explain this in your comment above, but somehow it feels like a strange behavior. If your tool only updates from draft04 I would expect it to do:

1. Nothing, because we say in our $schema that it already is draft-07. OR
2. It is smart and updates the id and minimum field, but also updates the $schema field.

As I said, I'm by no means an JSON Schema expert. So there might be a reason why one does not simply want to update the $schema field like this:

• if I call migrate.draft7 -> $schema = http://json-schema.org/draft-07/schema'
• if I call migrate.draft2019 -> $schema = http://json-schema.org/draft/2019-09/schema'
• .... and so on ....

Second Part

I know, I'm repeating myself. I'm not an JSON Schema expert ;). But why can the update process not be sequential? Like
having just 4 independent migrate functions that are chained on demand.

• draft04 to draft06
• draft06 to draft07
• draft07 to draft2019
• draft2019 to draft2020

Kind regards,
Daniel

[epoberezkin]

Nothing, because we say in our $schema that it already is draft-07. OR It is smart and updates the id and minimum field, but also updates the $schema field.

that’s reasonable, but it just assumes that you pass draft-04 schema that may have custom $schema, so if it’s anything but draft-04 URI it doesn’t change it. I am not saying it’s correct :)

having just 4 independent migrate functions that are chained on demand.

that’s not a terrible idea, actually.

[epoberezkin]

On your example, it also assumes your schema is valid (and it’s not). Either way, it’s worth redefining this package.

[DanSibbernsen]

Hi @epoberezkin , I'm in a similar boat, trying to migrate from draft-07 to draft-2019 so I can use the newer Conditional logic.

I'm also relatively new to json-schemas, is there a different way to migrate? I noticed this comment seems to resolve the migration error, is there more to it than that? For reference, I'm trying to update ansible-schemas.