Skip to content

docs: add spec-style description of the consolidated metadata format - #4283

Draft
d-v-b wants to merge 6 commits into
zarr-developers:mainfrom
d-v-b:claude/docs-consolidated-metadata-spec-6f3c45
Draft

docs: add spec-style description of the consolidated metadata format#4283
d-v-b wants to merge 6 commits into
zarr-developers:mainfrom
d-v-b:claude/docs-consolidated-metadata-spec-6f3c45

Conversation

@d-v-b

@d-v-b d-v-b commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Summary

This is a claude-authored contribution that adds specification-style documentation for how zarr-python implements consolidated metadata. I'm pretty busy these days with a newborn baby so I can't give this careful review. I am opening this as a draft and leaving it to other folks to push it forward.

cc @normanrz

🤖 AI text below 🤖

Add a new user-guide page that describes exactly what zarr-python reads and writes for consolidated metadata in Zarr formats 2 and 3, so that other implementations can interoperate. Quotes and attributes the schema text from zarr-specs#309 (Tom Augspurger, CC-BY-4.0), documents the key ordering, the empty child-group marker, the v2 .zmetadata layout and its deviation from zarr-python 2.x, and the reader/writer procedures.

Also correct the 3.1.1 sort-order note on the existing page, which said "lexicographic" while the implementation uses NFKC-casefolded ordering.

Assisted-by: ClaudeCode:claude-fable-5

Author attestation

  • I am a human, these are my changes, and I have reviewed and understood every change and can explain why each is correct.

TODO

  • Add unit tests and/or doctests in docstrings
  • Add docstrings and API docs for any new/modified user-facing classes and functions
  • New/modified features documented in docs/user-guide/*.md
  • Changes documented as a new file in changes/
  • GitHub Actions have all passed
  • Test coverage is 100% (Codecov passes)

Add a new user-guide page that describes exactly what zarr-python reads
and writes for consolidated metadata in Zarr formats 2 and 3, so that
other implementations can interoperate. Quotes and attributes the schema
text from zarr-specs#309 (Tom Augspurger, CC-BY-4.0), documents the key
ordering, the empty child-group marker, the v2 `.zmetadata` layout and
its deviation from zarr-python 2.x, and the reader/writer procedures.

Also correct the 3.1.1 sort-order note on the existing page, which said
"lexicographic" while the implementation uses NFKC-casefolded ordering.

Assisted-by: ClaudeCode:claude-fable-5
@github-actions github-actions Bot added the needs release notes Automatically applied to PRs which haven't added release notes label Aug 25, 2026
@d-v-b

d-v-b commented Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

@TomAugspurger you should probably also have a look, since this is an LLM summarizing your work

@TomAugspurger

Copy link
Copy Markdown
Contributor

I'm pretty busy these days with a newborn baby so I can't give this careful review.

Congrats! I'll take a look when I get a chance.

Do you have any more info on the motivation for this document. I gather it's primarily for other implementations looking to interoperate with what we write, and am trying to balance this approach vs. telling them to read the spec + source code :)

@normanrz

Copy link
Copy Markdown
Member

I asked for a spec on Zulip and Davis was kind enough to create one. The motivation is that we picked up the consolidated metadata in the newly-formed Zarr Format Working Group and I wanted to get a better understanding of the current zarr-python implementation. Having a spec here would be great, but even better would be if we could eventually bring this document into the Zarr 3 spec.

@d-v-b

d-v-b commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

Do you have any more info on the motivation for this document. I gather it's primarily for other implementations looking to interoperate with what we write, and am trying to balance this approach vs. telling them to read the spec + source code :)

IMO we don't really have a place for a consolidated metadata spec in the zarr-specs repo until we unblock the blockage that prevented your original PR from getting merged in some form or another. For folks curious about the normative structure of consolidated metadata, but also zarr-python's particular implementation choices, I think some kind of document in our docs is a good play. Long term our goal should be to replace an actual spec with a link to a spec defined elsewhere.

@normanrz

Copy link
Copy Markdown
Member

IMO we don't really have a place for a consolidated metadata spec in the zarr-specs repo until we unblock the blockage that prevented your original PR from getting merged in some form or another.

Right. With @joshmoore, I am working on a proposal for the ZFWG governance and I could imagine using consolidated metadata as testcase for the governance process.

@TomAugspurger TomAugspurger left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the context. With that in mind, I'll view this as a somewhat temporary document. Though just merging the zarr-specs PR feels infinitely better.

And for those interested in the implementation, rereading the discussion in #2113 might also be fruitful.

Comment thread docs/user-guide/consolidated_metadata_format.md Outdated
Comment thread docs/user-guide/consolidated_metadata_format.md Outdated
Consolidated metadata essentially stores all the metadata for a hierarchy in the
metadata of the root Group.

This page describes how to use consolidated metadata from Python. For a precise

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some hesitancy about linking to this document from user-facing docs. I think the spec (or the PR for the spec) should be sufficient for users, and if it isn't then the docs should be improved there.

Comment on lines +91 to +93
of strings joined by `"/"`. For keys with the same depth, the tie is broken by
comparing the paths after Unicode NFKC normalization and case-folding. This
behavior ensures deterministic metadata output for a given group.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems worse for causal readers.

Let's at least keep "lexicographic" (since it isn't incorrect, right?) And if we want to be more specific we can, but let's link to the Python docs on normalization.


## Concepts

A hierarchy is **consolidated at** a group (the *consolidating group*). The

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"consolidating group" isn't a term in zarr-developers/zarr-specs#309. If we want to make it one, let's propose it there.

Comment on lines +66 to +69
(`GroupMetadata.consolidated_metadata.metadata`). It is never written to a
store and is mentioned here only because it leaks into the on-disk form in
one place (the [empty child marker](#child-groups-carry-an-empty-marker)).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think "leaks into" is accurate here, or it conveys the wrong impression. That's deliberate, saying that there aren't any children.


## Paths

A **path** is the name of a node relative to the consolidating group:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC paths are already defined in the spec. Link to that.

at `B` produces `C`, `y`; consolidating at `C` produces no paths (an empty
mapping, which is still written).

!!! note "Difference from the zarr-specs#309 text"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha, I had a review pending from April 2025 pointing out this issue. Submitted that: zarr-developers/zarr-specs#309 (comment) and we can fix it in the spec.

Each value is a complete node metadata document, i.e. exactly what would be
found in that node's own `zarr.json`, with the following rules:

* The document MUST contain `zarr_format`. Readers discriminate on this first;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this isn't intended / well-tested.

Comment on lines +188 to +190
This is the one place the nested in-memory form shows through. The marker
does **not** mean the child group has no children: the child's descendants are
still listed in the flat mapping at the consolidating group. It exists so

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong (or I'm misunderstanding something). But AFAIK the presence of metadata: {} definitely does indicate a group with no children.

d-v-b and others added 2 commits August 30, 2026 22:22
Co-authored-by: Tom Augspurger <tom.augspurger88@gmail.com>
Co-authored-by: Tom Augspurger <tom.augspurger88@gmail.com>
@codecov

codecov Bot commented Aug 30, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.21%. Comparing base (5b5f3a3) to head (c1bae56).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4283   +/-   ##
=======================================
  Coverage   94.21%   94.21%           
=======================================
  Files          92       92           
  Lines       12861    12861           
=======================================
  Hits        12117    12117           
  Misses        744      744           
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs release notes Automatically applied to PRs which haven't added release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants