I still have some work to do here for $dynamic*, but I'm going to wait until #1589 is done so I can rebase on that.

Just did a close/open to rekick the build. It had been a while and couldn't do it manually.

Reviewed the changes in #1589, and they seem to align with the rest of what I've updated here, so I'm going to leave $dynamic* as it is.

...I still really dislike the way dynamic scope is defined. I think it should be the stack of schema resources and not include subschemas.

I agree, and this is already how we define dynamic scope (unless you're intending to change that?) -- we say elsewhere in the spec, when processing $dynamicRef [emphasis mine], "...the initial URI MUST be replaced by the URI (including the fragment) for the outermost schema resource in the dynamic scope that defines an identically named fragment with "$dynamicAnchor".

Therefore, in my implementation, the current URI is pushed to the dynamic_scope stack (the array that is searched when processing $dynamicRef) only when processing the $id keyword, not for every subschema.

I can't see any usecases for wanting other, non-resource, subschemas to be stored in the dynamic scope.

I've updated to use resources. (This is actually what we agreed on when @jviotti was writing his posts on scopes.)

It does raise one question, though: what if evaluation starts at a subschema? I suppose the dynamic scope is still the resource, but the evaluation path would still start from the subschema? This is how I have it now, and I could change it if we decide something else.

I desperately hope we wouldn't ever add another keyword that uses dynamic scope. - @jdesrosiers

I don't know. I think if explained properly (which is what this change is for), dynamic scopes could be utilized by others that need it. I think it's a powerful concept and it gives extensions another trick.

It does raise one question, though: what if evaluation starts at a subschema? I suppose the dynamic scope is still the resource, but the evaluation path would still start from the subschema? This is how I have it now, and I could change it if we decide something else.

This would be good to have as a test case in the test suite. Also, writing up an example of how this would work depending on which way it would be implemented would help us see which way is more "right".

writing up an example of how this would work - @karenetheridge

What I'm really thinking of here is more related to what you might have in an OpenAPI description. A resource root might be the entire document, so a schema wouldn't be at the resource root.

openapi: 3.1
# ...
components:
 schemas:
 foo:
 $dynamicAnchor: root
 properties:
 bar: { $ref: "#/components/schemas/bar" }
 bar:
 $id: bar
 $dynamicAnchor: root
 properties:
 recurse: { $dymamicRef: "#root" }

Here, while evaluation starts at /components/schemas/foo, the evaluation path after a loop would look like /properties/bar/$ref/properties/recurse/$dynamicRef, and you'd be back at /components/schemas/foo.

The dynamic scopes, then, are:

• the document
• the bar schema
• the document again, ...

So even though the top-level scope is the full document, the evaluation path starts in the middle of it. I think this is fine and probably expected.