Modular schema libraries (avoid hardcoding the base URI)

[jayrbolton]

I realize similar issues to this have come up before (eg here). I also realize this may be more of an implementation issue. If there is a better place to move this post, let me know. Basically, I want to avoid hardcoding any base URI references in a schema in order to better control dependencies in different environments (not unlike imports in a programming language).

A more concrete example:

• I have a login form frontend that uses json-schema for form validation
• I have a database server that uses json-schema for request validation
• I have a repo of json-schemas that I want to reuse in both places (let's call it the "schema-lib")
• In both the UI and the backend, I want to reference both local schemas and schemas from our schema-lib
• I have multiple deployments of the UI, the server, and the schema-lib (eg test, staging, production)
• When referencing schemas from the schema-lib, we need a configurable base URI that will change based on our environment
• (It would also be useful to configure and use multiple base URIs)

Here are a couple proposed solutions (both very much in the implementation layers):

• A hack using some template variables: https://gist.github.com/jayrbolton/117ca1d5bb9454c55a2295dda0df4d31
• Download remote schemas with a CLI and reference them all locally when validating, like an extremely stripped down package manager: https://gist.github.com/jayrbolton/e81fa352954bc29aea5bdce5bb4de92d

Side note: ideally, I would want to avoid any hard dependencies on http URLs to third party servers if I want the application to still work in a few years

[karenetheridge]

You can have an $id on a schema that is a uri-reference -- that is, it needs a base uri in order to be fully resolvable. If you are loading your schemas externally (rather than feeding them into the evaluator), then you would need to provide that base uri to the evaluator as well in order to know where to load the schemas from as references are encountered.

I use precisely this method for managing schemas across both production and staging instances of my application, where the uri references to individual schemas (e.g. "request.json", "response.json", "app-definitions.json") are constant but the base uris vary.

[Relequestual]

@jayrbolton Does the solution proposed by @karenetheridge sound like it would work for you?

Broadly, I think we would consider making either of the changes you suggested, as outside the scope of JSON Schema. There's templating via other existing tooling, and you could pre-compile your schemas.

BUT, as @karenetheridge points out, you can use a uri-reference, which can be a relative reference as opposed to a full URI.

[jayrbolton]

It sounds like what I'm looking for, but I'm not totally understanding what my schema would look like. Say I had a login form schema, which references two other schemas, each with different base URIs:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "Login Fields",
    "type": "object",
    "additionalProperties": false,
    "required": ["email", "password"],
    "properties": {
        "email": {"$ref": "{base_uri1}/defs.json#/definitions/email"},
        "password": {"$ref": "{base_uri2}/base/defs1.json#/definitions/password"}
    }
}

What would this look like if I instead used uri-reference $id fields?

[Relequestual]

If you want more than one base URI, then you're out of luck.
I think we both assumed you would only want one base URI.
It looks like you've you found several solutions that work for your situation.
This is very much outside the scope of JSON Schema itself.

Feel free to join our open slack server if you want to ask general questions or chat about approaches.