zarr -> Zarr, in prose

Author: d-v-b

docs/v3/core/v3.0.rst

@@ -116,7 +116,7 @@ This core specification adheres to a ``MAJOR.MINOR`` version
 number format. When incrementing the minor version, only additional features
 can be added. Breaking changes require incrementing the major version.
 
-A zarr implementation that provides the read and write API by
+A Zarr implementation that provides the read and write API by
 implementing a specification ``X.Y`` can be considered compatible with all
 datasets which only use features contained in version ``X.Y``.
 
@@ -321,7 +321,7 @@ The following figure illustrates the first part of the terminology:
     hierarchy_ are held in a store as raw bytes. To enable a variety
     of different store types to be used, this specification defines an
     `Abstract store interface`_ which is a common set of operations that stores
-    may provide. For example, a directory in a file system can be a zarr store,
+    may provide. For example, a directory in a file system can be a Zarr store,
     where keys are file names, values are file contents, and files can be read,
     written, listed or deleted via the operating system. Equally, an S3 bucket
     can provide this interface, where keys are resource names, values are
@@ -678,18 +678,18 @@ The following members are optional:
     unnamed dimension is indicated by the null object.  If ``dimension_names`` is
     not specified, all dimensions are unnamed.
 
-    For compatibility with zarr implementations and applications that support
+    For compatibility with Zarr implementations and applications that support
     using dimension names to uniquely identify dimensions, it is recommended but
     not required that all non-null dimension names are distinct (no two
     dimensions have the same non-empty name).
 
     This specification also does not place any restrictions on the use of the
-    same dimension name across multiple arrays within the same zarr hierarchy,
+    same dimension name across multiple arrays within the same Zarr hierarchy,
     but extensions or specific applications may do so.
 
 The array metadata object must not contain any other names.
 Those are reserved for future versions of this specification.
-An implementation must fail to open zarr hierarchies, groups
+An implementation must fail to open Zarr hierarchies, groups
 or arrays with unknown metadata fields, with the exception of
 objects with a ``"must_understand": false`` key-value pair.
 
@@ -769,7 +769,7 @@ above, but using a (currently made up) extension data type::
 
 .. note::
 
-   Comparison with zarr spec v2:
+   Comparison with Zarr spec v2:
 
    - ``dtype`` has been renamed to ``data_type``,
    - ``chunks`` has been replaced with ``chunk_grid``,
@@ -873,7 +873,7 @@ This follows the
     representation is the ``UTF-8`` encoded Unicode string.
 
 .. note::
-    The prefix ``__zarr`` is reserved for core zarr data, and extensions
+    The prefix ``__zarr`` is reserved for core Zarr data, and extensions
     can use other files and folders starting with ``__``.
 
 
@@ -1162,7 +1162,7 @@ To encode or decode a chunk, the encoded and decoded representations for each
 codec in the chain must first be determined as follows:
 
 1. The initial decoded representation, ``decoded_representation[0]`` is a
-   multi-dimensional array with the same data type as the zarr array, and shape
+   multi-dimensional array with the same data type as the Zarr array, and shape
    equal to the chunk shape.
 
 2. For each codec ``i``, the encoded representation is equal to the decoded
@@ -1182,7 +1182,7 @@ the following procedure:
 
 1. The initial *encoded chunk* ``EC[0]`` of the type specified by
    ``decoded_representation[0]`` is equal to the chunk array ``A`` (with a shape
-   equal to the chunk shape, and data type equal to the zarr array data type).
+   equal to the chunk shape, and data type equal to the Zarr array data type).
 
 2. For each codec ``codecs[i]`` in ``codecs``, ``EC[i+1] :=
    codecs[i].encode(EC[i])``.
@@ -1652,7 +1652,7 @@ that need to be carefully considered but do not strictly fall into the spec.
 Explicit vs implicit group
 --------------------------
 
-While this zarr spec v3 defines implicit and explicit groups, implementations may
+While this Zarr spec v3 defines implicit and explicit groups, implementations may
 decide to create an explicit group for all implicit groups they encounter; in
 particular when using a hierarchical storage.