Recognizing the hyper-schema meta-schema?

[handrews]

Similar to #28, would it be possible to automatically recognize http://json-schema.org/draft-04/hyper-schema and http://json-schema.org/draft-06/hyper-schema as built-in supported meta-schemas?

(venv) HenrysMacBookPro:schemas henry$ ajv compile -s common/user.json
schema common/user.json is invalid
error: no schema with key or ref "http://json-schema.org/draft-04/hyper-schema#"
(venv) HenrysMacBookPro:schemas henry$ curl http://json-schema.org/draft-04/hyper-schema > hyper-schema
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4639  100  4639    0     0  21803      0 --:--:-- --:--:-- --:--:-- 21882
(venv) HenrysMacBookPro:schemas henry$ ajv compile -m hyper-schema -s common/user.json
schema common/user.json is valid
(venv) HenrysMacBookPro:schemas henry$ 

[epoberezkin]

I'd rather have #29 to be honest - it would cover it.

[handrews]

You mean it would only work by fetching over the network? That's actually against the advice of the spec:

JSON Schema implementations SHOULD implement support for
current and previous published drafts of JSON Schema vocabularies as
deemed reasonable.

plus various notes about things being identifiers and how implementations SHOULD NOT automatically download (presumably if you are passing a custom meta-schema via a URI you know that it's fine to download, but do we really want constant traffic hitting json-schema.org?)

[handrews]

(actually I'm not sure why I thought that quote indicated local support, but there are things about not overburdening schema servers)

[handrews]

I'll probably end up using a modified local schema for testing anyway, but wearing my json-schema-org hat, I'm still a bit concerned about an extremely popular tool regularly fetching the meta-schemas, especially if that is the default behavior.

Happy to do a PR for this if I can sell you on it :-)

[epoberezkin]

Ok. Should it be an option (--hyper)? Or just add them?
I think it won't hurt much, they are only validated, not compiled.

But if your idea is to use modified meta-schema as a substitute for hyper-schema (without changing $schema) which can be valuable for testing you will have name conflict if they are added by default.

So maybe an option --hyper to add hyper-schemas

And maybe even an option --meta=false to avoid adding standard meta-schemas (for the same reason - to allow testing with modified meta-schemas). The latter is a bit more tricky, as this option would affect how schemas are validated, not only whether meta-schemas are added or not.

[handrews]

I definitely like the idea of a switch to disable standard meta schemas, whether that by default includes the meta-hyper-schema or not. In production I expect to use the standard meta-schemas, the modified ones that spoof the standard ids are only for internal dev/test mode. If they were in production they'd make evolving the APIs very difficult because of the strictness.

With my JSON Schema spec author hat on, I want to say "implementation should automatically support all standards-defined meta-schemas equally", but thinking from an implementor/validation-only user, I can see not including it.

The best argument I can think of for including it is that validating hyper-schemas is still validation and will hopefully be an increasingly common thing, so the UX is nicer if it's supported. But I'm not inclined to dig in on this.

I think if it is included, it should be automatic. That keeps UX parity which I think is the main reason to do it, and I can think of why that would be a problem (unless there's some internal performance reason).

[epoberezkin]

I am not that fussed about what it the default, to include or to skip. The performance impact is negligible in this case.

As long as there is an option to control it it's fine.