Support suffix for metadata files #63
Assignees
Labels
Comments
alimanfoo
added
the
core-protocol-v3.0
|
Add something like : |
Carreau
added a commit
to Carreau/zarr-specs
that referenced
this issue
Oct 12, 2020
Closes zarr-developers#63 The rational is that backends may be explored by non zarr-aware tools, like a filesytem and a GUI browser like Finder/Explorer/Nautilus, and the `.json` extension will help to view/edit json in those. While it may seem like this shoudl be store specific, once again the fact that a zarr-hierarchy can be copied from one storage to another by non-zarr-aware tool indicate that this shoudl be handled above the sotre level.
Carreau
added a commit
to Carreau/zarr-specs
that referenced
this issue
Oct 12, 2020
Closes zarr-developers#63 The rational is that backends may be explored by non zarr-aware tools, like a filesytem and a GUI browser like Finder/Explorer/Nautilus, and the `.json` extension will help to view/edit json in those. While it may seem like this shoudl be store specific, once again the fact that a zarr-hierarchy can be copied from one storage to another by non-zarr-aware tool indicate that this shoudl be handled above the sotre level.
Merged
|
An alternative is that the extension is determined by As the spec is right now, if you specify a non-default |
|
The default |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the current v3 core protocol draft, keys for metadata documents have no suffix to represent the document format, they are just keys like "meta/root/foo.group" and "meta/root/foo/bar.array". In some situations (e.g., where file systems or web servers are being used as storage) it would be useful to have a suffix that indicates the format, i.e., ".json" for the default. Consider adding support for this.
The text was updated successfully, but these errors were encountered: