json-schema-validator icon indicating copy to clipboard operation
json-schema-validator copied to clipboard

18 out of 61 2019-09 offical tests are disabled

Open anthonyleonard opened this issue 3 years ago • 1 comments

18 out of 61 of the offical 2019-09 tests are disabled in this project.

https://github.com/networknt/json-schema-validator/blob/master/src/test/java/com/networknt/schema/V201909JsonSchemaTest.java

I am writing up pros and cons of different Java libraries for my organisation. Though this library scores highly for being the most actively maintained, this level of non-compliance for a 3 year old draft seems very high.

anthonyleonard avatar Aug 23 '22 11:08 anthonyleonard

@anthonyleonard This is a very good question, and I want to take this opportunity to clarify our approach to supporting multiple specification versions in the library.

The library was implemented as a utility in the light-4j framework to validate the HTTP request and response at runtime based on the OpenAPI specifications. Although the schema specification is moving very fast, the OpenAPI adoption is slow, and there is no pressure for us to implement any keywords that OpenAPI doesn't support.

The latest version support, like 2019-09 or 2020-12, is community-driven, and we only implement keywords that our users are using. The majority of our focus is to get some new features into the library to support wider use cases like walking a JSON based on the schema, etc. When a new keyword is asked by one of the users, we open the issue and discuss it openly here for the design. Then it is implemented by the community members and most cases, the person who is asking for the keyword.

In this way, we can bring the users to the latest version as fast as possible, and keywords can be added for each iteration. In my mind, some of the keywords or some use cases of keywords will never be used. They are in the specification to make it complete syntax-wise. We don't have a scheduled release cycle, and we release a new version when an important feature or a bug is fixed. Also, we are trying our best to keep it backward compatible as a lot of users are using it.

Another reason we are using this approach is due to the shortage of resources from our team. The majority of our team members are focusing on the light-4j frameworks/products, and we have to rely on the community to help with some of the features that are not used by the light-4j or OpenAPI specification.

In summary, I think we have adopted a way to deliver the max to our users without putting pressure on our developers. Just like you are learning a new language, you should start using it as long as you have the basic grammar rules mastered. Nobody will learn all the grammar rules first and then start using the new language.

stevehu avatar Aug 23 '22 17:08 stevehu

@anthonyleonard You can track our progress in two places:

As you can deduce from the second link, we have some work to do when it comes to resolving references. The delay comes from identifying how to implement the specification without breaking existing clients and doing so without sacrificing performance.

fdutton avatar May 23 '23 23:05 fdutton