require that $schema cannot contain a fragment

[gregsdennis]

What kind of change does this PR introduce?

Clarification

Issue & Discussion References

• Closes 🧹 Clarification: usage of non-canonical identifiers in $schema #1590

Summary

Adds a requirement to $schema that its value cannot contain a fragment. This prevents someone from using a non-canonical IRI in this keyword.

Does this PR introduce a breaking change?

Technically, yes, but the likelyhood of people using fragments in $schema is low (probably non-zero, though).

[jdesrosiers]

I'm surprised to see a PR for this. I didn't think there was a consensus on this issue. The discussion just petered out without a clear resolution. I'm providing a review for this result, but I think we need to make sure this is the resolution we want before merging.

---

My first thought was that we can't do this because older dialect URIs use fragments, but then I realized I don't really know how this would affect older releases. It's a weird chicken and egg problem. I feel like $schema needs to be consistent across releases because it's what's used to determine which release to use. You don't know what version of $schema to use until you read its value.

I think that leaves us with two options: (1) allow (but discourage) an empty fragment, or (2) acknowledge the historic exceptions to the rule.

[jdesrosiers]

This can be called an "absolute IRI" instead of just an "IRI". Then we don't have to make a normative statement that a fragment isn't allowed because that's part of the definition of "absolute IRI". However, it might be a good idea to clarify that fact since most people think "absolute" just means "non-relative". Which means we shouldn't need to clarify that it mean "containing a scheme" anymore. Maybe something like this would work,

Suggested change

	[IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme). This
	IRI MUST be normalized and MUST NOT contain a fragment.
	[absolute IRI](https://www.rfc-editor.org/info/rfc3987) (without a fragment). This
	IRI MUST be normalized.

[karenetheridge]

I like option 2 -- it exactly covers what we want to do while accomodating the existence of older drafts.

We should still be able to disallow fragments (even empty ones), while still allowing the use of the draft7 and earlier schemas in a new implementation, even with a restriction in the metaschema itself (e.g. with the pattern keyword) -- as a schema should not be getting validated against a metaschema other than the one specified in the $schema keyword.

We would just need to point out the exception for older schemas, so the implementation doesn't reject the use of an empty fragment before considering if an older draft's semantics should apply.