URI Schemes term restriction is fairly draconian

[hsolbrig]

Section 9.1 Terms asserts:

"When used as the prefix in a Compact IRI, to avoid the potential ambiguity of a prefix being confused with an IRI scheme, terms MUST NOT come from the list of URI schemes as defined in [IANA-URI-SCHEMES]."

This appears to be quite restrictive, as prohibits "aaa", "nih" and more than 100 other seemingly innocuous terms. At the moment, the playground implementation doesn't enforce this (thank goodness). Should this constraint be weakened to a suggestion rather than a prohibition?

[gkellogg]

This is really for publishers of JSON-LD data rather than consumers. There are other steps we take to prevent IRIs from being misinterpreted as compact IRIs, and we may not need to make such blanket statements.

That said, creating a term "https" which can be used as a prefix would be a bad idea.

[TallTed]

This becomes more problematic when one considers the indeterminate future -- wherein any number of terms may be added to the list at [IANA-URI-SCHEMES] after having been used in JSON-LD documents created in the meantime.

Yes, using https (among others) would likely be a bad idea -- and some warning of the impact of such collisions, both current and future, should be included. But the current blanket forbiddance is problematic and unnecessarily strict.

At minimum, this MUST NOT should be reduced to a SHOULD NOT.

[azaroth42]

I believe this is an editorial oversight covered by previous resolutions. See:

147, #148, #155, #177 for highly related issues.

MUST NOT is impossible to enforce, as discussed during the above issues and as an untestable feature we should have fixed it during the resolution of those issues.

[azaroth42]

Resolved by #315. Closing.