Keyword URIs

[gregsdennis]

Branching off of #1401, we should discuss the idea of assigning URIs to keywords.

This could enable a number of things:

• keyword aliasing via custom vocabularies
• keyword identification in output
• resolving collisions between vocabularies (potentially via aliasing)
• ad-hoc vocabularies defined in meta-schemas

One thing that the other discussion raised was the ability to use the keyword URI in place of the keyword itself as a way to support collision resolution. E.g.

{
  "https://json-schema.org/keywords/type": "string",
  "https://example.com/keywords/type": "person",
}

My hesitation with this is that I doubt it would be needed often enough that implementors will want to support it. Additionally, if keyword aliasing is a thing, then maybe we don't need this. That said, I don't see any conflict in supporting it; I only question its value.

This issue is to discuss whether we assign URIs to keywords. It's clear to me that there's value in doing this. Is there sufficient value for the effort?

I'd like to keep the mechanics of features this could potentially enable off-topic, though I don't mind enumerating them. Supposing we move forward with this, other issues could be opened to discuss each one in more detail.

(Also relates to #1065, #911, #918)

[jdesrosiers]

Is there sufficient value for the effort?

That's a good question. Ultimately, this only enables features that power users would use and only fixes problems that power users will encounter. So, the impact of this change would be fairly low. However, I think the effort required for introducing this is very low, so why not do it for the power users.

[gregsdennis]

There's an interesting question about how we'd URI-ify the core keywords since $ is a reserved character. I mean, we can still use something like https://json-schema.org/keywords/$id, but would we really want to?

[jdesrosiers]

For the URIs I use in my implementation, I drop the $.