Allow . as the dimension separator

[jstriebel]

Since v0.2, / is the only allowed dimension separator for OME NGFF chunk paths. To be compatible with Zarr arrays in general, it would be great to also allow . as the dimension separator, depending on the Zarr metadata if available.

This allows to add OME metadata to existing Zarr arrays, that already use the . dimension separator.

[joshmoore]

Thanks for capturing this, @jstriebel. I can't remember if I mentioned to you or to Norman but for everyone: the hard requirement on a single separator was required while the dimension_separator addition was being add to the Zarr v2 spec. At this point, I think it's fine to drop. If either of you want to drive that, please feel free. The major caveat will be that the implementations will need to be updated as well.

(There have also been requests to support Zip-based NGFFs which will touch the same code paths.)

[normanrz]

We are happy to drive this.
Fwiw, I wouldn't interpret the current spec to have a strict / requirement, because it is not explicitly mentioned. Other parts of the Zarr spec are also not re-defined in the OME-NGFF spec, so, I would assume all features of zarr v2 are valid. Most implementations that support OME-NGFF already support ., because of their underlying zarr implementations.

[joshmoore]

Then we're looking at different implementations which is a good realization itself 😄

 │   └─ t                  # Chunks are stored with the nested directory layout.

[normanrz]

I see. To me the directory listing seemed more like an example section than a normative section.