|
| 1 | +# zarr-extensions |
| 2 | + |
| 3 | +This repository contains the specification for Zarr extensions for the [Zarr version 3 specification](https://zarr-specs.readthedocs.io/en/latest/v3/core/v3.0.html). |
| 4 | + |
| 5 | +It is the normative source for registering names of Zarr v3 extensions. |
| 6 | + |
| 7 | +## Registering an extension |
| 8 | + |
| 9 | +To register an extension, open a new PR with a new extension directory under the relevant extension point: |
| 10 | + |
| 11 | + * [Codecs](./codecs/README.md) |
| 12 | + * [Data Types](./dtype/README.md) |
| 13 | + * [Chunk Key Encoding](./chunk-key-encodings/README.md) |
| 14 | + * [Chunk Grid](./chunk-grids/README.md) |
| 15 | + * [Storage Transformers](./storage-transformers/README.md) |
| 16 | + |
| 17 | +Each extension MUST have a `README.md` file that describes the extension and its metadata specification. |
| 18 | +Extensions SHOULD have a `schema.json` file that contains the JSON schema for the metadata, if the README.md does not provide a link to an external schema. |
| 19 | +Please note that all extensions documents will be licensed under the [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/). |
| 20 | +Only open a PR if you are willing to license your extension under this license. |
| 21 | + |
| 22 | +The PR will be reviewed by the [Zarr steering council](https://github.com/orgs/zarr-developers/teams/steering-council). |
| 23 | +We aim to be very open about registering extensions. |
| 24 | +The review will be done largely based on avoiding confusing extension names and preventing malicious activity as well as maintaining the formal requirements of the extensions. |
| 25 | +Extension maintainers are responsible for their extensions. |
| 26 | +Updates to the extensions will also be reviewed by the steering council. |
| 27 | + |
| 28 | + |
| 29 | +## Document conventions |
| 30 | + |
| 31 | +These conventions are used for all extension specification documents in this repository. |
| 32 | + |
| 33 | +Conformance requirements are expressed with a combination of descriptive |
| 34 | +assertions and [RFC2119] terminology. The key words "MUST", "MUST NOT", |
| 35 | +"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", |
| 36 | +and "OPTIONAL" in the normative parts of specification documents are to be interpreted as |
| 37 | +described in [RFC2119]. However, for readability, these words do not appear in |
| 38 | +all uppercase letters in specification documents. |
| 39 | + |
| 40 | +All of the text of specification documents are normative except sections explicitly |
| 41 | +marked as non-normative, examples, and notes. Examples in specification documents are |
| 42 | +introduced with the words "for example". |
| 43 | + |
| 44 | +[RFC2119] S. Bradner. Key words for use in RFCs to Indicate |
| 45 | + Requirement Levels. March 1997. Best Current Practice. URL: |
| 46 | + https://tools.ietf.org/html/rfc2119 |
| 47 | + |
| 48 | +[RFC2119]: https://tools.ietf.org/html/rfc2119 |
| 49 | + |
| 50 | +## License |
| 51 | + |
| 52 | +All extensions are licensed under the [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/). |
0 commit comments