Error handling as per draft 2019-09 section 10.

[prashanthjos]

Is there any plan to include the new error handling with the networknt library as outlined in the draft spec below.

https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.10

I am planing to use this feature . Can you please let me know if there is any work happening in this area.

[stevehu]

@prashanthjos This has been discussed in several issues; however, nobody is actively working on this yet. I would be very happy to accept a PR is someone wants to work on it.

As this issue mentioned the guideline from the json-schema-core, we should follow it when implementing the error handling. Given that, I have closed the following related issues as they are all about error messages and should be addressed at the same time. During the implementation, we need to double-check if these issues are addressed at the same time.

https://github.com/networknt/json-schema-validator/issues/278 https://github.com/networknt/json-schema-validator/issues/250 https://github.com/networknt/json-schema-validator/issues/245 https://github.com/networknt/json-schema-validator/issues/58 https://github.com/networknt/json-schema-validator/issues/78

[prashanthjos]

Thank you @stevehu. Should we preserve the signature of the validate method on JsonSchema class. To support the new error message formats , the recursive validate calls should start returning JsonNode Array that represent the errors occurred in each validator rather than a Set<ValidationMessage>. We can collate the error nodes during the recursive call stack.

If we should preserve the signature of validate method should we introduce a new "validateJson" method that does the recursive procedure mentioned above. This might change signatures and code in majority of validators.

Please let me know your thoughts.

[stevehu]

@prashanthjos As this is a major change to the library, signature change is OK and we can bump up the release to 1.1.0 afterward.

[prashanthjos]

Also the way spec represents either the error schema path or error data node path doesn’t follow neither of JSON path or JSON pointer representations. Any thoughts?

[stevehu]

The spec mentioned JSON pointer, but this field is changing so fast these days. Here is something I found in the above link.

Keyword Relative Location
The relative location of the validating keyword that follows the validation path. The value MUST be expressed as a JSON Pointer, and it MUST include any by-reference applicators such as "$ref" or "$recursiveRef".

#/properties/width/$ref/minimum
                        
Note that this pointer may not be resolvable by the normal JSON Pointer process due to the inclusion of these by-reference applicator keywords.

[yuvke]

@prashanthjos As this is a major change to the library, signature change is OK and we can bump up the release to 1.1.0 afterward.

@stevehu I'm not sure what this change exactly entails in term of the ValidationMessage instance that is currently used for output of validation errors. But in case the property names / methods are changed I would consider this a breaking change and bump the version to 2.0.0.

[stevehu]

The major change is the structure of the message, which contains more information. I am not sure if the signature would be changed though. If yes, I agree that we should bump up to 2.0.0.