id ?

[marko bre]

I got rather confused when I read about the id keyword.

consider this example:

   {
       "id": "http://x.y.z/rootschema.json#",
       "schema1": {
           "id": "#foo"
       },
       "schema2": {
           "id": "otherschema.json",
           "nested": {
               "id": "#bar"
           },
           "alsonested": {
               "id": "t/inner.json#a"
           }
       },
       "schema3": {
           "id": "http://where.else/completely#"
       }
   }


as explained in the specification - "Subschemas at the following URI-encoded JSON Pointer [json-pointer]s (starting from the root schema) define the following resolution scopes:"

   # (document root)  http://x.y.z/rootschema.json#

   #/schema1  http://x.y.z/rootschema.json#foo

   #/schema2  http://x.y.z/otherschema.json#

   #/schema2/nested  http://x.y.z/otherschema.json#bar

   #/schema2/alsonested  http://x.y.z/t/inner.json#a

   #/schema3  http://where.else/completely#


meaning that the current schema is located at http://x.y.z/rootschema.json#, #/schema1 is located at http://x.y.z/rootschema.json#foo, ... , #/schema3 is located at http://where.else/completely# ?
meaning, when "$ref": "#/schema3" is encountered during validation, the validator should pull contents from http://where.else/completely# and validate the data against the content retrieved from that link?

so, if this is the case, how is "$ref": "#/schema3" different from "$ref": "http://where.else/completely#"? or "$ref": "#/schema1" from "$ref": "#foo"? and what is the actual use of "id" then?

Or maybe I got all that wrong, and if so, can someone please explain this?

and what would happen if "id": "http://x.y.z/rootschema.json#" was never set? Where would #/schema2 point to?

Consider scenario no. 2 :


   {
       "id": "http://x.y.z/rootschema.json#",
       "schema1": {
           "id": "#foo"
       },
       "schema2": {
           "id": "otherschema.json",
           "type": "string"
           "nested": {
               "id": "#bar"
           },
           "alsonested": {
               "id": "t/inner.json#a"
           }
       },
       "schema3": {
           "id": "http://where.else/completely#"
       }
       "type": "object",
       "properties": {
           "prop1": {
               "$ref": "#/schema2",
               "type": "integer"
           }
       }
   }

and lets imagine that this is what we get from navigating to  http://x.y.z/otherschema.json#:
   
   {
       "id": " http://x.y.z/otherschema.json#",
       "type": "array"
   }

Ok so, now the questions is, during validation of prop1 what happens? When "$ref": "#/schema2" is encountered, should data in prop1 be validated against all types (integer, string, array)?
Or maybe some of these type validations are skipped or overwritten?

[Geraint]

Actually, it's meant to be the other way around.  If "#/schema3" is encountered during validation, then it can use the schema from the document it already has (http://x.y.z/rootschema.json#/schema3).

However, what "id" says is that:

1. all "$ref"s within schema3 should be resolved relative to http://where.else/completely#
2. if the client/validator trusts the schema to be telling the truth, then when it encounters {"$ref": "http://where.else/completely#"} it may use the schema from the document it already has (http://x.y.z/rootschema.json#/schema3)

Does that make any more sense?

so, if this is the case, how is "$ref": "#/schema3" different from "$ref": "http://where.else/completely#"? or "$ref": "#/schema1" from "$ref": "#foo"? and what is the actual use of "id" then?

Or maybe I got all that wrong, and if so, can someone please explain this?

and what would happen if "id": "http://x.y.z/rootschema.json#" was never set? Where would #/schema2 point to?

If there is no "id" at the top level, then the base URI of the schema is the URI that was used to fetch the schema.

So if the document was fetched from "http://example.com/schemas/blah", then #/schema2 would be claiming to be equivalent to "http://example.com/schemas/otherschema/json".

[marko bre]

yup, makes sense . Thanks