Add support for JSON Schema draft v4

[theon]

From http://json-schema.org/documentation.html

The latest IETF published draft is v3. However, a newer version of the specification is being prepared for submission in early 2013.

It would be great to get support for v4 as there seems to be quite a lot of changes.

Thanks!

[kennardconsulting]

One big change in v4 is moving 'required' from being inside 'properties' to outside. However I don't believe Jackson's JSON Schema export is even compliant with v3 as it is. Please see https://github.com/FasterXML/jackson-module-jsonSchema/issues/15

[sebfz1]

Hi,

Is there any plan for this one? I am also stuck with the "required" key...

Here is a simple unit test if it can save some time :) https://github.com/sebfz1/jackson-issues/tree/master/issue-09

Thanks & best regards, Sebastien

[cowtowncoder]

@sebfz1 I think this is something that needs discussion on user and/or dev lists. Alas, I don't recall much feedback on v3 versus v4 compatibility...

[sebfz1]

Hi Tatu,

Here is a list of changes between v3 and v4: https://github.com/json-schema/json-schema/wiki/ChangeLog

Would you like me to open a thread in user@ ?

Thanks & best regards, Sebastien

[cowtowncoder]

@sebfz1 I think that would make sense. I would like to see progress here (given how this is highly requested), but I don't use JSON Schema for anything myself, so my role is more advisory. I can of course make minor fixes that are pointed out, help with complications, but am not the driver.

[cowtowncoder]

Heh. Looks like a wholesale rewrite.

I wonder if what is needed might actually be a separate JSON Schema v4 module, keeping this module v3. Or possibly vice versa.

[sebfz1]

Hi Tatu,

Thank you very much for digging into this...

IHMO, I would better keep dual implementations (draft-3 & draft-4) into the same module. Because the question will raise again on draft-5/v1... This way you can have common (eventually abstract) classes and the best... auto-detect the version given the $schema property, ie: "$schema": "http://json-schema.org/draft-03/schema#" or "$schema": "http://json-schema.org/draft-04/schema#"

My 2 cents :) Best regards, Sebastien

[cowtowncoder]

It's easier said than done. I may be wrong, but it doesnt seem like JSON Schema authors cared deeply about compatibility between versions, and as such intermingling code for producing both can produce pretty nasty result.

Regardless, whoever works on this (if anyone) gets to decide. If it can be done without split, all the better.

As to v5, at some point specification needs to become stable enough that changes really are minor, and single codebase can support variants. Or ideally so that new one is a strict superset.

[sebfz1]

It's easier said than done.

I definitely can understand this!

Btw the way, if Jackson is already about Json, maybe the new artifact name could simply be jackson-schema or jackson-module-schema or eventually jackson-json-schema (as there already is a jackson-json-schema-plugin). That's not the most important here, but still...

Maybe if you create the project with the prerequisite (ie: dependencies), it could motivate someone to begin implementing it... If I have some spare time (we never know) I can have a look to see if I have a brilliant idea...

[nrktkt]

Hey, I'm currently working with some code that is tied up with jackson but needs schema v4. If we make some decisions on how to support v4 I can start contributing code to that end. Does anyone have ideas about this?

[cowtowncoder]

@kag0 I think that the easiest thing would be to fork the code to a new project, and once it works well enough, we can figure out whether it should live as a separate project, or whether this project should be changed to multi-Maven-module set up. Either way, I think that the artifact id should be different so that existing module keeps its name, but the new module uses new name. This way backwards compatibility remains 100%.

There are other ways we could use, for example try to use Maven qualifiers. But I haven't really had good experience in trying to make things work that way.

I can help with git/maven project conversion; I think that should be done for Jackson 2.7. But the new external project could be released for 2.6, if things go quickly -- all that is needed is to produce jars.

As to name to use... while including version numbers in names is not a good practice in most cases, here we could just go with

json-module-json-schema-v4

This would also alllow getting rid of camel-case "jsonSchema" which IMO should not have been used (I didn't specify it, but didn't catch early enough).

@sebfz1 I actually prefer keeping "json" in the name just because there are other relevant dataformat schemas for other formats: Avro and protobuf have their own schema languages (which are conceptually different from JSON schema, but... well, use term "schema"); and XML schema might be supported in some form as well. module is bit redundant, but I'd want to keep that just because it helps in grouping various Jackson extensions. But if a better qualifier is thought of, I would be open to using that instead (currently we have "dataformat", "datatype" with reasonable definitions, and "module" for "anything else"). But we could maybe consider jackson-schema-json? The main question there being just that it would be a category with just one instance, for now. And all other schema support is related to actual dataformat module now, and for foreseeable future.

On the other hand, this module currently only handles generation of JSON Schema. But I guess that's ok.

[glaforge]

I'd be curious to know the status of the JSON Schema v4 support, @cowtowncoder. At my company, we were looking at the RAML API definition format, which mandates JSON Schema v4, and we would like to be able to use Jackson. Has there been any progress on this issue? Thanks.

[heruan]

@glaforge :+1: I'd like to keep using Jackson (are there alternatives?) but we too have strict v4-draft requirements.

[nrktkt]

I didn't have time to work on this, just wrote a hack to translate v3 to v4. So don't count on any code coming from this direction any time soon :disappointed:

[sebfz1]

Unfortunately - and even if I'm still interested - I also didn't found any single minutes to work on this... :-/

[heruan]

Consider also that v4 is three years old and v5 is coming soon (see json-schema/json-schema/issues/167).

[mcadi]

@cowtowncoder any news on support for v4 ? I'm stuck with the "required" key issue

[cowtowncoder]

@mcadi I am not aware of anyone actively working on that unfortunately. May make sense to try to revive this on jackson-dev mailing list.

[mrpotes]

I was thinking about this the other day. Looking at the changelogs for the JSON Schema core and validation schemas, the differences between v3 and v4 seem to be in representation rather than in actual semantics, so I wonder whether this issue could be resolved by providing v3 and v4 Serializer and Deserializer implementations? As far as I can see, the Jackson model needn't change, just be augmented by a few new properties here and there.

WDYT?

[cowtowncoder]

@mrpotes In general I do like the idea of pluggable backends over hard fork, but in this particular case I think a bigger rewrite would actually be beneficial. This because there are some areas where current handling appears to be wrong and change would be backwards incompatible. In addition I think that once v4 support works, there will be less and less need to maintain v3.

With that I think a follow-up question is whether to create a separate repo, or change this repo to be multi-module (maven). Latter seems better to me, from release perspective.

[mbknor]

I'm currently writing a new jsonSchema-generator using Jackson (https://github.com/mbknor/mbknor-jackson-jsonSchema). It writes v4 schemas and supports Polymorphism used like this:

@JsonTypeInfo(
        use = JsonTypeInfo.Id.NAME,
        include = JsonTypeInfo.As.PROPERTY,
        property = "type")
@JsonSubTypes({
        @JsonSubTypes.Type(value = Child1.class, name = "child1"),
        @JsonSubTypes.Type(value = Child2.class, name = "child2") })
public abstract class Parent {

    public String parentString;
}

It is not done yet, but works for us. Maybe someone would check it out and contribute.

[denis111]

And what about draft 6 and 7 ?

[Hronom]

What the progress?

[mbknor]

@Hronom @denis111

https://github.com/mbknor/mbknor-jackson-jsonSchema Is working quite nice for Draft 4.

It is used in production many places.

Feel free to send PR with support for 6 and 7 (if they exists?? :) )- I'm not using it myself in any current projects at the time, so I'm not going to implement it.

[Hronom]

@mbknor I'm start using your project, but I was interested how the progress with official support of this standard in jackson. JSON schema needed for many cases.

[denis111]

@mbknor Well, currently I'm also not using it :) But v7 exists https://json-schema.org/ ;)

[mbknor]

@denis111 :)

Any comments, @cowtowncoder ?

[cowtowncoder]

I would be happy to End-of-Life this module, if and when it supports functionality needed by users, as I trust @mbknor 's implementation to already be superior to this module.

EOL would probably occur between 2.x and 3.0, meaning that this module can remain for pre-v4 (as I recall, there was no practical way to have v3-and-v4 support with one codebase).

Having said that, it might be time to see if Jackson 3.0 could expose better introspection functionality, fix some of oddities and limitations there. 2.x mechanism is... not very good. But it is the main mechanism for a few other modules too, like dataformats' schema generation (CSV, protobuf, Avro, Properties at least).

[Hronom]

@cowtowncoder maybe you provide rights to the @mbknor to be a co-maintainer on this module? So this module will be in official family.