Merge branch 'main' into omero_metadata_optional

Author: will-moore

index.md

@@ -87,7 +87,7 @@ Note that the number of dimensions is variable between 2 and 5 and that axis nam
     │
     └── labels
         │
-        ├── zarr.json         # The labels group is a container which holds a list of labels to make the objects easily discoverable
+        ├── zarr.json         # The labels group is a container which holds an array of labels to make the objects easily discoverable
         │                     # All labels will be listed in `zarr.json` e.g. `{ "labels": [ "original/0" ] }`
         │                     # Each dimension of the label should be either the same as the
         │                     # corresponding dimension of the image, or `1` if that dimension of the label
@@ -207,8 +207,8 @@ See the [example below](#spec:example:coordinate_transformation).
 `axes` describes the dimensions of a coordinate systems
 and adds an interpretation to the samples along that dimension.
 
-It is a list of dictionaries,
-where each dictionary describes a dimension (axis) and:
+It is an array of objects,
+where each object describes a dimension (axis) and:
 - MUST contain the field `name` that gives the name for this dimension.
   The values MUST be unique across all `name` fields in the same coordinate system.
 - SHOULD contain the field `type`.
@@ -381,7 +381,7 @@ Additionally, the logic for finding the Zarr group for each image follows the fo
   - Matching `series` metadata (as described next) SHOULD be provided for tools that are unaware of the `plate` specification.
 - If the `OME` Zarr group exists, it:
   - MAY contain a `series` attribute. If so:
-    - `series` MUST be a list of string objects, each of which is a path to an image group.
+    - `series` MUST be an array of string objects, each of which is a path to an image group.
     - The order of the paths MUST match the order of the `Image` elements in `OME/METADATA.ome.xml` if provided.
 - If the `series` attribute does not exist and no `plate` is present:
   - separate `multiscales` images MUST be stored in consecutively numbered groups starting from 0 (i.e. `0/`, `1/`, `2/`, `3/`, ...).
@@ -420,11 +420,11 @@ The following transformations are supported:
 |------|--------|-------------|
 | [`identity`](#identity-md) | | The identity transformation is the do-nothing transformation and is typically not explicitly defined. |
 | [`mapAxis`](#mapaxis-md) | `"mapAxis":List[number]` | an axis permutation as a transpose array of integer indices that refer to the ordering of the axes in the respective coordinate system. |
-| [`translation`](#translation-md) | one of:<br>`"translation":List[number]`,<br>`"path":str` | Translation vector, stored either as a list of numbers (`translation`) or as a zarr array at a location in this container (`path`). |
-| [`scale`](#scale-md) | one of:<br>`"scale":List[number]`,<br>`"path":str` | Scale vector, stored either as a list of numbers (`scale`) or as a zarr array at a location in this container (`path`). |
+| [`translation`](#translation-md) | one of:<br>`"translation":List[number]`,<br>`"path":str` | Translation vector, stored either as an array of numbers (`translation`) or as a zarr array at a location in this container (`path`). |
+| [`scale`](#scale-md) | one of:<br>`"scale":List[number]`,<br>`"path":str` | Scale vector, stored either as an array of numbers (`scale`) or as a zarr array at a location in this container (`path`). |
 | [`affine`](#affine-md) | one of:<br>`"affine":List[List[number]]`,<br>`"path":str` | 2D affine transformation matrix stored either with JSON (`affine`) or as a zarr array at a location in this container (`path`). |
 | [`rotation`](#rotation-md) | one of:<br>`"rotation":List[List[number]]`,<br>`"path":str` | 2D rotation transformation matrix stored as an array stored either with json (`rotation`) or as a zarr array at a location in this container (`path`).|
-| [`sequence`](#sequence-md) | `"transformations":List[Transformation]` | sequence of transformations. Applying the sequence applies the composition of all transforms in the list, in order. |
+| [`sequence`](#sequence-md) | `"transformations":List[Transformation]` | sequence of transformations. Applying the sequence applies the composition of all transforms in the array, in order. |
 | [`displacements`](#coordinates-displacements-md) | `"path":str`<br>`"interpolation":str` | Displacement field transformation located at `path`. |
 | [`coordinates`](#coordinates-displacements-md) | `"path":str`<br>`"interpolation":str` | Coordinate field transformation located at `path`. |
 | [`inverseOf`](#inverseof-md) | `"transformation":Transformation` | The inverse of a transformation. Useful if a transform is not closed-form invertible. See forward and inverse of [bijections](#bijection-md) for details and examples. |
@@ -477,8 +477,8 @@ Coordinate transformations can be stored in multiple places to reflect different
 - Transformations in individual multiscale datasets represent a special case of transformations
   and are explained [below](#multiscales-md).
 - Additional transformations for single multiscale images MUST be stored under a field `coordinateTransformations`
-  in the multiscales dictionaries.
-  This `coordinateTransformations` field MUST contain a list of valid [transformations](#trafo-types-md).
+  in the multiscales objects.
+  This `coordinateTransformations` field MUST contain an array of valid [transformations](#trafo-types-md).
 - Transformations between two or more images MUST be stored in the attributes of a parent zarr group.
   For transformations that store data or parameters in a zarr array,
   those zarr arrays SHOULD be stored in a zarr group called `coordinateTransformations`.
@@ -579,7 +579,7 @@ Most coordinate transformations MUST specify their input and output coordinate s
 using `input` and `output` with a string value
 that MUST correspond to the name of a coordinate system or the path to a multiscales group.
 Exceptions are if the coordinate transformation is wrapped in another transformation,
-e.g. as part of a  `transformations` list of a `sequence` or
+e.g. as part of a  `transformations` array of a `sequence` or
 as `transformation` of an `inverseOf` transformation.
 In these two cases input and output could, in some cases, be omitted (see below for details).
 If unused, the `input` and `output` fields MAY be null.
@@ -788,8 +788,8 @@ The `input` and `output` fields MAY be omitted if wrapped in another transformat
 The array at this path MUST be 1D, and its length MUST be `N`.
 
 <strong>translation</strong>
-: The translation parameters stored as a JSON list of numbers.
-The list MUST have length `N`.
+: The translation parameters stored as a JSON array of numbers.
+The array MUST have length `N`.
 
 :::{dropdown} Example
 :animate: fade-in
@@ -824,8 +824,8 @@ The `input` and `output` fields MAY be omitted if wrapped in another transformat
 The array at this path MUST be 1D, and its length MUST be `N`.
 
 <strong>scale</strong>
-: The scale parameters are stored as a JSON list of numbers.
-The list MUST have length `N`.
+: The scale parameters are stored as a JSON array of numbers.
+The array MUST have length `N`.
 
 :::{dropdown} Example 1
 :animate: fade-in
@@ -1025,7 +1025,7 @@ A `sequence` transformation consists of an ordered array of coordinate transform
 and is invertible if every coordinate transform in the array is invertible
 (though could be invertible in other cases as well).
 To apply a sequence transformation to a point in the input coordinate system,
-apply the first transformation in the list of transformations.
+apply the first transformation in the array of transformations.
 Next, apply the second transformation to the result.
 Repeat until every transformation has been applied.
 The output of the last transformation is the result of the sequence.
@@ -1039,7 +1039,7 @@ The `input` and `output` fields MUST be included for sequence transformations.
 :::{note}
 
 Considering transformations as functions of points,
-if the list contains transformations `[f0, f1, f2]` in that order,
+if the array contains transformations `[f0, f1, f2]` in that order,
 applying this sequence to point `x` is equivalent to:
 
 ```
@@ -1348,7 +1348,7 @@ Another **invalid** `byDimension` transform:
 :language: json
 ```
 
-This transformation is invalid because the output axis `x` appears in more than one transformation in the `transformations` list.
+This transformation is invalid because the output axis `x` appears in more than one transformation in the `transformations` array.
 :::
 
 ##### bijection
@@ -1395,9 +1395,9 @@ Here, "image" refers to 2 to 5 dimensional data representing image
 or volumetric data with optional time or channel axes.
 It is stored in a multiple resolution representation.
 
-`multiscales` contains a list of dictionaries where each entry describes a multiscale image.
+`multiscales` contains an array of objects where each entry describes a multiscale image.
 
-Each `multiscales` dictionary MUST contain the field `coordinateSystems`,
+Each `multiscales` object MUST contain the field `coordinateSystems`,
 whose value is an array containing coordinate system metadata
 (see [coordinate systems](#coordinate-systems-md)).
 The last entry of this array is the "intrinsic" coordinate system
@@ -1416,17 +1416,17 @@ followed by the  `channel` or custom axis (if present) and the axes of type `spa
 If there are three spatial axes where two correspond to the image plane (`yx`)
 and images are stacked along the other (anisotropic) axis (`z`),
 the spatial axes SHOULD be ordered as `zyx`.
-Each `multiscales` dictionary MUST contain the field `datasets`,
-which is a list of dictionaries describing the arrays storing the individual resolution levels.
-Each dictionary in `datasets` MUST contain the field `path`,
+Each `multiscales` object MUST contain the field `datasets`,
+which is an array of objects describing the arrays storing the individual resolution levels.
+Each object in `datasets` MUST contain the field `path`,
 whose value is a string containing the path to the Zarr array for this resolution relative to the current Zarr group.
 The `path`s MUST be ordered from largest (i.e. highest resolution) to smallest.
 Every Zarr array referred to by a `path` MUST have the same number of dimensions
 and MUST NOT have more than 5 dimensions.
 The number of dimensions and order MUST correspond to number and order of `axes`.
 
-Each dictionary in `datasets` MUST contain the field `coordinateTransformations`,
-whose value is a list of dictionaries that define a transformation
+Each object in `datasets` MUST contain the field `coordinateTransformations`,
+whose value is an array of objects that define a transformation
 that maps Zarr array coordinates for this resolution level to the "intrinsic" coordinate system
 (the last entry of the `coordinateSystems` array).
 The transformation is defined according to [transformations metadata](#trafo-types-md).
@@ -1450,18 +1450,18 @@ This is strongly recommended
 so that the the "intrinsic" coordinate system of the image avoids more complex transformations.
 
 If applications require additional transformations,
-each `multiscales` dictionary MAY contain the field `coordinateTransformations`,
+each `multiscales` object MAY contain the field `coordinateTransformations`,
 describing transformations that are applied to all resolution levels in the same manner.
 The value of `input` MUST equal the name of the "intrinsic" coordinate system.
 The value of `output` MUST be the name of the output coordinate System
 which is different from the "intrinsic" coordinate system.
 
-Each `multiscales` dictionary SHOULD contain the field `name`.
+Each `multiscales` object SHOULD contain the field `name`.
 
-Each `multiscales` dictionary SHOULD contain the field `type`,
+Each `multiscales` object SHOULD contain the field `type`,
 which gives the type of downscaling method used to generate the multiscale image pyramid.
 It SHOULD contain the field `metadata`,
-which contains a dictionary with additional information about the downscaling method.
+which contains a object with additional information about the downscaling method.
 
 
 :::{dropdown} Example
@@ -1539,7 +1539,6 @@ Each object in `channels` MAY contain the following fields:
   - `end` (float) End of the rendering window.
 - `inverted` (boolean) If true, the rendering of darkest to brightest pixels should be inverted.
 
-
 ### "labels" metadata
 (labels-md)=
 
@@ -1628,8 +1627,8 @@ Pixels with a 1 in the Zarr array, which correspond to cellular space, will be d
 For high-content screening datasets,
 the plate layout can be found under the custom attributes of the plate group under the `plate` key in the group-level metadata.
 
-The `plate` dictionary MAY contain an `acquisitions` key
-whose value MUST be a list of JSON objects defining the acquisitions for a given plate to which wells can refer to.
+The `plate` object MAY contain an `acquisitions` key
+whose value MUST be an array of JSON objects defining the acquisitions for a given plate to which wells can refer to.
 Each acquisition object MUST contain an `id` key
 whose value MUST be an unique integer identifier greater than or equal to 0 within the context of the plate
 to which fields of view can refer to (see [well metadata](#well-md)).
@@ -1642,52 +1641,52 @@ whose value MUST be a string specifying a description for the acquisition.
 Each acquisition object MAY contain a `starttime` and/or `endtime` key
 whose values MUST be integer epoch timestamps specifying the start and/or end timestamp of the acquisition.
 
-The `plate` dictionary MUST contain a `columns` key
-whose value MUST be a list of JSON objects defining the columns of the plate.
-Each column object defines the properties of the column at the index of the object in the list.
+The `plate` object MUST contain a `columns` key
+whose value MUST be an array of JSON objects defining the columns of the plate.
+Each column object defines the properties of the column at the index of the object in the array.
 Each column in the physical plate MUST be defined,
 even if no wells in the column are defined.
 Each column object MUST contain a `name` key whose value is a string specifying the column name.
 The `name` MUST contain only alphanumeric characters,
 MUST be case-sensitive,
-and MUST NOT be a duplicate of any other `name` in the `columns` list.
+and MUST NOT be a duplicate of any other `name` in the `columns` array.
 Care SHOULD be taken to avoid collisions on case-insensitive filesystems
 (e.g. avoid using both `Aa` and `aA`).
 
-The `plate` dictionary SHOULD contain a `field_count` key
+The `plate` object SHOULD contain a `field_count` key
 whose value MUST be a positive integer defining the maximum number of fields per view across all wells.
 
-The `plate` dictionary SHOULD contain a `name` key
+The `plate` object SHOULD contain a `name` key
 whose value MUST be a string defining the name of the plate.
 
-The `plate` dictionary MUST contain a `rows` key
-whose value MUST be a list of JSON objects defining the rows of the plate.
-Each row object defines the properties of the row at the index of the object in the list.
+The `plate` object MUST contain a `rows` key
+whose value MUST be an array of JSON objects defining the rows of the plate.
+Each row object defines the properties of the row at the index of the object in the array.
 Each row in the physical plate MUST be defined,
 even if no wells in the row are defined.
 Each defined row MUST contain a `name` key whose value MUST be a string defining the row name.
 The `name` MUST contain only alphanumeric characters,
 MUST be case-sensitive,
-and MUST NOT be a duplicate of any other `name` in the `rows` list.
+and MUST NOT be a duplicate of any other `name` in the `rows` array.
 Care SHOULD be taken to avoid collisions on case-insensitive filesystems
 (e.g. avoid using both `Aa` and `aA`).
 
-The `plate` dictionary MUST contain a `version` key
+The `plate` object MUST contain a `version` key
 whose value MUST be a string specifying the version of the plate specification.
 
-The `plate` dictionary MUST contain a `wells` key
-whose value MUST be a list of JSON objects defining the wells of the plate.
+The `plate` object MUST contain a `wells` key
+whose value MUST be an array of JSON objects defining the wells of the plate.
 Each well object MUST contain a `path` key
 whose value MUST be a string specifying the path to the well subgroup.
-The `path` MUST consist of a `name` in the `rows` list,
+The `path` MUST consist of a `name` in the `rows` array,
 a file separator (`/`),
-and a `name` from the `columns` list,
+and a `name` from the `columns` array,
 in that order.
 The `path` MUST NOT contain additional leading or trailing directories.
 Each well object MUST contain both a `rowIndex` key
-whose value MUST be an integer identifying the index into the `rows` list,
+whose value MUST be an integer identifying the index into the `rows` array,
 and a `columnIndex` key
-whose value MUST be an integer identifying the index into the `columns` list.
+whose value MUST be an integer identifying the index into the `columns` array.
 `rowIndex` and `columnIndex` MUST be 0-based.
 The `rowIndex`, `columnIndex`, and `path` MUST all refer to the same row/column pair.
 
@@ -1713,16 +1712,16 @@ containing one field of view per acquisition.
 For high-content screening datasets,
 the metadata about all fields of views under a given well can be found under the `well` key in the attributes of the well group.
 
-The `well` dictionary MUST contain an `images` key
-whose value MUST be a list of JSON objects specifying all fields of views for a given well.
+The `well` object MUST contain an `images` key
+whose value MUST be an array of JSON objects specifying all fields of views for a given well.
 Each image object MUST contain a `path` key
 whose value MUST be a string specifying the path to the field of view.
-The `path` MUST contain only alphanumeric characters, MUST be case-sensitive, and MUST NOT be a duplicate of any other `path` in the `images` list.
+The `path` MUST contain only alphanumeric characters, MUST be case-sensitive, and MUST NOT be a duplicate of any other `path` in the `images` array.
 If multiple acquisitions were performed in the plate,
 it MUST contain an `acquisition` key whose value MUST be an integer identifying the acquisition
 which MUST match one of the acquisition JSON objects defined in the [plate metadata](#plate-md).
 
-The `well` dictionary SHOULD contain a `version` key
+The `well` object SHOULD contain a `version` key
 whose value MUST be a string specifying the version of the well specification.
 
 :::{dropdown} Example