Test property named $ref, containing an actual $ref

[ryangalamb]

No description provided.

[karenetheridge]

this looks similar to #383.

[ryangalamb]

@karenetheridge Thanks! Those test cases are quite helpful for what I'm working on.

The bug this PR covers in my implementation is a bit different. (I don't see any $refs as non-keyword property names in the other PR.) I have a function that takes a validation path and figures out the appropriate base URI for that schema location. My first implementation would see /properties/$ref and then try to resolve the schema as a $ref. Since I was only using that function to determine the base URI to resolve a $ref against, nothing in the test suite was exercising that yet.

Since this test case broke my implementation, I figured it was worth sharing the breakage love.

[karenetheridge]

LGTM.

[karenetheridge]

This is a good test as some implementations do indeed attempt to parse every $ref they see as a jumping point, without looking to see if it is actually a schema, as opposed to simply a property.

two points about this test in particular:

• it would be more robust by testing "$ref": "...a property value...", as the current test case has the $ref value being an object, which is not syntactically valid for a $ref keyword. The easiest (only?) way to do this with the current schema syntax is to have the $ref be inside an "enum" or "const" keyword.

• Also, the test(s) should be extended back to every draft where it's relevant (which is all of them, in this case).

[ryangalamb]

The easiest (only?) way to do this with the current schema syntax is to have the $ref be inside an "enum" or "const" keyword.

That'd be good as an additional test, thanks. I'm happy to add it.

For my implementation, that wouldn't have triggered the bug this PR is targeted for. (My specific issue is when "$ref" is on the validation path, and then the validator tries to apply an actual "$ref" keyword. It was messing up the way I determine the base URI to resolve the $ref against.)

Also, the test(s) should be extended back to every draft where it's relevant (which is all of them, in this case).

👍 good point. Thanks!

[ryangalamb]

Done backporting the cases!

[Julian]

Thanks, backport looks good to me, so merging this too -- sounds like possibly there was a follow-up test we were considering? If so probably perfectly good to do that in a follow-up PR if needed.