-
-
Notifications
You must be signed in to change notification settings - Fork 582
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
Designating a dialect for custom metaschemas in 4.18 #1061
Comments
This will happen before the real release, probably this week! Thanks for indicating someone is paying attention :D Expect an update in the next few days but it'll look basically like what you expect I hope! |
(to be even more specific no changes should be required on your part though you certainly can choose to make some to get improved behavior, and also there will be a be another beta!) |
Huzzah! I'll keep an eye out for it. |
I want to clarify something that I didn't notice until now -- @eslavich are you specifically calling Are you instead talking about a totally unrelated validator/dialect you created with |
I've been testing asdf with the new 4.18 and I think I might have a minimal example that illustrates why we need to define a specification (and the opaque specification results in resolution errors). For asdf we define a meta-schema based off draft4 (the details probably aren't important but I'm happy to supply as much as you'd like). Since this metaschema is not registered with referencing.jsonschema._SPECIFICATIONS creating a validator with the metaschema results in an opaque specification and failures due to inability to resolve references. Here's a minimal example that was compatible with 4.17: import jsonschema
meta_schema = {
"id": "https://example.com/yaml-schema/draft-01",
"$schema": "http://json-schema.org/draft-04/schema#",
"allOf": [{"$ref": "http://json-schema.org/draft-04/schema"}],
}
s0 = {
"id": "http://example.com/foo",
"$schema": "http://example.com/yaml-schema/draft-01#",
}
s1 = {
"id": "http://example.com/bar",
"$schema": "http://example.com/yaml-schema/draft-01#",
"allOf": [{"$ref": "foo"}]
}
by_id = {s['id']: s for s in (meta_schema, s0, s1)}
def retrieve(uri):
return by_id[uri]
handlers = {'http': retrieve}
resolver = jsonschema.validators.RefResolver(
"", {}, cache_remote=False, handlers=handlers)
Validator = jsonschema.validators.create(
meta_schema=meta_schema,
type_checker=jsonschema.validators.Draft4Validator.TYPE_CHECKER,
validators=jsonschema.validators.Draft4Validator.VALIDATORS,
id_of=jsonschema.validators.Draft4Validator.ID_OF,
format_checker=jsonschema.validators.Draft4Validator.FORMAT_CHECKER,
)
validator = Validator(s1, resolver=resolver)
validator.validate({}) When run with 4.17.3 this executes with no error. When run with 4.18.0 this shows the expected
If I modify the example to use referencing (am I doing this right?): import jsonschema
import referencing
meta_schema = {
"id": "https://example.com/yaml-schema/draft-01",
"$schema": "http://json-schema.org/draft-04/schema#",
"allOf": [{"$ref": "http://json-schema.org/draft-04/schema"}],
}
s0 = {
"id": "http://example.com/foo",
"$schema": "http://example.com/yaml-schema/draft-01#",
}
s1 = {
"id": "http://example.com/bar",
"$schema": "http://example.com/yaml-schema/draft-01#",
"allOf": [{"$ref": "foo"}]
}
by_id = {s['id']: s for s in (meta_schema, s0, s1)}
def retrieve(uri):
if uri in by_id:
return referencing.Resource(by_id[uri], referencing.jsonschema.DRAFT4)
raise referencing.exceptions.NoSuchResource(uri)
registry = referencing.Registry(retrieve=retrieve)
Validator = jsonschema.validators.create(
meta_schema=meta_schema,
type_checker=jsonschema.validators.Draft4Validator.TYPE_CHECKER,
validators=jsonschema.validators.Draft4Validator.VALIDATORS,
id_of=jsonschema.validators.Draft4Validator.ID_OF,
format_checker=jsonschema.validators.Draft4Validator.FORMAT_CHECKER,
)
validator = Validator(s1, registry=registry)
validator.validate({}) The example fails with the following traceback:
|
Thanks, that's definitely helpful, I'll have a look more carefully in the morning, but just to be sure, why are you calling |
Thanks for the quick response and for the good question. I have not tried swapping 'create' for 'extend'. A simple swap (and removing the id_of and meta_schema arguments) in asdf does not appear to work but I'm not quite sure why yet. Is there a way to define a meta schema with extend? |
When I first added the API I mistakenly didn't add one, assuming that generally one wasn't going to change the metaschema -- if this is what's preventing you from using it I'm happy to add an argument for it, though otherwise I wasn't planning on it because eventually the entire API may need deprecating unfortunately due to the new "Vocabulary System" in newer drafts of JSON Schema (which mean that now there's some concept of groups of validators). But yeah if it's useful I can add it if it turns out there's some other reason your quick experiment didn't work. Initially what you shared looks like a bug (at least inasmuch as the behavior should not change for |
I'm currently using the suggestion in #994 (comment) |
I don't think that's the same question, though I'm not 100% sure. The discussion there is about users (perhaps like yourself) who are trying to change what it means to be "Draft 4". This question here is about an explicit new draft which extends another -- i.e. a user who is properly specifying a different |
…rafts We need a bit more state management to serve `RefResolver` until it's fully removed :/ (The handler here is simply to avoid needing to hit some remote reference.) Refs: #1061 (comment)
@braingram this should be at least partially addressed with a bugfix in Can you let me know how much progress that gets you? Appreciated! EDIT: To be clear, "this" is your example comment more so than the title of the issue (being able to create |
@Julian Thanks for the update! I pulled down 4.18.1 and tested the two examples. The one using the deprecated RefResolver now works on 4.18.1. However the second example using referencing.Registry fails with the same error. Is this expected because the |
It has more to do with the original title of this issue, which I'm not sure yet how the best way to solve is (or well, I know a good way, but it involves touching this API even though it's likely not to be a good long term solution for other reasons, so I'm not sure yet whether there's some other one). Specifically to explain the issue -- You have the schema
That
One way of doing that would be, as you said, to have But as I say adding that argument is not completely trivial -- if only because in the current API, you can provide an And now basically that means that the So, tl;dr... yes I'm aware the second example doesn't work yet. If that's what's blocking you, I will consider adding the |
I'm working with a custom metaschema that is a superset of draft 4, is there/will there be a way to select the draft 4 dialect when creating a Validator class? Currently the create method is choosing the opaque dialect when it fails to recognize our metaschema's id:
https://github.com/python-jsonschema/jsonschema/blob/v4.18.0a1/jsonschema/validators.py#L187
and the referencing package doesn't appear to offer a sanctioned method for registering a new dialect id:
https://github.com/python-jsonschema/referencing/blob/v0.24.4/referencing/jsonschema.py#L544-L556
Is there another way to accomplish this that I'm missing? And if not, are you open to adding something like a
default_specification
argument to the create method?By the way, thanks a lot for providing an alpha release, it's super helpful to be able to work through our issues ahead of time.
The text was updated successfully, but these errors were encountered: