subschema nested ref in remote ref

[willson-chen]

The following test scenario is added: The base URI remains unchanged, and multiple layers of nested references are used in the sub-schema.

For details: 601

[Julian]

Thanks @willson-chen! Definitely appreciated.

Before adding this one do we know for sure this isn't already covered by one of the existing tests?

Specifically these are the current $ref-related ones my implementation skips as known bugs. Did you happen to cross reference them against this new one to see whether any of those are testing the same thing the new one is?

(I have not, but definitely we should)

[willson-chen]

@Julian I've seen this before. It's not the same scene.
The base_uri of bug371 will change. I added the case where the path of subschema changes, instead of the base_uri.

[karenetheridge]

This PR has the same problem as described in #360 -- there are collisions between identifiers of different schemas which require an implementation to clear out its uri index between tests. Preferably #360 should be resolved and then this PR will incorporate the same fixes as well.

[Julian]

@karenetheridge sounds like a good point -- just in case -- if you've looked at this, does this scenario look like something untested currently to you too?

[karenetheridge]

if you've looked at this, does this scenario look like something untested currently to you too?

It appears this scenario (a references within a remotely-referenced subschema) is covered by https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/tests/draft2019-09/refRemote.json#L18-L51.

[Julian]

Hm, somehow those can't be the exact same, because my implementation passes those, but fails these.

[karenetheridge]

@Julian interesting! maybe when you track down the source of your bug you will be able to explain how they differ because the difference is surely quite subtle :)

[Julian]

Was that meant for this ticket / did you mean to close this? Or was that meant for #424?

[karenetheridge]

yes, sorry, wrong tab :)

[Julian]

So. The difference between this test and existing ones is simply that we don't seem to have tests which resolve a $ref and then the resulting document contains a relative $ref to resolve that isn't a fragment. The tests in refRemote don't do so, they have JSON pointers into themselves.

I'll take one last look to be sure we indeed don't have any, but last call here for comments :)

And @willson-chen really sorry this took so long.

[Julian]

OK, I believe I'd broken this test with my forward porting, but now after staring at it for a few hours, I think it's correct now, and have verified both against my implementation and another, so think this is good to go finally...

(To again summarize, the key new thing about this test is it involves a 2 step $ref where the second one isn't just a JSON pointer).