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.

    • 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.