-
Notifications
You must be signed in to change notification settings - Fork 554
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
schema: Completely drop our JSON Schema 'id' properties
We're using JSON Schema draft-04 [1], as declared by our '$schema' properties [2]. In draft-04, the 'id' keyword alters the resolution scope. But our current '$ref' values use JSON Pointers [3,4] with relative references like 'defs-linux.json#/definitions/Device' that ignore the 'id's. By draft-07, 'id' has become '$id', and [5]: The root schema of a JSON Schema document SHOULD contain an "$id" keyword with a URI (containing a scheme). But since [6], including any URI that cannot be retrieved generates an error: $ ./validate config-schema.json test/config/good/minimal.json Could not read schema from HTTP, response status is 404 Not Found While a root 'id' entry would be nice, we don't currently host these anywhere with a useful URI. We could use [7], but then testing pull requests would be difficult. By draft-07, the purpose of internal '$id' entries is clearly explained [5]: Providing a plain name fragment enables a subschema to be relocated within a schema without requiring that JSON Pointer references are updated. We don't need that, because we control all the references. In the infrequent event of a subschema move, we can update the consuming references in the same commit. The draft-07 $ref docs also explain that $ref targets may be URNs [8]: The URI is not a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable URI. I haven't found analogous wording for $id, but it's possible that gojsonschema is being overly agressive with its attempted retrievals. This commit removes all of our 'id' entries. The resulting JSON Schema is valid (regardless of where you host it) and does not generate the 404s. Reported by Tom Godkin [9] and William Martin [10]. [1]: https://tools.ietf.org/html/draft-zyp-json-schema-04#section-7.2 [2]: https://tools.ietf.org/html/draft-zyp-json-schema-04#section-6 [3]: https://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-07 [4]: https://tools.ietf.org/html/rfc6901 [5]: https://tools.ietf.org/html/draft-handrews-json-schema-00#section-9.2 [6]: xeipuuv/gojsonschema@83a7f63 [7]: https://raw.githubusercontent.com/opencontainers/runtime-spec/v1.0.1/schema/config-schema.json [8]: https://tools.ietf.org/html/draft-handrews-json-schema-00#section-8 [9]: opencontainers/runc#1680 [10]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/L9ME-YRPmmc Subject: runtime-spec validation questions Date: Thu, 4 Jan 2018 15:47:50 +0000 Message-ID: <CAMp6QwMTJab5K25=CVy=6OZV6NRX0s-nMLGwqC8ZMpFEp5bF_Q@mail.gmail.com> Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information
Showing
5 changed files
with
0 additions
and
124 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.