Alistair Miles
Alistair Miles
The current storage spec in the section on “data type encoding” describes how the data type of an array should be encoded in the array metadata. Here is the content...
Reading [The Arrow C data interface](https://github.com/apache/arrow/blob/master/docs/source/format/CDataInterface.rst) I'm wondering if we should consider following any of the approach described there for the zarr v3.0 core protocol spec. In particular, the [format...
In the current v3 core protocol draft, chunk keys are formed by concatenating chunk indices without any zero padding, e.g., "0.0" and "100.200", etc. However, this means chunk files/objects do...
From @shoyer: What about indirection for chunks? The use case here is incrementally updated and/or versioned arrays (e.g., each day you update the last chunk with the latest data, without...
Assuming we want to at least migrate the [storage spec](https://zarr.readthedocs.io/en/stable/spec.html) versions 1 and 2, then: * [ ] Migrate the source files for the storage spec from the zarr (python)...
This issue is a starting point for discussing possible protocol extensions to allow support for various types of "awkward" arrays that do not fit into the model of arrays with...
This issue describes a concept for zarr v3 protocol extension which enables content-addressable storage to be layered on top of any underlying store. It is a thought experiment only, not...
Hi all, using this issue to capture some notes from experience of a very quick-and-dirty implementation of the v3 core protocol spec, [zarrita](https://github.com/alimanfoo/zarrita). I thought I would try a fresh...
This is a placeholder for a potential protocol extension to define sparse memory layouts for chunks. The idea is to enable use of a sparse memory layout (e.g., CSR, CSC...
Scope?
There are at least three types of spec that could live here: 1. [The zarr storage spec](https://zarr.readthedocs.io/en/stable/spec/v2.html). There have been two versions (1 and 2). Content currently lives in the...