RFC 089: record how ontology types outside the enum are handled - #173
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2 tasks done
kenoir
approved these changes
Oct 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Preview
What does this change?
Resolves wellcomecollection/platform#6537.
Open question 6 scoped the
typeenum toWork/Image/Itembut did not say what happens to registry rows of other types, such asConcept, which the API was returning in responses that failed its own spec. It now records the behaviour implemented in wellcomecollection/catalogue-api#1023: a canonical id whose original row is outside the enum is a404, and other out-of-enum rows are omitted from the identifier set. The original is chosen before rows are omitted, so the top-leveltypefrom open question 7 keeps its meaning.The status codes paragraph, the ETag description in the caching section and the "aliases toggle" out-of-scope note are updated to match.
How to test
Read the amended open question 6 and status codes paragraph in the preview above, and compare them with
identifiers/spec/openapi.yamlin catalogue-api.validate_rfc.pyandcreate_table_summary.py --check-readmeboth pass locally.How can we measure success?
The RFC and the deployed spec describe the same behaviour for out-of-enum types.
Have we considered potential risks?
Documentation only. No decisions other than open question 6 change.
Generated with Claude Code