Incoherency in draft v4 wrt id and JSON Pointer

[Francis Galiegue]

From the json-schema github repo, file draft04/schema:

----
"properties" : {
"type" : {
"type" : [
{
"id" : "#simple-type",
"type" : "string",
"enum" : ["object", "array",
"string", "number", "boolean", "null", "any"]
},
"array"
],
----

Why the "id"? It complicates JSON schema implementations even more,
since it means you have to walk ALL the schema in order to map IDs.
Whereas this schema is perfectly accessible using JSON Pointer:

#/properties/type/type/0

and voilà! No need for a separate id...

--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[Xample]

In my case, referencing internal schemas IDs is the environment job. Look at the following scenario (pseudo code):

1. Get the schema from the environment 

> env.getSchema("http://www.url.com/toSchema");

2. If not already in the table (see below), the environment get the schema and tries to index it into an "absoluteURI_ID - schema" table

> {

   "http://www.url.com/toSchema#" : { … },

   "http://www.url.com/toSchema#simple-type" : { … }

  }

3. Right after loading a schema, I replace every relative references to their absolute equivalent

> {"$ref":"#anId"}

  will become

> {"$ref":"http://www.url.com/toSchema#anId"}

4. Only the environment is then responsible for resolving references even if they are self referencing only. f.e.

> env.getSchema("http://www.url.com/toSchema#anId");