27th May, 2020
Dennis, Matthias, Ryan W, John K, Josh (very late)
Non standard community call, high bandwidth discussion about spec v3.
- Some misc suggestions: See https://github.com/zarr-developers/zarr-specs/pull/71/files
-
Overview:
- **Standing items: **
-
-
Base raw types
- r+ number of bits/bytes.
- Non multiple of 8 ?
- There might be interest in allowing fewer than 8 bits for categorical.
- Non multiple of 2 ?
- Dennis: Type def like style ?
- Dennis core: variable length type.
-
Extensions:
-
How to declare dependencies
-
Should all extensions be listed in the top metadata document and referred to in .group .array with only their URL
- Pros: avoid to check all intermediate path for a
.group/.array and read it to see if it can be understood.
- Cons: complicated on deletion, disallow different
extensions in same hierarchy.
- Pros: avoid to check all intermediate path for a
-
Is must_understand too restrictive for extensions that only apply to a group .subgroup ?
-
Fill_values for extension fallback 0b -0x ?
-
List of some possible extension examples (in the context of a proposal around a specific extension-framework implementation, from discussions w Josh+John at CZI summit in February)
-
-
Seem to be fine, but josh ask about link to remote linked datasets ?
It might be fine to assume that remote is it’s own dataset.
-
-
Stores: Strictness of API.
- Can store assume queries are valid ?
- Group keys always ending in / ?
- Suggestion of `delete_prefix`
- Strictness of what is accepted by stores (bytes, bytesarray, numpy arrays…) and returned.
-
Extensions :
-
Types,
-
Attributes.
-
Extra objects.
-
Checksum example. Checksum are kind of a filter.