[Change request]: Clarification on nullibillity of Identifier

[bartvriesema]

Organization

Maastricht University

Project

OEAPIv6

Contact Details

No response

Short description

Currently I am working on implementing the OEAPIv6 specification in .NET, and I run into an unclear part of the specification. This issue seems to be present in multiple entities that reference ./Identifier.yaml and that uses the oneOf expand functionality.

For example in ./Organisation.yaml there is a field parentId that references the Identifier.yaml which requires a UUID. But if no parentId is present it does not explain what to do. We could omit this field in the response, but that does not adhere to the text representing this field as it implies it contains a value. And the Identifier.yaml doesn't allow null values.

The field parent which contains either the full object or a null value, does allow for returning a null value. And is therefore clear in its intention.

Version

v6

Usecase

It would solve an inconsistency in what to do with null values of parentId, but it also applies to rootid

Which institutions support this change?

No response

Proposed solution

Clarify what to do with null values of Identifiers

Requests and responses

No response

What is your question for the OOAPI work group?

No response

[bartvriesema]

While investigating this further, we found a related but distinct problem on the other side of these relationships: the expanded-object fields (parent, organisation, course, etc.) declare type: [object, 'null'] correctly, but also wrap the $ref in allOf. Since allOf requires the instance to satisfy every subschema, and the referenced schema (e.g. Organisation) itself only allows type: object, null can actually never validate against these fields either — despite the type array claiming otherwise. That's tracked separately in #601, which already proposes the fix (oneOf instead of allOf).

Both issues stem from the same underlying gap — declared/intended null-allowance for optional relationships isn't fully reflected in the JSON Schema — just surfacing on different sides of the same fields (parentId here vs. parent in #601). Flagging the connection in case it's useful for prioritizing or batching a fix.