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

Use dialect identifier from vega-lite-schema to set jsonschema validator #2800

Closed
mattijn opened this issue Jan 4, 2023 · 1 comment · Fixed by #2812
Closed

Use dialect identifier from vega-lite-schema to set jsonschema validator #2800

mattijn opened this issue Jan 4, 2023 · 1 comment · Fixed by #2812

Comments

@mattijn
Copy link
Contributor

mattijn commented Jan 4, 2023

As was pointed out in #2771 (comment), and summarised here:

  • vega specifies the $schema property in the schema (see for example L3 here), which is a "dialect identifier", it basically is a URI that identifies which version of the JSON Schema spec the schema is written for -- an example of one is https://json-schema.org/draft-07/schema which is the dialect ID for draft 7 of the spec
  • we can then use jsonschema.validators.validator_for to get the right validator class given the schema, which will return you Draft7Validator if the schema use draft 7, but if/when Vega-lite repo upgrade to draft2020 say, then you'd get Draft202012Validator instead and things will work properly still.

Currently (or at least after PR #2771 is merged) the validator version is defined as a constant (draft 7). Altair currently uses this validator for the schema definitions for Vega-lite v3/v4/v5 (and that is still fine as they all use the draft 7 schema). So in my understanding the required change to get this working properly is to make it dynamic and set and define the validator on a version by version basis.

@binste
Copy link
Contributor

binste commented Jan 4, 2023

Thanks for the summary! I'll look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants