$id in subschema and fragments

[Matt Wlazlo]

The RCF gives the following example:

{
    "$id": "http://example.com/root.json",
    "definitions": {
        "A": { "$id": "#foo" },
        "B": {
            "$id": "other.json",
            "definitions": {
                "X": { "$id": "#bar" },
                "Y": { "$id": "t/inner.json" }
            }
        },
        "C": {
            "$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f"
        }
    }
}

The schemas at the following URI-encoded JSON Pointers [RFC6901] (relative to the root schema) have the following base URIs:

...

#/definitions/B/definitions/X

http://example.com/other.json#bar

http://example.com/other.json#/definitions/X

http://example.com/root.json#/definitions/B/definitions/X

Why isn't http://example.com/root.json#bar included as a base URI for #/definitions/B/definitions/X?

Cheers,
Matt.

[Henry Andrews]

Because the "$id" :"#bar" (a plain-name fragment declaration) is only resolved against its immediate base, which is "$id": "other.json", producing "other.json#bar".  It does not "see" the earlier bases.

The JSON Pointer fragments are calculated differently, as they specifically state 'When an "$id" sets the base URI, the object containing that "$id" and all of its subschemas can be identified by using a JSON Pointer fragment starting from that location.  This is true even of subschemas that further change the base URI.' (note second sentence).

It's debatable as to how ideal this is, but as the current editors/authors inhereting an existing spec, this seemed to be the behavior that most people expected.

-henry