node names

Author: alimanfoo

slides/v3-update-20190619.md

@@ -76,7 +76,7 @@ Alistair Miles ([@alimanfoo](https://github.com/alimanfoo))
 
 ====
 
-### Spec development process (1)
+### Spec development process - current
 
 * Currently @alimanfoo is acting as editor for the v3.0 core protocol
   spec.
@@ -90,7 +90,7 @@ Alistair Miles ([@alimanfoo](https://github.com/alimanfoo))
 
 ===
 
-### Spec development process (2)
+### Spec development process - future?
 
 * Ultimately I think we'll need to define a community process for spec
   development, so that:
@@ -101,24 +101,92 @@ Alistair Miles ([@alimanfoo](https://github.com/alimanfoo))
 
   * It's clear what stage of maturity each spec is at.
 
-* Postpone that for now, may need external advice/help on best
+* Don't have a solution for that yet, may need advice/help on best
   approach.
 
 ===
 
-### Spec development process (3)
+### Spec development process - freedoms
 
 * Hopefully the [zarr-specs
   repo](https://github.com/zarr-developers/zarr-specs) can serve as a
   focus for community spec development.
 
+  * ...and the [zarr-specs RTFD
+    site](https://zarr-specs.readthedocs.io) can serve as a discovery
+    point for specs.
+  
 * However, don't want to force all spec development down the same
-  route.
+  route, or force all specs to be published in the same place.
 
-  * This is one reason why currently the core spec makes use of
-    **URIs** in metadata to refer to protocol extensions and codecs -
-    allow for anyone to publish their own spec.
+  * This is one reason why currently the core protocol spec makes use
+    of **URIs** in metadata to refer to protocol extensions and
+    codecs - allow freedom for anyone to publish their own spec.
+
+====
+
+### [Core protocol - concepts and terminology](https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html#concepts-and-terminology)
+
+*Hierachy. Group. Array. Name. Path. Dimension. Shape. Element. Data
+type. Chunk. Grid. Memory layout. Compressor. Codec. Metadata
+document. Store.*
+
+* Are we comfortable with this terminology and how it is defined?
+
+* Any important missing terms/concepts?
 
 ====
 
-### 
+### [Core protocol - node names](https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html#node-names)
+
+* Each node (array or group) in a hierarchy has a name.
+
+* Node names are used to form node paths.
+
+  * E.g., "/foo/bar" is a path identifying a node named "bar" whose
+    parent is named "foo" whose parent is the root node.
+
+===
+
+### Node names - restrictions
+
+* Node paths are used by users to access nodes and navigate a
+  hierarchy.
+
+* N.B., node paths are also used to form storage keys (see later).
+
+* To try and ensure compatibility with a variety of storage systems,
+  the core protocol currently states fairly heavy restrictions on node
+  names.
+  
+  * Includes restriction to ASCII alpha-numeric characters, "-", "_"
+    and ".".
+
+===
+
+### Node names - restrictions
+
+* Are we comfortable with the current restrictions? 
+
+* Should we be aiming to support Unicode? Or is that a bridge too far
+  for now?
+
+  * Not sure what full implications would be, but supporting Unicode
+    could make storage specs and implementations harder to develop.
+
+===
+
+### Node names - case (in)sensitivity
+
+* N.B., some file systems are case sensitive, some are not.
+
+* This can ([and
+  has](https://github.com/cggh/scikit-allel/issues/215#issuecomment-434088283))
+  led to bugs with the zarr v2 protocol when used with file system
+  storage on different operating systems.
+  
+* Hard to resolve without annoying users (e.g., force all names to
+  lower case) or increasing implementation complexity (e.g., check for
+  case-insensitive name clashes).
+  
+* I'm not happy with the spec's current approach to this.