typo

rfc/2/index.md

@@ -122,7 +122,7 @@ However, in the future they might deprecate support for version 2 or deprioritiz
 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 a OME-Zarr user perspective, the hard cut also makes things simpler: ≤ 0.5 => Zarr version 2 and > 0.5 => Zarr version 3.
+From a 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, it 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.
 
@@ -177,7 +177,7 @@ While it is clear that Zarr v3 will become the predominant version of the specif
 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 a `ome` namespace in the attributes that is useful for composability.
+Additionally, there would be no opportunity to introduce an `ome` namespace in the attributes that is useful for composability.
 
 <!--
 - What are the costs of implementing this proposal?