Skip to content

Commit

Permalink
manifest: DRY annotations and extensibility
Browse files Browse the repository at this point in the history
As I suggested in the PR landing these blocks [1,2,3].  I've shifted
the extensibility section to stand alone at the end of the file, and
pushed the annotations meat into the lower-level manifest
specification (linking there from the higher-level manifest-list
specification).

The extensibility requirements and annotations field might arguably
apply to our other JSON types as well, but I've left them off this
commit to focus on making the current requirements more DRY without
changing the specified behavior.

[1]: #164 (comment)
[2]: #164 (comment)
[3]: #164 (comment)

Signed-off-by: W. Trevor King <[email protected]>
  • Loading branch information
wking committed Sep 23, 2016
1 parent eebd585 commit ff9ead7
Showing 1 changed file with 6 additions and 18 deletions.
24 changes: 6 additions & 18 deletions manifest.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,20 +63,7 @@ A client will distinguish a manifest list from an image manifest based on the Co

- **`annotations`** *string-string map*

This OPTIONAL property contains arbitrary metadata for the manifest list.
Annotations MUST be a key-value map where both the key and value MUST be strings.
While the value MUST be present, it MAY be an empty string.
Keys MUST be unique within this map, and best practice is to namespace the keys.
Keys SHOULD be named using a reverse domain notation - e.g. `com.example.myKey`.
Keys using the `org.opencontainers` namespace are reserved and MUST NOT be used by other specifications.
If there are no annotations then this property MUST either be absent or be an empty map.
Implementations that are reading/processing manifest lists MUST NOT generate an error if they encounter an unknown annotation key.

See [Pre-Defined Annotation Keys](#pre-defined-annotation-keys).

### Extensibility
Implementations that are reading/processing manifest lists MUST NOT generate an error if they encounter an unknown property.
Instead they MUST ignore unknown properties.
This OPTIONAL property contains arbitrary metadata for the manifest list with the same semantics as the [manifest's `annotations`](#image-manifest-property-descriptions).

## Example Manifest List

Expand Down Expand Up @@ -157,10 +144,6 @@ Unlike the [Manifest List](#manifest-list), which contains information about a s

See [Pre-Defined Annotation Keys](#pre-defined-annotation-keys).

### Extensibility
Implementations that are reading/processing image manifests MUST NOT generate an error if they encounter an unknown property.
Instead they MUST ignore unknown properties.

## Example Image Manifest

*Example showing an image manifest:*
Expand Down Expand Up @@ -203,3 +186,8 @@ This specification defines the following annotation keys, which MAY be used by m
* **org.opencontainers.authors** contact details of the people or organization responsible for the image (freeform string)
* **org.opencontainers.homepage** URL to find more information on the image (string, must be a URL with scheme HTTP or HTTPS)
* **org.opencontainers.documentation** URL to get documentation on the image (string, must be a URL with scheme HTTP or HTTPS)

# Extensibility

Implementations that are reading/processing [manifests](#image-manifest) or [manifest lists](#manifest-list) MUST NOT generate an error if they encounter an unknown property.
Instead they MUST ignore unknown properties.

0 comments on commit ff9ead7

Please sign in to comment.