diff --git a/0.1/index.bs b/0.1/index.bs index 7cb79539..e044a74f 100644 --- a/0.1/index.bs +++ b/0.1/index.bs @@ -364,7 +364,7 @@ custom attributes of the plate group under the `plate` key. For example the following JSON object defines a plate with two acquisition and -6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion. +6 wells (2 rows and 3 columns), containing up 2 fields of view per acquisition. ```json "plate": { diff --git a/0.2/index.bs b/0.2/index.bs index e8e5a7bd..64c07c78 100644 --- a/0.2/index.bs +++ b/0.2/index.bs @@ -419,7 +419,7 @@ custom attributes of the plate group under the `plate` key. For example the following JSON object defines a plate with two acquisition and -6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion. +6 wells (2 rows and 3 columns), containing up 2 fields of view per acquisition. ```json "plate": { diff --git a/0.3/index.bs b/0.3/index.bs index ed424f62..0f64fbe0 100644 --- a/0.3/index.bs +++ b/0.3/index.bs @@ -432,7 +432,7 @@ custom attributes of the plate group under the `plate` key. For example the following JSON object defines a plate with two acquisition and -6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion. +6 wells (2 rows and 3 columns), containing up 2 fields of view per acquisition. ```json "plate": { diff --git a/about/index.md b/about/index.md index 75c6c88e..855ecd60 100644 --- a/about/index.md +++ b/about/index.md @@ -40,9 +40,9 @@ parallelization. As a result, a number of formats have been developed more recently which provide the basic data structure of an HDF5 file, but do so in a more cloud-friendly way. -In the [PyData](https://pydata.org/) community, the Zarr [[zarr]] format was developed +In the [PyData](https://pydata.org/) community, the [Zarr](https://zarr.dev/) format was developed for easily storing collections of [NumPy](https://numpy.org/) arrays. In the -[ImageJ](https://imagej.net/) community, N5 [[n5]] was developed to work around +[ImageJ](https://imagej.net/) community, [N5](https://github.com/saalfeldlab/n5) was developed to work around the limitations of HDF5 ("N5" was originally short for "Not-HDF5"). Both of these formats permit storing individual chunks of data either locally in separate files or in cloud-based object stores as separate keys. diff --git a/data/index.md b/data/index.md index f4cdcec0..be0f179e 100644 --- a/data/index.md +++ b/data/index.md @@ -7,6 +7,7 @@ Data Resources | [Cell Painting Gallery](https://github.com/broadinstitute/cellpainting-gallery) | AWS Open Data Program | 136 | 20 TB | | [CZB-Zebrahub](https://zebrahub.ds.czbiohub.org/imaging) | czbiohub | 5 | 1.2 TB | | [DANDI](https://dandiarchive.org/dandiset/000108) ([identifiers.org][dandi2],[github][dandi3]) | AWS Open Data Program | 3914 | 355 TB | +| [JAX](https://images.jax.org/webclient/userdata/?experimenter=-1) | The Jackson Laboratory | 17000 | 192 TB | | [Glencoe](https://glencoesoftware.com/ngff) | Glencoe Software, Inc. | 8 | 165 GB | | [IDR Samples](https://idr.github.io/ome-ngff-samples/) | EBI | 88 | 3 TB | | [MoBIE](https://mobie.github.io/specs/ngff.html) | EMBL-HD | 21 | 2 TB | diff --git a/rfc/1/index.md b/rfc/1/index.md index 903b71a7..99d6b589 100644 --- a/rfc/1/index.md +++ b/rfc/1/index.md @@ -78,7 +78,7 @@ Additionally, not all decisions in the NGFF community need to follow the RFC pro The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in IETF RFC 2119. +interpreted as described in IETF [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). ## Stakeholders diff --git a/rfc/1/review_1.md b/rfc/1/review_1.md index 79868de3..5a471d81 100644 --- a/rfc/1/review_1.md +++ b/rfc/1/review_1.md @@ -47,59 +47,3 @@ Under SPEC it says “Once sufficient endorsements, including two released imple ## Recommendation We are very supportive of this RFC and are appreciative of Josh Moore’s effort to make this proposal. We feel that there needs to be additional clarifications before this RFC can transition to the SPEC stage. Thus, we request “Major changes”, but are optimistic that the requested changes are addressable. - -iff --git a/rfc/1/review_2.md b/rfc/1/review_2.md -eleted file mode 100644 -ndex eba1e6f..0000000 --- a/rfc/1/review_2.md -++ /dev/null -@ -1,50 +0,0 @@ -# Review of RFC2 - -## Review authors -This review was written by: -- Joel Lüthi -- Virginie Uhlmann -- Kevin Yamauchi - -## Summary -RFC1 proposes a process by which changes to the NGFF project can be proposed, reviewed, and implemented. These changes include both modifications to the NGFF specification and to the governance of the NGFF project. This process has three phases: DRAFT, RFC, and SPEC. In the draft phase, community members can propose changes. If these changes receive sufficient community support via endorsements and Editor approval, they transition to the RFC phase. In the RFC phase, the proposal is reviewed by Reviewers chosen by an Editor. With Reviewer and Editor approval, the proposal transitions to the SPEC stage in which implementation will begin. - -Overall, we are in favor of the proposed changes and believe they are an improvement over the current process. The current NGFF process for adopting new specifications is based on “community consensus”, which is poorly defined, leading to uncertainty in how and when a specification will be approved. Further, this specification aims to provide a mechanism by which disagreements can be reconciled. Finally, this RFC adds much needed clarity about which type of discussion is meant to be prioritized at a given phase of a proposal. - -We reviewed this RFC from the perspective of somebody who might contribute an NGFF specification and somebody who might make a library that depends on the NGFF. Before approving, we would like further clarification on how the key decision points (e.g., R6 and R7) work. In particular, we seek clarification on the decision making powers of the Reviewers and Editors, as well as on the role of Endorsers. - -## Significant comments and questions -### Interaction of Reviewers and Editor in R6 and R7 -We think there needs to be further clarification on how RFCs transition to the SPEC phase. In particular, it is unclear when the Editor can override the Reviewers and vice versa. Similar to the process established in peer-reviewed publishing, we think that the final decision should rest with the Editor. -In which cases can the Editor override the Reviewers? -Can the Reviewers “force” an RFC to be accepted in spite of Editor concerns? If so, what are the conditions? It says that “If sufficient endorsements, including two in-progress implementations, are available, then the RFC can progress”, but it isn’t defined what “sufficient endorsements” means. We would appreciate additional clarification. -In the current RFC, it seems like a single “Reject” from a reviewer (veto) would prevent the SPEC from being accepted. We think that it is important that an individual cannot block an RFC and that the Editor can override a single “no vote”. As such, we would be in favor of removing the proposed veto power attributed to Reviewers in the current version. -Similarly, the current text suggests a single “Major changes” recommendation would always send an RFC into another round of edits and review. We think that it’s important that the Editor has some discretion as to whether a “Major changes” recommendation should block an RFC from getting to the SPEC phase. - -### Clarification on the role of Endorsers -What is the role of Endorsers in the process? From the diagram, we thought that Endorsers are voting to transition the DRAFT to a SPEC, but it is unclear how that interacts with the rest of the review process (e.g., can Endorsers “override” Reviewers somehow?). However, it is stated “Accept” at R2 is “equivalent to the Reviewer joining the list of endorsements.” and we aren’t sure what that means. We think it’s important that a potential reviewer can endorse a draft be made into an RFC without also simultaneously advocating the RFC should transition to SPEC. - -### The role of Implementers in the process -We think there needs to be further clarification on the role of the Implementers in the process. What is the intent of the additional version of “accept” for reviewers who are also Implementers (e.g., “Plan to implement”)? Does this mean that Implementers must always be included in the review? Does an RFC need planned implementations to transition to SPEC? It is unclear how these additional types of “Accept” factor into the decision to transition to SPEC. - -Further, what happens if a SPEC is accepted but there are no implementations in one of the main “official languages” (i.e., Python, Java, Javascript)? - -### Modification of RFCs and SPECs -We are curious about how changes to RFCs and SPECs are handled. Are the RFCs versioned as they are updated during the review process (R2-R6)? Is it possible to modify the RFC once it transitions to SPEC? How are changes proposed during the SPEC phase integrated (e.g., are they a PR with changes to the specification)? Do all changes to the spec need to be mentioned in the RFC itself or can finer details just be worked out during the SPEC phase based on a higher-level RFC? For example, if during the implementation, we realize that something needs to be added/changed to the spec, does there need to be another RFC? How is it decided if a change is “big enough” to require a new RFC? We think it should be possible to make minor changes without a new RFC and that the Editor should be able to decide when the magnitude of the change is large enough to warrant a new RFC. - -## Minor comments and questions - -- It is currently unclear if there are any guidelines or rules for how reviewers are selected in R1. Is there a min/max number of reviewers? On which basis should the reviewers be chosen (eg, Implementers or not)? We would suggest 3-5 would be a reasonable range. -- It is currently unclear how reviews are aggregated in R3. Does the Editor just forward all reviews? Or is there some compilation and prioritization provided by the Editor? -- We think it would be helpful to have an explanation of how conflicts of interests are managed and surfaced during the review process. For example, what would be considered a conflict of interest? Are there conflicts of interests that would prevent community members from participating in the review process? -Under SPEC it says “Once sufficient endorsements, including two released implementations, are listed, the specification will be considered “adopted”. Is this two implementations in any language (e.g., two Python implementations) or does it have to be implementations in at least two different languages? -- We think it would be helpful to have an overview at the top of the RFC giving a high level view of the process. For example, explaining that the proposal transitions from DRAFT -> RFC -> SPEC and explaining the intention/goal of each step as well as the estimated time for each (e.g., using the min/max bounds). It might be nice to also have a linear timeline type diagram as well. The detailed diagram in the current RFC is useful for digging into the process, but we find it difficult to quickly understand the overall flow from it. -- There are some typos in the document that should be addressed, including: - - end of “Proposal”: _further_RFCs. -> _further_ RFCs () - - In “Implementation”: familiar -> familiarize - - Under “SPEC”: Editors in coordination.Editors -> Editors in coordination. Editors (space missing) - - In “Drawbacks, risks, alternatives, and unknowns”, this RFC is referred to as RFC-0 instead of RFC-1 - -## Recommendation -We are very supportive of this RFC and are appreciative of Josh Moore’s effort to make this proposal. We feel that there needs to be additional clarifications before this RFC can transition to the SPEC stage. Thus, we request “Major changes”, but are optimistic that the requested changes are addressable. diff --git a/rfc/2/index.md b/rfc/2/index.md index 95571c2d..3a914f21 100644 --- a/rfc/2/index.md +++ b/rfc/2/index.md @@ -4,23 +4,27 @@ Adopt the version 3 of Zarr for OME-Zarr. ## Status -This RFC is currently in draft state (D3). - -| Role | Name | GitHub Handle | Institution | Date | Status | -| -------- | ------------------- | --------------------------------------------------- | -------------------------------------------------- | ---------- | ----------------------------------------------------------------------- | -| Author | Norman Rzepka | [normanrz](https://github.com/normanrz) | [scalable minds](https://scalableminds.com) | 2024-02-14 | | -| Endorser | Davis Bennett | [d-v-b](https://github.com/d-v-b) | | 2024-02-14 | Endorse | -| Endorser | Kevin Yamauchi | [kevinyamauchi](https://github.com/kevinyamauchi) | ETH Zürich | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1947942934) | -| Endorser | John Bogivic | [bogovicj](https://github.com/bogovicj) | HHMI Janelia Research Campus | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1948547356) | -| Endorser | Matthew Hartley | [matthewh-ebi](https://github.com/matthewh-ebi) | EMBL-EBI | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1948912814) | -| Endorser | Christian Tischer | [tischi](https://github.com/tischi) | EMBL | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1949058616) | -| Endorser | Joel Lüthi | [jluethi](https://github.com/jluethi) | BioVisionCenter, University of Zurich | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1949333769) | -| Endorser | Constantin Pape | [constantinpape](https://github.com/constantinpape) | University Göttingen | 2024-02-18 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1951318754) | -| Endorser | Will Moore | [will-moore](https://github.com/will-moore) | OME, University of Dundee | 2024-02-19 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1952057704) | -| Endorser | Juan Nunez-Iglesias | [jni](https://github.com/jni) | Biomedicine Discovery Institute, Monash University | 2024-02-20 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1953922897) | -| Endorser | Eric Perlman | [perlman](https://github.com/perlman) | | 2024-02-22 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1960272942) | -| Endorser | Ziwen Liu | [ziw-liu](https://github.com/ziw-liu) | Chan Zuckerberg Biohub | 2024-03-12 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1992588774) | -| Endorser | Lachlan Deakin | [LDeakin](https://github.com/LDeakin) | Australian National University | 2024-03-14 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1998594492) | +This RFC is currently in RFC state (R6). + +| Role | Name | GitHub Handle | Institution | Date | Status | +| -------- | ------------------- | --------------------------------------------------- | -------------------------------------------------- | ---------- | ----------------------------------------------------------------------- | +| Author | Norman Rzepka | [normanrz](https://github.com/normanrz) | [scalable minds](https://scalableminds.com) | 2024-02-14 | | +| Endorser | Davis Bennett | [d-v-b](https://github.com/d-v-b) | | 2024-02-14 | Endorse | +| Endorser | Kevin Yamauchi | [kevinyamauchi](https://github.com/kevinyamauchi) | ETH Zürich | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1947942934) | +| Endorser | John Bogivic | [bogovicj](https://github.com/bogovicj) | HHMI Janelia Research Campus | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1948547356) | +| Endorser | Matthew Hartley | [matthewh-ebi](https://github.com/matthewh-ebi) | EMBL-EBI | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1948912814) | +| Endorser | Christian Tischer | [tischi](https://github.com/tischi) | EMBL | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1949058616) | +| Endorser | Joel Lüthi | [jluethi](https://github.com/jluethi) | BioVisionCenter, University of Zurich | 2024-02-16 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1949333769) | +| Endorser | Constantin Pape | [constantinpape](https://github.com/constantinpape) | University Göttingen | 2024-02-18 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1951318754) | +| Endorser | Will Moore | [will-moore](https://github.com/will-moore) | OME, University of Dundee | 2024-02-19 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1952057704) | +| Endorser | Juan Nunez-Iglesias | [jni](https://github.com/jni) | Biomedicine Discovery Institute, Monash University | 2024-02-20 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1953922897) | +| Endorser | Eric Perlman | [perlman](https://github.com/perlman) | | 2024-02-22 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1960272942) | +| Endorser | Ziwen Liu | [ziw-liu](https://github.com/ziw-liu) | Chan Zuckerberg Biohub | 2024-03-12 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1992588774) | +| Endorser | Lachlan Deakin | [LDeakin](https://github.com/LDeakin) | Australian National University | 2024-03-14 | [Endorse](https://github.com/ome/ngff/pull/227#issuecomment-1998594492) | +| Reviewer | Melissa Linkert, Sebastién Besson, Chris Allan, Jason Swedlow | glencoesoftware | Glencoe Software | 2024-05-23 | [Review](./review_1.md) | +| Reviewer | Yaroslav O. Halchenko | yarikoptic | Dartmouth College, DANDI Project | 2024-06-10 | [Review](./review_2.md) | +| Reviewer | Jeremy Maitin-Shepard | jbms | Google | 2024-04-30 | [Review](./review_3.md) | +| Reviewer | Melissa Linkert, Sebastién Besson, Chris Allan, Jason Swedlow | glencoesoftware | Glencoe Software | 2024-08-05 | [Accept](./review_1b.md) | ## Overview @@ -51,17 +55,18 @@ Adopting Zarr v3 in OME-Zarr is a precondition for using sharding. Library support for Zarr v3 is already available for several languages: +- [zarr-python (Python)](https://github.com/zarr-developers/zarr-python) - [tensorstore (C++/Python)](https://github.com/google/tensorstore) -- [zarrita (Python)](https://github.com/scalableminds/zarrita) +- [zarr-java (Java)](https://github.com/zarr-developers/zarr-java) - [zarrita.js (JS)](https://github.com/manzt/zarrita.js) - [zarr3-rs (Rust)](https://github.com/clbarnes/zarr3-rs) -Visualization tools with integrated Zarr implementations are also available: +Visualization tools with integrated Zarr v3 implementations are also available: - [neuroglancer](https://github.com/google/neuroglancer) - [WEBKNOSSOS](https://github.com/scalableminds/webknossos) -Support for other languages is under active development, including C, Java and Python. +Support for other languages is under active development. Libraries will likely prioritize support for v3 over previous versions in the near future. OME-Zarr should therefore adopt the new version for future-proofing. @@ -84,26 +89,7 @@ Implementations can read inner chunks individually. Depending on the choice of codecs and the underlying storage backends, it may be possible to write inner chunks individually. However, in the general case, writing is limited to entire shards. -## Proposal - -This RFC proposes to adopt version 3 of the Zarr format for OME-Zarr. -Images that use the new version of OME-Zarr metadata MUST NOT use Zarr version 2 any more. - -The motivation for making this hard cut is to reduce the burden of complexity for implementations. -Currently, many Zarr library implementations support both versions. -However, in the future they might deprecate support for version 2 or deprioritize it in terms of features and performance. -Additionally, there are OME-Zarr implementations that have their own integrated Zarr stack. -With this hard cut, implementations that only support OME-Zarr versions > 0.5 (TODO: update assigned version number) will not need to implement Zarr version 2 as well. - -From a OME-Zarr user perspective, the hard cut also makes things simpler: ≤ 0.5 => Zarr version 2 and > 0.5 => Zarr version 3 (TODO: update assigned version number). -If users wish to upgrade their data from one OME-Zarr version to another, it would be easy to also migrate the core Zarr metadata to version 3. -This is a fairly cheap operation, because only json files are touched. -Zarr version 2 and 3 metadata could even live side-by-side in the same hierarchy. -There are [scripts available](https://github.com/scalableminds/zarrita/blob/8155761/zarrita/array_v2.py#L452-L559) that can migrate the metadata automatically. - -It is RECOMMENDED that implementations support a range of OME-Zarr versions, including versions based on Zarr version 2. - -### Notable changes in Zarr v3 +### Other notable changes in Zarr v3 There are a few notable changes that Zarr v3 brings for OME-Zarr: @@ -123,15 +109,40 @@ There are a few notable changes that Zarr v3 brings for OME-Zarr: The Zarr specification does not prescribe the support stores for Zarr hierarchies. HTTP(S), File system, S3, GCS, and Zip files are commonly used stores. +## Proposal + +This RFC proposes to adopt version 3 of the Zarr format for OME-Zarr. +Images that use the new version of OME-Zarr metadata MUST NOT use Zarr version 2 any more. + With this proposal all features of the Zarr specification are allowed in OME-Zarr. In the future, the OME-Zarr community MAY decide to restrict the allowed feature set. +The motivation for making this hard cut is to reduce the burden of complexity for implementations. +Currently, many Zarr library implementations support both versions. +However, in the future they might deprecate support for version 2 or deprioritize it in terms of features and performance. +Additionally, there are OME-Zarr implementations that have their own integrated Zarr stack. +With this hard cut, implementations that only support OME-Zarr versions ≥ 0.5 will not need to implement Zarr version 2 as well. + +From an OME-Zarr user perspective, the hard cut also makes things simpler: < 0.5 => Zarr version 2 and ≥ 0.5 => Zarr version 3. +If users wish to upgrade their data from one OME-Zarr version to another, migration tools will be available ([prototype here](https://github.com/scalableminds/zarrita/blob/8155761/zarrita/array_v2.py#L452-L559)). +Migration is a fairly computationally cheap operation, because only json files are touched. + +Due to the existence of large quantities of images in OME-Zarr 0.4, it is RECOMMENDED that implementations continue to support OME-Zarr 0.4 with the underlying Zarr v2. + +OME-Zarr images MUST be consistent in their OME-Zarr and Zarr version. +With this constraint, implementations only need to detect the version of a provided URL or file path once and can assume that all multiscale levels, wells, series images etc. use the same version. + +While technically possible, OME-Zarr 0.5 (with Zarr v3) and OME-Zarr 0.4 (with Zarr v2) metadata could exist side-by-side in a Zarr hierarchy, it is NOT RECOMMENDED. +This may be useful for short periods of time (i.e. during migrations from 0.4 to 0.5), but should not be used longer term. +Multiple metadata versions can lead to conflicts, which may be hard to resolve by implementations. +If implementations encounter 0.4 and 0.5 metadata side-by-side, 0.5 SHOULD be treated preferentially. + ### Changes to the OME-Zarr metadata -While the adoption of Zarr v3 does not strictly require changes to the OME-Zarr metadata, this proposal contains changes to align with community conventions and ease implementation: +While the adoption of Zarr v3 does not strictly require changes to the OME-Zarr metadata, this proposal contains changes to align with [community conventions](https://zarr.dev/zeps/draft/ZEP0004.html#namespacing) and ease implementation: -- OME-Zarr metadata will be stored under a dedicated key in the Zarr array or group attributes. The key will be a well-known URI of the OME-NGFF specification with a version number, e.g. `https://ngff.openmicroscopy.org/0.6`. -- Since the version is already encoded in the new metadata key, the `version` keys in `multiscale`, `plate`, `well` etc. are removed. +- OME-Zarr metadata will be stored under a dedicated `ome` key in the Zarr array or group attributes. +- The version information will be moved from the `multiscale`, `plate`, `well` etc. sections into the new `ome` section. - The `dimension_names` attribute in the Zarr metadata must match the axes names in the OME-Zarr metadata. Finally, this proposal changes the title of the OME-Zarr specification document to "OME-Zarr specification". @@ -142,7 +153,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF RFC 2119][IETF RFC 2119] -## Stakeholders (Recommended Header) +## Stakeholders Preliminary work of this RFC has been discussed in: @@ -153,35 +164,22 @@ Preliminary work of this RFC has been discussed in: - several Zarr community calls - several recent OME-NGFF community calls. - - ## Implementation -OME-Zarr implementations can rely on existing Zarr libraries to implement the adoption of Zarr v3. +OME-Zarr implementations can rely on existing Zarr libraries to implement the adoption of Zarr v3. +See [Background](#background) for a list of v3-capable Zarr libraries. -TODO: Provide a reference implementation +Support for the OME-Zarr 0.5 metadata is under development in [ome-zarr-py](https://github.com/ome/ome-zarr-py/pull/383/files) and other implementations. ## Drawbacks, risks, alternatives, and unknowns While it is clear that Zarr v3 will become the predominant version of the specification moving forward, current library support for v3 is still under active development. +An alternative to this proposal would be to [add Zarr v3 support to OME-Zarr 0.4](https://github.com/ome/ngff/pull/249) without changes to the OME-Zarr Metadata. +The contents of the `.zattrs` would simply move to the `attributes` within the `zarr.json`. +There would need to be some transparency for users to know what Zarr versions are supported by an implementation. +Additionally, there would be no opportunity to introduce an `ome` namespace in the attributes that is useful for composability. +