Allow callers to provide a resolver for "$ref" schemas

[robfig]

Presently, when validation encounters a $ref it looks it up in a package-scoped DefaultSchemaPool, and not finding it there requests it over HTTP.

The problem with this for my use case, is that I would like to allow users to update schemas (so would need to invalidate the cached copy in DefaultSchemaPool), and I would like to allow them to use private schemas, which would not be accessible over HTTP.

It seems like it might be a generally nice feature to introduce an SchemaResolver interface that the DefaultSchemaPool and HTTP fetching are packaged behind, and allow callers to plug in their own.

If I make such a pull request, would you be open to it?

Thank you, Rob

[robfig]

The spec seems to agree with me with some SHOULDs https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3.1

8.3.1. Loading a referenced schema

The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, and the URIs that identify them.

When schemas are downloaded, for example by a generic user-agent that doesn't know until runtime which schemas to download, see Usage for Hypermedia [hypermedia].

Implementations SHOULD be able to associate arbitrary URIs with an arbitrary schema and/or automatically associate a schema's "$id"-given URI, depending on the trust that the validator has in the schema. Such URIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations as shown in section 8.2.4.

[b5]

Sorry for the delay on this @robfig we would absolutely be open to such a thing. We've been meaning to implement such facilities for a while, but are too bogged down atm. We have some commented-out unit tests & TODOs regarding loading referenced schemas if my memory serves correctly. Thanks for filing in advance!

Our only non-standard request when working is to use Qri's commit-message guidelines which helps us automate changelogs.

[b5]

If there's anything you need from us before filing, like working out the interface, I'd be happy to collaborate on this issue. Otherwise I'll make sure a few of us are around for prompt turnaround on reviews.

Thanks again!

[robfig]

Here's a draft, but I ran into some issue getting the tests working. It seems that the references in the test case are not actually attempted to be resolved, for some reason. https://github.com/qri-io/jsonschema/commit/a12c30bf6b8adf00bb9c51a5b3cbd44c680a651e

[b5]

This is looking really good!

Try adding this after line 646 of schema_test.go in that branch 😉

rs.FetchRemoteReferences()

[tv42]

DefaultSchemaPool seems to no longer exist. I guess it's called SchemaRegistry now?

It also seems to force global state on you, which is just weird and wrong...