Davis Bennett

> imho this recommendation is orthogonal to the main purpose of this PR, and it should come in a separate PR. I like it, but it's an extra thing and...

important to consider here that downstream libraries may pull in the schema documents by name for [testing](https://github.com/thewtex/ngff-zarr/blob/64c28f24e22b62965cd09a90309e400063ce7294/test/test_ngff_validation.py#L21). So some redirection or duplication would be necessary to avoid breaking those workflows...

see https://github.com/zarr-developers/zarr-python/pull/1898

> We are using DirectoryStore with dimension separator "/". In practice this should be equivalent as NestedDirectoryStore, since that is exactly what it does under the hood ([subclassing DirectoryStore](https://github.com/zarr-developers/zarr-python/blob/a81db0782535ba04c32c277102a6457d118a73e8/zarr/storage.py#L1581)). Perfect!...

> You reviewed and merged it (Thanks!). (edit: it is still broken for iohub because there has been no zarr release after that.) Lol, I totally forgot about this. 😆...

> I think one of the biggest shortfalls of Zarr V2 is the lack of codec standardisation. Numcodecs has many codecs, but they are not very useful if they are...

@normanrz could you elaborate on these points a bit? Do you think the spec should _require_ or merely _suggest_ that implementations support a fixed set of codecs? If you want...

> I think it is best to keep the codec spec in the Zarr spec. Is the current set of codecs inside the zarr spec? I think this is actually...

given that the zarr v3 spec document itself says that it [doesn't define a list of codecs](https://github.com/zarr-developers/zarr-specs/blob/81317acfc1441ff4274bcfbf67386e9852892969/docs/v3/core/v3.0.rst?plain=1#L1218C15-L1218C42) (and this claim is internally consistent -- that document does not in fact...

So it seems like most people in this conversation believe that the v3 spec should specify a set of codecs that Zarr implementations _must_ support. This is at variance with...