Add anchors to misc. docs

Signed-off-by: Mrunal Patel <[email protected]>

Author: mrunalp

implementations.md

@@ -1,18 +1,18 @@
-# Implementations
+# <a name="implementations" />Implementations
 
 The following sections link to associated projects, some of which are maintained by the OCI and some of which are maintained by external organizations.
 If you know of any associated projects that are not listed here, please file a pull request adding a link to that project.
 
-## Runtime (Container)
+## <a name"implementationsRuntimeContainer" />Runtime (Container)
 
 * [opencontainers/runc](https://github.com/opencontainers/runc) - Reference implementation of OCI runtime
 
-## Runtime (Virtual Machine)
+## <a name="implementationsRuntimeVirtualMachine" />Runtime (Virtual Machine)
 
 * [hyperhq/runv](https://github.com/hyperhq/runv) - Hypervisor-based runtime for OCI
 * [01org/cc-oci-runtime](https://github.com/01org/cc-oci-runtime) - Hypervisor-based OCI runtime for Intel® Architecture
 
-## Testing & Tools
+## <a name="implementationsTestingTools" />Testing & Tools
 
 * [kunalkushwaha/octool](https://github.com/kunalkushwaha/octool) - A config linter and validator.
 * [huawei-openlab/oct](https://github.com/huawei-openlab/oct) - Open Container Testing framework for OCI configuration and runtime

project.md

@@ -1,6 +1,6 @@
-# Project docs
+# <a name="projectDocs" />Project docs
 
-## Release Process
+## <a name="projectReleaseProcess" />Release Process
 
 * Increment version in [`specs-go/version.go`](specs-go/version.go)
 * `git commit` version increment

spec.md

@@ -1,23 +1,23 @@
-# Open Container Initiative Runtime Specification
+# <a name="openContainerInitiativeRuntimeSpecification" />Open Container Initiative Runtime Specification
 
 The [Open Container Initiative](http://www.opencontainers.org/) develops specifications for standards on Operating System process and application containers.
 
-# Abstract
+# <a name="ociRuntimeSpecAbstract" />Abstract
 
 The OCI Runtime Specification aims to specify the configuration, execution environment, and lifecycle a container.
 
 A container's configuration is specified as the `config.json` for the supported platforms and details the fields that enable the creation of a container.
 The execution environment is specified to ensure that applications running inside a container have a consistent environment between runtimes along with common actions defined for the container's lifecycle.
 
-# Platforms
+# <a name="ociRuntimeSpecPlatforms" />Platforms
 
 Platforms defined by this specification are:
 
 * `linux`: [runtime.md](runtime.md), [config.md](config.md), [config-linux.md](config-linux.md), and [runtime-linux.md](runtime-linux.md).
 * `solaris`: [runtime.md](runtime.md), [config.md](config.md), and [config-solaris.md](config-solaris.md).
 * `windows`: [runtime.md](runtime.md), [config.md](config.md), and [config-windows.md](config-windows.md).
 
-# Table of Contents
+# <a name="ociRuntimeSpecTOC" />Table of Contents
 
 - [Introduction](spec.md)
     - [Notational Conventions](#notational-conventions)
@@ -31,7 +31,7 @@ Platforms defined by this specification are:
     - [Windows-specific Configuration](config-windows.md)
 - [Glossary](glossary.md)
 
-# Notational Conventions
+# <a name="ociRuntimeSpecNotationalConventions" />Notational Conventions
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119][rfc2119].
 

style.md

@@ -1,29 +1,29 @@
-# Style and conventions
+# <a name="styleAndConventions" />Style and conventions
 
-## One sentence per line
+## <a name="styleOneSentence" />One sentence per line
 
 To keep consistency throughout the Markdown files in the Open Container spec all files should be formatted one sentence per line.
 This fixes two things: it makes diffing easier with git and it resolves fights about line wrapping length.
 For example, this paragraph will span three lines in the Markdown source.
 
-## Traditionally hex settings should use JSON integers, not JSON strings
+## <a name="styleHex" />Traditionally hex settings should use JSON integers, not JSON strings
 
 For example, [`"classID": 1048577`][class-id] instead of `"classID": "0x100001"`.
 The config JSON isn't enough of a UI to be worth jumping through string <-> integer hoops to support an 0x… form ([source][integer-over-hex]).
 
-## Constant names should keep redundant prefixes
+## <a name="styleConstantNames" />Constant names should keep redundant prefixes
 
 For example, `CAP_KILL` instead of `KILL` in [**`linux.capabilities`**][capabilities].
 The redundancy reduction from removing the namespacing prefix is not useful enough to be worth trimming the upstream identifier ([source][keep-prefix]).
 
-## Optional settings should not have pointer Go types
+## <a name="styleOptionalSettings" />Optional settings should not have pointer Go types
 
 Because in many cases the Go default for the type is a no-op in the spec (sources [here][no-pointer-for-strings], [here][no-pointer-for-slices], and [here][no-pointer-for-boolean]).
 The exceptions are entries where we need to distinguish between “not set” and “set to the Go default for that type” ([source][pointer-when-updates-require-changes]), and this decision should be made on a per-setting case.
 
 ## Examples
 
-### Anchoring
+### <a name="styleAnchoring" />Anchoring
 
 For any given section that provides a notable example, it is ideal to have it denoted with [markdown headers][markdown-headers].
 The level of header should be such that it is a subheader of the header it is an example of.
@@ -47,7 +47,7 @@ To use Some Topic, ...
 
 ```
 
-### Content
+### <a name="styleContent" />Content
 
 Where necessary, the values in the example can be empty or unset, but accommodate with comments regarding this intention.