json-schema-org
Cover URI schemes in $id besides URL and URN
According to the spec, the $id attribute allows arbitrary URIs. The test suite covers URLs and URNs. It might be helpful to have a canary with another URI type, e.g. tag URI (which seems to be recommended over unregistered URNs):
"$id": "tag:foo.example,2025:bar/baz"
One of the existing URN test cases could be copied/repurposed to cover tag URI.
According to json-schema-validation-comparison as of 2025-11-25 (commit 895504e5), the following JVM implementations don't seem to handle tag URIs as expected: Jackson, Justify, Skema and Snow.
I don't see how the urn: tests are any less of a canary than tag: tests would be. Although it would be setting a better example to have tag: tests rather than urn: tests. I'm not seeing why we would need both.
According to json-schema-validation-comparison as of 2025-11-25 (commit 895504e5), the following JVM implementations don't seem to handle tag URIs as expected: Jackson, Justify, Skema and Snow.
Weird, I wonder what these implementations are doing that they would see some URI schemas as being different?
Weird, I wonder what these implementations are doing that they would see some URI schemas as being different?
I think most language's standard libraries implement WHATWG's URL rather than IETF's RFC 3986/7 (URI/IRI). Then JSON Schema implementers use that because they don't realize it's not the same thing or don't think the differences are worth including a dependency. WHATWG URLs require ://, so they can't support certain schemes that aren't defined to use :// like urn: and tag:. Fun fact: both file:/path and file:///path are valid IETF URIs, but only the later is a valid WHATWG URL.
I think these are implementations that are using WHATWG URLs instead of IETF URIs. I also think one example of a URI that doesn't have :// should be sufficient to clue implementation into the fact that they're using the wrong spec.
Ah, I just looked at the mentioned sKema issue and it seems to corroborate my suspicion. They have a workaround to specifically handle urn:. I'm guessing that workaround is because it doesn't support URIs without ://. That's how an implementation can seem to work for urn: but not tag: making it seem like it's a different case that needs its own test.
I wonder if having a test for an arbitrary, made up scheme (like foo:) might do more to discourage this kind of workaround and encourage using an implementation that supports URIs without ://.
Yes, there seems to be some bias to focus on URL and URN support exclusively, these two being the most familiar URI classes. tag URI just happens to be the use case that got me looking into this - I agree that a made up custom scheme might provide better coverage.
@sangamon Hi! i am new contributor to this project and preparing for GSsoc'26 this issue aligns with my tech stack can you please assign it to me.
@ShreyasN707: I don't think I'm in a position to assign any issues in this project. Furthermore, I don't think there's anything challenging at the implementation level here, there's just some justified deliberation about merits/demerits of the suggested change.
I wonder if having a test for an arbitrary, made up scheme (like foo:) might do more to discourage this kind of workaround and encourage using an implementation that supports URIs without ://.
We can't dynamically create schemes in the test suite, but this sounds like a great thing for bowtie! :)
I started a tread on Slack to try to get some more opinions on how to handle this case.
https://json-schema.slack.com/archives/C8CQ81GKF/p1764527326577729
Based on the feedback we got here and in the slack thread, I think we want to include tests for urn:, tag:, and something arbitrary (like foo:). The arbitrary scheme test should be clear (in the test case "description" or "comment" fields) that any arbitrary scheme should be supported.
We can't fully prevent implementers from hardcoding special cases, but we can at least make sure that the important cases are covered (urn:, tag:) and make sure that implementers are clear about what's expected.