Cover URI schemes in $id besides URL and URN

[sangamon]

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.

[jdesrosiers]

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.

[karenetheridge]

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?

[jdesrosiers]

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.

[jdesrosiers]

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 ://.