How do you get a complete local copy of 2020-12 meta-schema?

[GabenGar]

It was way simpler with draft7 being a single file, but later drafts seem to rely on external references. I assume I also have to get all schemas under $vocabulary, but the links redirect to non-existent sections of the document. Skimming through the document there are seem to be some links present which map to the links in the vocabulary but not all of them. So what gives?

[handrews]

@GabenGar for the meta-schemas, the assumption is that implementations should be able to support that, and we've noticed that many bundle the meta-schemas with their implementation. This is correct as it avoids excessive HTTP requests to the JSON Schema org web site, and we (after experimenting with various policies) guarantee that meta-schema contents won't change.

For the vocabularies, no, you do not have to fetch anything from those URIs, and in fact probably cannot. From the spec §8.1.2. The "$vocabulary" Keyword:

The URI MAY be a URL, but the nature of the retrievable resource is currently undefined, and reserved for future use. Vocabulary authors MAY use the URL of the vocabulary specification, in a human-readable media type such as text/html or text/plain, as the vocabulary URI.

with an additional explanatory note (that's what the yellow highlight of the text means) of:

Vocabulary documents may be added in forthcoming drafts. For now, identifying the keyword set is deemed sufficient as that, along with meta-schema validation, is how the current "vocabularies" work today. Any future vocabulary document format will be specified as a JSON document, so using text/html or other non-JSON formats in the meantime will not produce any future ambiguity.

[GabenGar]

It's not only about excessive http requests, but also not having external http requests at all, i.e. offline or a corporate network. And in general I am not a big fan of programs randomly doing http calls with questionable authenticity (because they are done outside of browser) during development when not asked to.
Even if an implementation bundles meta-schemas it implements into its own module, there are still uses for having a local copy of the meta-schema:

• Extra annotations.
  As an example ajv allows to use a custom meta-schema, provided this meta-schema has a $schema keyword set. This allows to have a meta schema with extra annotations while preserving the validation rules of the base meta-schema.
• Custom schema interface.
  As a result of previous point, local meta-schema allows to create a basic interface for all schemas with all extra information needed for the project instead of manually extending a barebone interface hopefully provided by the implementation and keeping it updated. Becomes a bigger issue once there are more than 1 language (and therefore implementations) needed to participate in the validation process.
• Limiting "format" keyword.
  The more concrete usage is to limit "format" value to a "enum"/"oneOf"/"anyOf" of intersection of all supported values between all implementations in the project. Might not work at the implementation level but at least allows to control it at the level of the project code. This can only work without too much overhead when done on the local copy of the meta-schema itself.
• Various uses in the frontend, the main one is building forms.
  They are made to create values needed to conform to schemas, so might as well use the schemas themselves to build them. It doesn't technically require a meta-schema, but to conceptualize this pattern there needs to be a common interface across all schemas and it can only be derived from the meta-schema.

So I guess a more focused question would be:
Which files do I need to download to be able to create a standalone copy of the draft 2020-12 meta-schema?

It doesn't look like the file at https://json-schema.org/draft/2020-12/schema has a sufficient info by itself. The properties section is way too thin, so I assume the complete information is stored in (potentially) several vocabularies.

[Relequestual]

It's never expected that implementations can make HTTP requests at all. We specify this in the spec itself.

The additional files you need are found in this folder in the spec repo: https://github.com/json-schema-org/json-schema-spec/tree/main/meta

Those are the schemas referenced in the primary schema.json meta schema file you mention.

It's worth noting that references ($ref), schema identifiers ($id) and vocabulary identifiers (keys of $vocabulary) are all URIs as opposed to URLs. That means that they may not be network addressable, as you discovered.

The standalone copy of the 2020-12 meta-schema is spread over multiple files. They could be combined using the bundling process defined in the spec, but that shouldn't be required (and implementations would still need to understand and index the identifiers of embedded schema resources). Modern JSON Schema implementations should be able to process multi-schema-resource validation (aka referencing other files or schemas).

Usually, implementations provide a way to pre-load required schemas, and then create an index of the $ids for referencing later.

[jdesrosiers]

See this gist. It has the full bundled 2020-12 meta-schema and includes the code used to generate it.