errors in refRemote.json "base URI change - change folder"

[karenetheridge]

So after the merging of #360 which gave the resources unique names, I was able to test these tests against my implementation, and I got some failures. After closer examination I think the test is wrong, not my implementation:

The errors are in the schema with description "base URI change - change folder". Let's look at that schema:

        "schema": {
            "$id": "http://localhost:1234/scope_change_defs1.json",
            "type" : "object",
            "properties": {"list": {"$ref": "baseUriChangeFolder/"}},
            "$defs": {
                "baz": {
                    "$id": "baseUriChangeFolder/",
                    "type": "array",
                    "items": {"$ref": "folderInteger.json"}
                }
            }
        },

and let's trace the evaluation path through the schema:

• first, we identify the local resources "http://localhost:1234/scope_change_defs1.json" (the main schema itself), and "http://localhost:1234/baseUriChangeFolder/" at path /$defs/baz.
• at /properties/list/$ref, we have the uri reference "baseUriChangeFolder/". Using the base $id http://localhost:1234/scope_change_defs1.json" we resolve that reference to "http://localhost:1234/baseUriChangeFolder/", which is in the locally-defined schema at path /$defs/baz.
• we start evaluating the subschema at /$defs/baz. We got here through the $ref "http://localhost:1234/baseUriChangeFolder/", so that's our new base uri (used for subsequent uri resolution).
• at /$defs/baz/$id, we identify ourselves as "baseUriChangeFolder/" (note the lack of leading / here). Resolved against our base uri, this identifies our local position as "http://localhost:1234/baseUriChangeFolder/baseUriChangeFolder/".
• at /$defs/baz/items/$ref, we have the uri reference "folderInteger.json". Resolved against our base, that gives "http://localhost:1234/baseUriChangeFolder/baseUriChangeFolder/folderInteger.json". But that resource doesn't exist, so we error out at this point.

The error is that the uri at /properties/list/$ref should have a leading /, so it doesn't append to whatever existing path we already had in our base uri. When we first identify resources in this schema, the path component of the base uri is "/scope_change_defs1.json" -- there are no directory portions to use in the base, so resolving "baseUriChangeFolder/" against that gives us "/baseUriChangeFolder/" as the new base. But when we actually traverse the $ref and evaluate the subschema's $id, the base uri changes to "baseUriChangeFolder/" resolved against the base, which is "/baseUriChangeFolder/baseUriChangeFolder/".

If we're in agreement that this is an error, I can submit a one-character pull request that amends the uri reference at /$defs/baz/$id. If not, please explain why you disagree :)

cc @epoberezkin, who wrote the original test in commit a884acc (PR #160)

[karenetheridge]

I stared at this some more and I think I'm wrong. I'll fill in the details tomorrow.

shakes fist at tests finding bugs in my implementation :D

[karenetheridge]

The important part of the spec to note (that I got wrong in my analysis above, and in my implementation), is at https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.8.2.2:

[I]n accordance with RFC 3986 section 5.1.2 regarding encapsulating entities, if an "$id" in a subschema is a relative URI-reference, the base URI for resolving that reference is the URI of the parent schema resource.

What I have been doing is setting the "current base uri, to be used in future uri resolution" to the uri of the current resource being jumped to via a $ref, but that means if the uri is relative, on seeing the $id at the current root, the uri is resolved again, resulting in the doubling of the path.