zarr-metadata: ship definitions for zarr-python's registered extension data types #423

🤖 AI text below 🤖

zarr-metadata ships no DataTypeDefinitions for the extension data types zarr-python itself registers and writes — fixed_length_utf32, null_terminated_bytes, and friends. Any strict scope (pydantic-zarr's zarr_scope_strict) over a store zarr-python wrote therefore refuses genuine documents until the consumer defines those types themselves.

This was hit while building strict validation for Sentinel-2 GeoZarr stores in EOPF-Explorer/data-model#330: real products hold fixed-length unicode band/angle coordinates (numpy U, stored as fixed_length_utf32) and fixed-length bytes arrays (numpy S, stored as null_terminated_bytes). Strict validation of these stores was impossible against CORE_AND_EXTENSIONS alone; the consumer-side workaround lives in data_api/geozarr/scope.py — two DataTypeDefinitions plus hand-written FixedLengthUtf32Object / NullTerminatedBytesObject TypedDicts mirroring the shape of the per-extension *Object types.

The ask: ship definitions for zarr-python's registered data types, together with their *Object TypedDicts. Since the spellings are provisional, an opt-in scope (e.g. ZARR_PYTHON_EXTENSIONS) alongside CORE_AND_EXTENSIONS would keep the default scope spec-pure while making strict validation usable on stores zarr-python writes — which is most stores.