Should extension keywords be able to assign IRIs to schemas at all?

[handrews]

Issue #1304 proposes forbidding extension keywords from being able to create embedded resources or change the base IRI.

Should extension keywords be able to assign IRIs at all? Assigning an IRI means that it can be used in $ref or any other keyword or feature that references schemas by IRIs.

Assigning full IRIs

We are not clear about it, but $id functions similarly to a "self" link relation type (and in the earliest drafts of JSON [Hyper-]Schema when Schema and Hyper-Schema were the same spec, using links with "rel": "self" was how this functionality worked.

Any other keyword would need to assign IRIs with a different link relation type, making it essentially a reflexive (applying to the schema instead of the instance) version of Hyper-Schema's links keyword. In which case I think it would be considered an annotation- information that can be used by the application, but not something that creates $ref-able identifiers.

Assigning fragments

JSON Pointer fragments cannot be assigned, as they are inherent in the JSON structure. We removed the aspect of $id that made it seem like you could assign them. It seems clear to me that we should clarify that no keyword can ever assign JSON Pointer fragments.

Plain name fragments are created by $anchor and (in 2020-12) by $dynamicAnchor. #1140 would remove this capability from $dynamicAnchor. Recent discussions on Slack have also highlighted how the fragment-creating behavior (and the related behavior of $dynamicRef working like $ref if it targets anything other than a $dynamicAnchor-created fragment) is egregiously confusing. Which I think proves that we should forbid other keywords from creating such fragments.

Leaning towards "no"

I think we should forbid this, not just for extension keywords but for any future JSON Schema Org keywords as well.

[handrews]

Closing in favor of the referencing discussion, can be re-filed if needed once that resolves.