Start a roadmap

[dstansby]

This is very much a suggestion, apart from I think we should aim for v1 to have OME-zarr 0.4 validation. Open questions:

• Should v1 include metadata writing?
• What else should happen after v1?

[imagejan]

At some point in the future, I think it would be nice if the versions of this package (a reference implementation) would align with the versions of the NGFF spec (such that v0.4 would contain the data models for OME-Zarr 0.4, and v0.5 would contain the data models for both OME-Zarr 0.4 and 0.5, etc.), just to avoid confusion with all the different packages and versions. Or do you think this is asking for too much?

[d-v-b]

At some point in the future, I think it would be nice if the versions of this package (a reference implementation) would align with the versions of the NGFF spec (such that v0.4 would contain the data models for OME-Zarr 0.4, and v0.5 would contain the data models for both OME-Zarr 0.4 and 0.5, etc.), just to avoid confusion with all the different packages and versions. Or do you think this is asking for too much?

I think we have to version our package independently from the OME-Zarr versions. If the versions are locked together, then it's hard for us to issue patch releases or bugfixes.

[dstansby]

To add, our plan is to have different namespaces for different versions of the OME-zarr spec, so currently we have a ome_zarr_models.v04 namespace, but we'll add v05, v06 etc. to this in time.

[d-v-b]

• Should v1 include metadata writing?

Yes, and in a simple form we have metadata writing today -- any class that inherits from GroupSpec has a to_zarr(store, path) method that will create an OME Zarr group (and zarr arrays) in the provided storage backend. we could make this fancier, e.g. by only writing group attributes (but still checking that the entire zarr group is valid).

I think a MVP for this repo should be sufficient to easily read an OME-Zarr image from storage, make some changes to that metadata, and save a new OME-Zarr image to a different storage backend with those changes. That should cover the spectrum of basic use cases, I think, and I don't think we are too far from that tbh