Consider to remove entrypoint metadata, do not specify root

[jstriebel]

During the last ZEP meeting we discussed if it's possible and useful to not have an explicit root of a zarr hierarchy. See the meeting notes here.

This would include to drop the global /meta and /data prefix as described in #177, but possibly also the entrypoint metadata.

This discussion is directly related to those comments: #177 (comment)

I'll try to summarize the arguments:

Pro explicit root

• A zarr hierarchy has a clear address.
• Global extensions which move/change metadata (e.g. consolidated metadata) can be configured via the entrypoint metadata. Entrypoint metadata can be a good "gateway" to set up arbitrary extensions, without needing to find any other metadata first.

Contra explicit root

• Groups and arrays can be moved anywhere and still are valid groups/arrays (but extensions would need to be part of all respective metadata). (Let's refer to this as nesting invariance.)
• Any extensions which don't affect the metadata can be (and then maybe should be) copied into all contained arrays.

---

One particular case that changes some of these arguments is introducing group-wise extensions, e.g. consolidated metadata within an arbitrary sub-group of a hierarchy. This would weaken nesting invariance, as only the whole group with the extension can be moved freely. E.g. moving any array in the group with consolidated metadata would require an update of the metadata. However, if extensions don't affect metadata, it would be very pratical to simply copy all extensions into the respective arrays.

---

My currently favoured strategy would be:

• Remove the explicit entrypoint metadata
• Move the relevant metadata into the groups:
  • Probably drop metadata encoding (v3 spec: Consider removing metadata encoding #174)
  • zarr_format in all group and array metadata
  • extensions in (relevant or all) group and array metadata
• Implicit groups are always opened via their next explicit parent group, arrays w/o metadata must look up extensions in their parent group
  • The topmost entry of a group hierarchy must be explicit (similar to current entrypoint), e.g. if a collection of arrays should be openable as a group, the topmost group must have metadate, e.g. to specify the zarr version.
  • The strategy for implementations would be to traverse the store hierarchy upwards from any given url, until array or group metadata is found.

---

cc all participants of the last zep call: @MSanKeys963 @joshmoore @jbms @WardF @DennisHeimbigner @rabernat

[jstriebel]

Let's discuss this in the next ZEP meeting tomorrow, so far no objections have been raised. cc @zarr-developers/implementation-council