You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I import a schema from schemastore, it should define exactly one top level URL, with all subschemas available as fragment references (potentially anchors or plain-name fragment IDs) within that. That makes it clear that schemas will not step on one another's toes by defining a schema in another namespace. Although it's possible for schemas to do that, it doesn't seem to be good practice.
I noticed this being an issue when investigating #4063, and wrote a little program to find all such cases. The program also looked for any use (via $ref) of such IDs.
Here's a summary the places where the program found instances of IDs defined outside the schema's namespace, places where IDs were declared that duplicated other schema IDs in schemastore, and places where any of those IDs were actually used.
We can see that in practice nothing in the schema store seems to be relying on these ID definitions (the only exception being the internal references inside base.json and base-04.json.
Although there is the possibility that external users are relying on these IDs, I suspect that they're unlikely to be, and if they are, then they should not be.
I suggest that we remove all such $id definitions and change the $ref references in base*.json to use regular fragment identifiers.
❌ Actual Behavior
Duplicate IDs will lead to inappropriate/undefined behavior if multiple such schemas are combined.
YAML or JSON file that does not work.
N/A
IDE or code editor.
None
Are you making a PR for this?
Yes, I will create a PR.
The text was updated successfully, but these errors were encountered:
rogpeppe
added a commit
to rogpeppe-contrib/schemastore
that referenced
this issue
Sep 13, 2024
This removes `$id` definitions from schemas where
those IDs are defining schemas outside of the schema URI itself.
The problem this is fixing is summarized in SchemaStore#4073.
FixesSchemaStore#4073.
Area with issue?
JSON Schema
✔️ Expected Behavior
When I import a schema from schemastore, it should define exactly one top level URL, with all subschemas available as fragment references (potentially anchors or plain-name fragment IDs) within that. That makes it clear that schemas will not step on one another's toes by defining a schema in another namespace. Although it's possible for schemas to do that, it doesn't seem to be good practice.
I noticed this being an issue when investigating #4063, and wrote a little program to find all such cases. The program also looked for any use (via
$ref
) of such IDs.Here's a summary the places where the program found instances of IDs defined outside the schema's namespace, places where IDs were declared that duplicated other schema IDs in schemastore, and places where any of those IDs were actually used.
File position summary
We can see that in practice nothing in the schema store seems to be relying on these ID definitions (the only exception being the internal references inside
base.json
andbase-04.json
.Although there is the possibility that external users are relying on these IDs, I suspect that they're unlikely to be, and if they are, then they should not be.
I suggest that we remove all such
$id
definitions and change the$ref
references inbase*.json
to use regular fragment identifiers.❌ Actual Behavior
Duplicate IDs will lead to inappropriate/undefined behavior if multiple such schemas are combined.
YAML or JSON file that does not work.
N/A
IDE or code editor.
None
Are you making a PR for this?
Yes, I will create a PR.
The text was updated successfully, but these errors were encountered: