Implementation of object reference in JSON schema

[smrgeoinfo]

summary from Claude for future reference:
The problem:
id-reference today is:

id-reference:
  type: object
  properties:
    '@id': { type: string }
  required: ['@id']

The bug: the lenient branch swallows everything
anyOf passes if the value matches at least one branch. id-reference only requires @id and permits any other properties (no additionalProperties: false). But a real inline structure should carry an @id too — that's how other parts of the document reference it (a shared layout stated once, referenced by the rest).

So an inline DimensionalDataStructure that carries an @id matches both the DimensionalDataStructure branch and the id-reference branch. If the inline structure is malformed — say a component missing its required @type — it fails the DimensionalDataStructure branch but still passes id-reference (it has an @id), so anyOf overall passes and the error is masked. The structure's contents are never actually validated.

Example of problem:

"cdi:isStructuredBy": {
  "@id": "ex:struct-1",
  "@type": ["cdi:DimensionalDataStructure"],
  "cdi:has_DataStructureComponent": [ { "cdif:name": "broken" } ]   // ← no @type, invalid
}

→ validates GREEN (matched id-reference on @id alone). Remove the @id and it correctly fails — proving the @id was the escape hatch.

The fix
Add additionalProperties: false to id-reference:

id-reference:
  type: object
  properties:
    '@id': { type: string }
  required: ['@id']
  additionalProperties: false      # ← only {@id} matches this branch

Now id-reference matches only a bare {"@id": "..."}. An inline structure has @type, cdi:has_DataStructureComponent, schema:name, … — all "additional properties" — so it no longer matches id-reference and must satisfy a real DataStructure branch, where its components are deeply validated. The malformed example above would now fail, as it should.

This update propagates through almost all of the JSON schema implementations....