search

networknt / json-schema-validator

A fast Java JSON schema validator that supports draft V4, V6, V7, V2019-09 and V2020-12
Apache License 2.0
807 stars 320 forks source link

improve outputUnits with all assertion fields #1030

Closed JR-Utily closed 2 months ago

JR-Utily commented 2 months ago

Thanks for your great lib. We needed json schema validation for our scala project, and it was really easy to wrap around your work !

I have one suggestion regardless: You have documented a lot of interesting fields available for the "assertion" object here https://github.com/networknt/json-schema-validator?tab=readme-ov-file#results-and-output-formats that are in fact only available in the ValidationMessage class and not in OutputUnit for LIST or HIERARCHY validation. It would be great to have them, for example to be able to built our own error message from the given errors without the need to rely on the lib specific formulation.

In this view, I think OutputUnit.getErrors and OutputUnit.getAnnotations could return something with stronger type than just Map<String, Object> to give structure, in a way close to what already exists in ValidationMessage

I hope it helps improve this great lib !

justin-tay commented 2 months ago

The output unit needs to serialize the errors to the message to implement A Specification for Machine-Readable Output for JSON Schema Validation and Annotation so that won't change.

It's also not really possible to return a stronger type, as the type varies and Object is the only shared super type.

If the issue is that you would like the ability to customize the messages for those formats then I can see if something can be exposed to do so.

JR-Utily commented 2 months ago

Well, I didn't interpret the spec as you did, but I get your point. IMHO, the format given for LIST and HIERACHY are examples, not what MUST be implemented. When it says " however it is RECOMMENDED that the output be convertible to the JSON format defined herein via serialization or other means. " it does not say the error message has to be already formulated in one locale in output units, only that it should be easily serializable in json (and most struct data are). BUT this is just my opinion, and I see what you did in the PR, which is great. If I understand correctly, it will allow to pass a function to instantiate any Class from a ValidationMessage so that Class would be put in the getErrors() Map ? If so, it is really great, and I must thank you for the quickness of the patch !

justin-tay commented 2 months ago

Yes the mapped object will get put in the errors map. If you pass the identity function then the ValidationMessage will just get passed through as is, but you can also do your own mapping from the ValidationMessage to a String.