Dynamic references are not URIs

[jdesrosiers]

We've made several improvements to dynamic references. We determined that the bookending requirement is unnecessary. So, we removed it (https://github.com/json-schema-org/json-schema-spec/issues/1064), which made the initial resolution step unnecessary. So, we removed that too (https://github.com/json-schema-org/json-schema-spec/issues/1140), which makes it unnecessary for a dynamic reference to be a URI at all.

So, now I'm proposing that we remove the leading # from dynamic references. There's no reason for these values to look like URIs. The only reason to keep them is that changing it would be a breaking change. The dynamic reference changes we've made already are technically breaking changes, but they are pretty low impact. If you've been using dynamic references correctly, you shouldn't notice the change in almost all cases. This change would be a little more disruptive.

Option 1 - Remove the leading #

Pros: This change should help reduce confusion about this feature. When it looks like a URI, people expect URI resolution-like behavior and that's not the case for this feature.

Cons: Users would have to make a slight change their schemas when upgrading to the stable release: "$dynamicRef": "#foo" => "$dynamicRef": "foo".

Option 2 - Without leading # is preferred, with leading # is deprecated

Pros: Users don't need to change their schemas in order upgrade, but new schemas can use the new notation.

Cons: Until schema linters are widely used, there's no good way to give users feedback that the # notation is deprecated which means people are likely to continue to use it unnecessarily and it will likely never go away completely. Also, we'll never be able to remove the # notation unless we have move to a v2, but ideally we'll never have to do that.

Option 3 - Do nothing

Pros: No schemas or implementations need to change.

Cons: We're stuck with this useless historical artifact.

[gregsdennis]

I think I prefer option 2. Allow #* but discourage it. Maybe include its support as a MAY requirement to let implementations decide.

[jdesrosiers]

Maybe include its support as a MAY requirement to let implementations decide.

I don't know about that. It would mean it would work in some implementations, but not others. That's something we want to avoid. I think if we allow it, it should be required to implement even if we discourage its use.

[jdesrosiers]

I was thinking that we can allow implementations to support #, but only by configuration that's off by default. But then I thought, they can do that anyway without us having to say it in the spec. We could mention that in release notes, but I don't think it should be in the spec. So, maybe we should just go with option 1.

What do you think @gregsdennis?

[gregsdennis]

I'm happy with removing it. I think having the strings match makes sense, and it removes all "URI" association.

I can easily add the option in my lib.