Skip to content
This repository was archived by the owner on Dec 28, 2025. It is now read-only.
This repository was archived by the owner on Dec 28, 2025. It is now read-only.

"$id" is (slightly) non-compliant (hidden by errors in JSON Schema Test Suite) #69

@handrews

Description

@handrews

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions