add tests for $dynamicAnchor in multiple branches of propertyDependencies

[gregsdennis]

Resolves #615

[gregsdennis]

This should be in draft-next.

Yep. My bad. That's what I meant.

The dynamic anchors in "east" and "west" need to be in a definition or something where it doesn't get evaluated.

The goal of this test is to check whether the implementation can resolve to the right anchor. I don't see how burying the anchors inside $defs adds value.

east is only evaluated when expectedTypes is strings (similarly for west when expectedTypes is integers), so the argument that putting the anchor in a def prevents it from being evaluated doesn't hold.

Yes, the anchor and the associated $id are the same subschema, but that's irrelevant for this test.

[gregsdennis]

🤔 @jdesrosiers I do see a problem with what I have that your approach solves: having $ref and $dynamicAnchor together would probably cause the $ref to re-evaluate, resulting in a loop, which should be rejected by the implementation.

I'll update.

[jdesrosiers]

I'm not sure I see the loop. The problem I saw was much more fundamental than that. In order for the sub-schemas to apply, the instance must be an object, but the propertyDependencies sub-schemas assert that the instance is a string or integer depending on which sub-schema matches. Then the sub-schema that's asserting that the instance is a string or integer references "inner" which asserts that the instance is an object. These contradictions mean that the propertyDependencies sub-schemas are effectively false and the test cases don't correctly describe the schema's expected results, nor do they demonstrate dynamic behavior.