Core protocol v3.0 - node names #25
Conversation
| * must not be the empty string ("") | ||
|
|
||
| * must consist only of characters in the sets `a-z`, `A-Z`, `0-9`, | ||
| `-_.` |
There was a problem hiding this comment.
Is this too restrictive? I was thinking that node names are used in file paths when using file system storage, and so we should ensure no characters are used that could be problematic within a file system path. But are there other characters that people use in dataset naming that would be safe to include?
| 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. |
There was a problem hiding this comment.
This restriction is to deal with the situation where file system storage is used on a platform with a case insensitive file system, e.g., current default on mac I believe.
| `-_.` | ||
|
|
||
| * must not be a string composed only of period characters, e.g. "." or | ||
| ".." |
There was a problem hiding this comment.
Again this is to avoid node names that would be problematic in a file path.
| * must not be a string composed only of period characters, e.g. "." or | ||
| ".." | ||
|
|
||
| * must be at most 255 characters long |
There was a problem hiding this comment.
Again this is to avoid node names that would be problematic in a file path.
alimanfoo
force-pushed
the
core-protocol-v3.0-node-names
branch
from
794daa6
to
d1cc3e7
Compare
alimanfoo
changed the title
|
In the interests of having content together in one place, I'd like to merge this PR into the core-protocol-v3.0-dev branch. We can still discuss, revise and revisit anything after merge. I'll merge tomorrow if no objections. |
This PR adds a draft for the section on node names.