Extension points

[normanrz]

As we move toward OME-Zarr 1.0, we want to provide enough extension points in the specification to avoid having to issue breaking changes in new specification versions.
As a preparation, I though it would be useful to collect a list of extension points that emerge from the various in-flight RFCs:

Metadata field	RFC	Useful for
axes -> type	RFC-5	new image axis types
axes -> unit	RFC-5	new image axis unit types (e.g. in combination with a new axis type)
coordinateTransforms -> type	RFC-5	new coordinate transformations, (e.g. thin-plate-spline transforms)
coordinateTransforms -> type = coordinates or type = displacement -> interpolation	RFC-5	new interpolation types
axes -> orientation -> type	RFC-4	new orientation type
nodes -> type	RFC-8	new node type, e.g. tables, meshes
nodes -> attributes	RFC-8	custom metadata for nodes in a collection

These extension points would allow any implementor to add new functionality within the scope of the extension points. In the case of collection node types and attributes that would be quite broad. To manage the namespace, an idea is to use prefixes separated by a colon (:). There would be a central repository where implementors or users can register their prefix (e.g., mobie:, neuroglancer:, fractal:, webknossos:).
Unprefixed names would be reserved for in-spec types/attributes/etc. and would need to be added via the RFC process. This would allow for a progression from prefixed extension (for experimentation and customization) to standardized in-spec feature.

[jo-mueller]

Another motivator for introducing namespaces: It would allow us to use vocabulary that has been well-defined elsewhere and make the ngff specification compatible and discoverable for a bunch of other tools. See for example the specification of croissant, which makes use of the following namespaces:

Prefix	IRI	Description
sc	http://schema.org/	The schema.org namespace.
dct	http://purl.org/dc/terms/	Dublin Core terms.
wd	http://www.wikidata.org/wiki/	Wikidata namespace