From 5c25ae75aecc70ce7ed37596e35a25779759ce1f Mon Sep 17 00:00:00 2001 From: Yaroslav Halchenko Date: Wed, 11 Sep 2024 14:30:37 -0400 Subject: [PATCH] Add my re-review (#2) of RFC-2 --- rfc/2/index.md | 6 ++++++ rfc/2/reviews/2b/index.md | 25 +++++++++++++++++++++++++ 2 files changed, 31 insertions(+) create mode 100644 rfc/2/reviews/2b/index.md diff --git a/rfc/2/index.md b/rfc/2/index.md index 3ab73533..2fc97417 100644 --- a/rfc/2/index.md +++ b/rfc/2/index.md @@ -134,6 +134,12 @@ This RFC is currently in RFC state (R6). - Google - 2024-09-11 - [Accept](./reviews/3b/index) +* - Reviewer + - Yaroslav O. Halchenko + - yarikoptic + - Dartmouth College, DANDI Project + - 2024-09-11 + - [Accept](./reviews/2b/index) ``` ## Overview diff --git a/rfc/2/reviews/2b/index.md b/rfc/2/reviews/2b/index.md new file mode 100644 index 00000000..a30f411e --- /dev/null +++ b/rfc/2/reviews/2b/index.md @@ -0,0 +1,25 @@ +# Review 2 (update) + +## Review authors +This review was written by: +- Yaroslav O. Halchenko (Dartmouth College, DANDI Project) + +## Summary + +Comments from the initial round of reviews were proposed, accepted (with minor tune ups after) in https://github.com/ome/ngff/pull/250 . The changes to RFC-2 in that PR are sufficient to update our recommendation from "Major changes" to "Accept". + +- Concern on compatibility with Zarr v2/OME 0.4 was largely addressed: it is now RECOMMENDED to maintain compatibility. +- Concern on v2 and v3 co-existence was addressed by more explicit formulation that it is possible but NOT RECOMMENDED [^1], and that 0.5 SHOULD be treated preferentially in case of both v2 and v3 metadata co-existence. +- Recommendation on separation of the "name" of the standard from the versioning was addressed by introduction of `ome` as the top-level key for the OME-NGFF metadata in zarr.json with a `version` key within that `ome` record. + - unfortunately the concept of "namespaces" is not yet formalized in Zarr itself, WiP in [ZEP004: Namespaces](https://github.com/zarr-developers/zarr-specs/pull/262/files). + So it would remain possible that changes in the future would be needed to align with Zarr's formalization of namespaces. +- My questioning of the value to bundle together support of Zarr v3 and changes to metadata was largely addressed by addition to "Drawbacks, risks, alternatives, and unknowns": even without formalization of "Zarr namespaces" it would be useful to have `ome` as the top-level key for the OME-NGFF metadata in zarr.json. + +[^1]: according to [RFC 2119: Section 4](https://datatracker.ietf.org/doc/html/rfc2119#section-4), even though "NOT RECOMMENDED" is not explicitly listed among the list of key words, it is to be treated similarly to "SHOULD NOT", so we are fine here. + +Remaining concerns in the original review are addressed by stronger language around how applications should handle multiple versions and the usage of ‘ome’ as the top-level key for the OME-NGFF metadata in zarr.json. + + +## Recommendation + +"Accept".