Jonathan Striebel

If there are no objections, I'd leave this as an extension (TBD) for now.

Just as a note: This was also discussed in issue #131, and the data type names of the v3 spec were updated in PR #155 to be `uint32`, `float64` etc…...

Issue #141 is directly related. Besides changes to the spec specifically making it possible to encode such values somehow, this should probably be moved to zarr-python, do you agree @joshmoore?

The v3 spec defines partial chunk reads and writes, not discussing interactions with codecs so far: https://zarr-specs.readthedocs.io/en/latest/core/v3.0.html#abstract-store-interface It would be great to specifically note if and how partial reads and...

Zero-padding up to a user-specified length seems like a good extension. I'm not sure if this needs to be part of the core though, I think it could be added...

The syntax is now consistent with "bfloat16" as of #155. I'd propose to add bfloat16 as a dtype extension, as it could not easily be supported by zarr-python without requiring...

@Carreau Does the current extension points of [storage transformers](https://zarr-specs.readthedocs.io/en/latest/core/v3.0.html#id19) in the v3 spec provide the flexibility needed to adapt to different key-formats? If so, I'd close this issue for now.

see also #141 and #81

Atm, object data type is not supported in v3 and might be added as an extension. So this is mostly a v2 issue for now I assume

Cross-referencing #138