Jonathan Striebel

For v3 the goal is to have a clearly addressable URI (see #132), and all relevant metadata how to open the hierarchy/group/array should be stored in clearly defined metadata. This...

IMO it's a benefit to know the underlying data layout easily to be able to reason about efficiency when traversing and indexing an array. C and Fortran order are well-known...

PS: Especially with #162 it's possible for clients to re-order the axes as needed and not rely on an expected order.

cross-referencing #138 and #46

Also referencing the consolidated metadata issue #136 here. I assume that this could be a v3 extension, right? Probably as an extension in the [entrypoint metadata](https://zarr-specs.readthedocs.io/en/latest/core/v3.0.html#entry-point-metadata), which would not be...

The [spec currently states](https://zarr-specs.readthedocs.io/en/latest/core/v3.0.html#abstract-store-interface): > A listable store supports any one or more of the following operations: So this includes that there may be stores that do not support deletion...

Thanks for the clarification @jakirkham! Do you think there's a TODO for the current v3 core spec from this issue? I'm re-opening it, but I'm not quite sure if this...

Since the zip store is currently not yet specified in v3 I assume this does not block ZEP 1, which is mostly about the core spec. Further clarifications can also...

I'm proposing to go forward with JSON encoding as the default for v3 for now, and explicitly allowing arbitrary JSON entries for a given key in the user-attributes, which itself...

Consolidated metadata for v3 is being discussed in #136. Marking this issue for the v2 discussion.