Commits on Jan 5, 2018

1. 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>

   

   wking committed Jan 5, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 4e5a137
   • Browse repository at this point

   Copy the full SHA

   4e5a137 View commit details

   Browse the repository at this point in the history