Jason Desrosiers

There's a bit of vocabulary confusion happening here. Let's look at an example. ```json { "description": "simple enum validation", "schema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "enum": [1, 2, 3] }, "tests": [...

> having only individual test IDs would be a massive pain for implementers. > > an implementer might not support the entire enum keyword at all, and forcing them to...

This needs to be way simpler. It's trying to solve every imaginable problem and makes it too complicated for anyone to remember how it works. So, we're either forcing everyone...

Good. This is thinking in the right way, but there's one thing I think you're missing. The point of using a hash is that it can be checked automatically against...

> More importantly, if we don't do this now, we'll likely need to do it eventually anyway — either when the AST structure changes or when we want more control...

> My implementation doesn't add to the dynamic scope until the reference is fully resolved. That's what my implementation does too. I was mistaken when I said otherwise in the...

Crossing resource boundaries isn't about reference resolution. You're just describing an external reference. Crossing resource boundaries is about JSON Pointers. JSON Pointers identify a location in a schema resource. `bar#/$defs/item`...

> Let's drop this, please and focus on the issue topic. This definitely ended up being a tangent about what "crossing resource boundaries" means and we can resolve that discussion...

I think @MeastroZI was right the first time. The original test should be modified because it's just a duplicate of another test. Changing the test makes it cover a unique...

For the required tests in this PR (`$ref: "items"`), I don't think there's any ambiguity. I don't see how the spec could be interpreted to include `bar` in the dynamic...