support for draft V6, V7 and V2019-09

[vinaygoureddy]

I am looking to use constant (json-schema-org/json-schema-spec#58) from draft v6 and there is a proposal to use Switch, so would there be any chance of supporting for draft v6 in future?

[stevehu]

Yes. I am planning to refactor it with IoC service this holiday season. After that the user can config there instance with v4 or v6 support and they can replace some of the validators if they like just by putting a jar in the classpath with config change in service.yml.

[davsclaus]

Adding support for draft v6 would be really cool. We have just switched to use this library in our camel-json-validator component

source: https://github.com/apache/camel/tree/master/components/camel-json-validator
docs: https://github.com/apache/camel/blob/master/components/camel-json-validator/src/main/docs/json-validator-component.adoc

[stevehu]

@davsclaus Thanks a lot for sharing the good news. This is very encouraging to see this library is used and enhanced by the community. It is a very small component in light platform but we are using it intensively in light-rest-4j, light-graphql-4j and light-hybrid-4j frameworks. I recently wrote an OpenAPI 3.0 parser and there are a lot of ideas can be leverage here.

[handrews]

Note that draft-07 (which is backwards-compatible with draft-06) is out:
http:https://json-schema.org/specification.html

[dillonredding]

Any news on supporting draft-06 or draft-07?

[stevehu]

I am planning to rewrite this library with light-4j/service dependency injection so that we can support all version of specifications.

[CHENXCHEN]

Any news on supporting draft-06 or draft-07?

[stevehu]

The team has been busy to support the existing use cases and enhancements mainly for OpenAPI 3.0 specification. However, there are so many validators have been updated to support v6 and v7 features. Everyone is welcome to open issues or submit PRs if you see one of the validators is missing or need to be enhanced to support the latest specification.

[handrews]

@CHENXCHEN @stevehu note that there is serious discussion going on for OpenAPI 3.1 to go to draft-08 (a.k.a. draft/2019-08, because for complicated IETF reasons, the draft-NN numbering got kinda weird). OAI/OpenAPI-Specification#1977

While draft/2019-08 will take some time to be adopted, its extensibility features make it better suited for use cases like code generation. We are hoping that draft/2019-08 will be a major new baseline for both JSON Schema and OpenAPI, since it addresses most of the major long-standing problems with the project, including those that caused OpenAPI to use an incompatible modification of JSON Schema in OAS 3.0.

[stevehu]

@handrews Thanks a lot for the link and I am so happy that OAI is fully adopting JSON schema specification with only the extensions. I am constantly making decisions in sticking with JSON schema or supporting OpenAPI when working with this library. Do you know when the v3.1 will be released?

[handrews]

@stevehu I'm not that directly involved with the OAS 3.1 schedule, although there's probably something about it on their site or github repo somewhere. It's not a 100% done deal on the convergence, but it is what everyone is working towards so I suspect we'll sort it out.

[stevehu]

@handrews Thanks a lot. We will be monitoring the progress and implement the enhancements along the way.

[handrews]

draft/2019-08 is in final-ish review (I need to update this page) but be warned that we already know that the stuff relating to the vocabulary concept in the Core spec is not clear enough for folks. I'm working on that this week.

[handrews]

http:https://json-schema.org/work-in-progress

[stevehu]

There are still several validators that are not implemented. Let's keep this open until everything is done.

[stevehu]

Close this issue and track individual issues with separate numbers.