Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support standard output formats #1008

Open
flying-sheep opened this issue Oct 24, 2022 · 3 comments
Open

Support standard output formats #1008

flying-sheep opened this issue Oct 24, 2022 · 3 comments
Labels
Dialects v2 Issues which will likely be addressed as part of reworked dialect support Enhancement Some new desired functionality Error Reporting Issues related to clearer or more robust validation error reporting

Comments

@flying-sheep
Copy link

flying-sheep commented Oct 24, 2022

The standard draft 2020-12 defines four standard output formats: https://json-schema.org/draft/2020-12/json-schema-core.html#name-output-formatting

  • Flag - A boolean which simply indicates the overall validation result with no further details.
  • Basic - Provides validation information in a flat list structure.
  • Detailed - Provides validation information in a condensed hierarchical structure based on the structure of the schema.
  • Verbose - Provides validation information in an uncondensed hierarchical structure that matches the exact structure of the schema.

jsonschema should provide ways to emit them and integrate them with its error structure:

  • there should be a Validator method with a format keyword argument that just emits a Python dict conforming to the chosen format
  • the ValidationErrors emitted by iter_errors should match the errors in the Basic format
  • the ErrorTree structure should match the Detailed/Verbose format
@Julian
Copy link
Member

Julian commented Oct 24, 2022

Hi there! This is certainly welcome/desired, though the implementation is a bit different.

The output formats are actually being restructured heavily still (see json-schema-org/json-schema-spec#1249 and json-schema-org/json-schema-spec#1320) for the next release of the specification.

What this means here is that certainly for now, though implementing them is very much desired and will be done, that the mechanism is going to follow more closely the API that exists here and has existed forever -- meaning -- I want this library, in its ValidationError details to essentially support all of the data needed to generate those output formats, or any changes to them.

My quick pass previously was that that's indeed either fully possible or very nearly possible to do already today, simply by taking a bunch of ValidationErrors and generating the specified JSON for each format. Any gaps here though are 100% stuff that should be added.

Someone (if no one else, eventually me) then should package functions into a package which depends on this one and generates the specific output format (and I'm happy to host+promote that package in this org).

So, a jsonschema-output2020 package, which, in pseudocode supports:

from jsonschema.validators import Draft2020Validator
import jsonschema_output2020
errors = Draft2020Validator(schema).iter_errors(123)
output = jsonschema_output2020.detailed(errors=errors)
print(json.dumps(output))

is what I believe is the right next step here, along with collecting any missing things from the ValidationError API which would support such a thing.

If/when things stabilize upstream, it's possible that the functionality can fully move into this library, though it's something we can independently think about.

the ValidationErrors emitted by iter_errors should match the errors in the Basic format
the ErrorTree structure should match the Detailed/Verbose format

These objects have backwards compatibility guarantees, so regardless of anything else, this sort of thing wouldn't change, not without long deprecations.

Hope that clarifies, and very much could use some help if you're interested in giving such a thing a shot.

@flying-sheep
Copy link
Author

Thank you for the detailed answer. I encountered some problems using ErrorTree, so I wasn’t sure how reliable a translation would be (e.g. ErrorTree only contains the first error for multiple missing required properties, ignoring all subsequent ones).

Granted, that only applies to ErrorTree, not iter_errors.

@Julian
Copy link
Member

Julian commented Oct 25, 2022

Yes ErrorTree is completely unrelated (though the issue you mention with it is #442 ).

@Julian Julian added the Enhancement Some new desired functionality label Apr 18, 2023
This was referenced Jul 28, 2023
@Julian Julian added the Error Reporting Issues related to clearer or more robust validation error reporting label Nov 16, 2023
@Julian Julian added the Dialects v2 Issues which will likely be addressed as part of reworked dialect support label Feb 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dialects v2 Issues which will likely be addressed as part of reworked dialect support Enhancement Some new desired functionality Error Reporting Issues related to clearer or more robust validation error reporting
Projects
None yet
Development

No branches or pull requests

2 participants