Jonathan Striebel

See also the comments in #74.

Since the entrypoint semantic might be removed (see #192), there's no need to have a separate part of a URL for the entrpoint and the array anymore. Instead, we could...

> For example, I'd much rather have the canonical URL be file:///my/path/to/a/group/inner_array/zarr.json. Fine for me as well, no strong opinion here. > It's trivial for implementations to strip the zarr.json...

> We don't have any specific examples of group-level storage transformers yet, but with any group-level storage transformer, we do need the URL to separately indicate the location to at...

I would have assumed that this would be a separate spec under [data-types](https://zarr-specs.readthedocs.io/en/latest/v3/data-types.html), since it's optional. I can see that this is a lot of boilerplate for a rather simple...

This is the relevant ZEP 3 that proposes variable sized chunks: https://zarr.dev/zeps/draft/ZEP0003.html. Would this potentially solve this use case? Then we should also link this issue there. cc @martindurant

@rabernat Do you have any preferences, e.g. should the python implementation change or rather the spec? I don't have a strong opinion which version is more appropriate, but agree that...

After re-reading this part of the spec, I think that the `/` suffix is useful in the API, especially to make this definition as simple as it is: > Retrieve...

@rabernat @joshmoore Do you have any concrete proposals for the current spec? Happy to do a review, but I'm not quite sure what exactly should be changed.

I'm wondering if it should be a core feature to have the `attributes` separate, or if it could be an extension. Any opinions on that? If it's supposed to be...