In 2019-09 and 2020-12, the constraints on the value of "$id" are:
- SHOULD be normalized
- MUST NOT have a non-empty fragment
- SHOULD NOT have an empty fragment
Therefore a compliant implementation is expected to support "$id" with non-normalized and/or empty-fragment-having URI-references, as documented by several tests in the test suite:
The only reason jschon passes these tests is that they put the $id in question in the data rather than in the schema, while making the schema a reference to the standard meta-schema. Which means that all these tests do is test that the data is valid against the meta-schema, which of course it is....
...except in draft-next where fragments are no longer allowed, which is enforced by the meta-schema, causing the $id-with-fragment tests to fail on draft-next (no matter what jschon is or isn't doing). This is how I figured out what was happening.
@marksparkza , I definitely get wanting to forbid these cases (goodness knows I've wanted to for many years), but as a matter of compliance they need to be allowed. There could be opt-in enforcement of additional rules for this (and perhaps #64 / #66 regarding non-plain-name-fragment $refs), as something of a built-in linter.
However, as can be seen on the implementations page (look for This implementation documents), non-compliant default behavior will be flagged.