Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Node name changes #85

Closed
wants to merge 4 commits into from
Closed

Node name changes #85

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1329bdb
Node name changes
alimanfoo Jul 15, 2020
991cb8e
added clarification about case sensitivity
alimanfoo Jul 15, 2020
ac578dd
fix idiocy
alimanfoo Jul 15, 2020
12e41bc
minor
alimanfoo Jul 15, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 18 additions & 8 deletions docs/protocol/core/v3.0.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -257,7 +257,7 @@ Node names
==========

Except for the root node, each node in a hierarchy must have a name,
which is a string characters. To ensure consistent behaviour
which is a string of characters. To ensure consistent behaviour
across different storage systems, the following constraints apply to
node names:

Expand All @@ -271,12 +271,16 @@ node names:

* must be at most 255 characters long

Note that node names are used to form storage keys, and that some
storage systems will perform a case-insensitive comparison of storage
keys during retrieval. Therefore, within a hierarchy, all nodes within
a set of sibling nodes must have a name that is unique under
case-insensitive comparison. E.g., the names "foo" and "FOO" are not
allowed for sibling nodes.
Node names are case sensitive, e.g., the names "foo" and "FOO" are **not**
identical.

.. note:
The Zarr core development team recognises that restricting the set
of allowed characters creates an impediment and bias against users
of different languages. We are actively discussing whether the full
Unicode character set could be allowed and what technical issues
this would entail. If you have experience or views please comment on
`issue #56 <https://github.com/zarr-developers/zarr-specs/issues/56>`_.


Data types
Expand Down Expand Up @@ -904,7 +908,8 @@ string containing only characters in the ranges ``a-z``, ``A-Z``,
``0-9``, or in the set ``/.-_``, and a `value` is any sequence of
bytes. It is assumed that the store holds (`key`, `value`) pairs, with
only one such pair for any given `key`. I.e., a store is a mapping
from keys to values.
from keys to values. It is also assumed that keys are case sensitive,
i.e., the keys "foo" and "FOO" are different.

The store operations are grouped into three sets of capabilities:
**readable**, **writeable** and **listable**. It is not necessary for
Expand Down Expand Up @@ -955,6 +960,11 @@ which do not contain the character "/" after the given prefix.
"a/f/g", then ``list_dir("a/")`` would return keys "a/b" and "a/c"
and prefixes "a/d/" and "a/f/".

Note that because keys are case sensitive, it is assumed that the operations
``set("foo", a)`` and ``set("FOO", b)`` will result in two separate (key, value)
pairs being stored. Subsequently ``get("foo")`` will return *a* and ``get("FOO")``
will return *b*.


Store implementations
---------------------
Expand Down