api
api copied to clipboard
IIIF
Define process for accepting entries for registries
#1310 created several registries, including for extensions, services, profiles, types, motivations and others. We need a process defined for:
- How are entries suggested for inclusion?
- What are the possible features for each entry?
- What makes an appropriate / inappropriate entry?
- How is that judgement arrived at in a transparent and fair fashion?
Some thoughts:
Suggestions: issues, PRs or on iiif-discuss.
Features: The string to use in the JSON-LD, the context that defines the mapping, reference to the specification that defines the feature, an example to use in a cookbook / pointer to a cookbook entry, short descriptive text.
Good Entries: All of the above features, plus two publishing implementations and one consuming implementation. Doesn't duplicate any existing entry or core feature. Is appropriate to the registry (not putting profiles into services etc).
Judgement: Lacking any sort of technical review committee ... it probably has to fall to the editors. Discussion according to the above requirements in the same channel as the submission, with the same requirement as any normative change (no -1s, all but one +1).
Process above sounds good to me. I agree that until we change to something like a technical review committee, the editors are tasked with finalizing the decisions (informed by technical assessment and community agreement) as with any normative change.
In AV group meeting:
Concern over community agreement on process holding up Presentation 3 spec
How to handle breaking changes in extensions? - versioning best practices Who is the maintainer of an extension? How does an extension get de-listed? What happens if its @context is missing? Should IIIF host @contexts? Probably not - unless the extension has come from a TSG sponsored by IIIF. Text Granularity group.
The registry is not a forum for developing community extensions, it's for institutions to publish their extensions, describe them.
