Correct links (#106)

**What this PR does / why we need it**:
correct links and markdown files style

.github/.markdownlint.yml

@@ -1,4 +1,5 @@
 default: true
 
 MD013: false #https://github.com/DavidAnson/markdownlint/blob/HEAD/doc/Rules.md#md013
+MD029: false #https://github.com/DavidAnson/markdownlint/blob/HEAD/doc/Rules.md#md033
 MD033: false #https://github.com/DavidAnson/markdownlint/blob/HEAD/doc/Rules.md#md033

CONTRIBUTING.md

@@ -1,5 +1,5 @@
-Welcome to the OCM community!
+# Welcome to the OCM community
 
 We welcome many different types of contributions.
 
-Please refer to the [Contributing Guide in the Community repository](https://github.com/open-component-model/community/blob/main/CONTRIBUTING.md) for more information on how to get support from maintainers, find work to contribute, the Pull Request checklist, the Pull Request process, and other useful information on contributing to the OCM projects.
+Please refer to the [Contributing Guide in the Community repository](https://github.com/open-component-model/community/blob/main/CONTRIBUTING.md) for more information on how to get support from maintainers, find work to contribute, the Pull Request checklist, the Pull Request process, and other useful information on contributing to the OCM projects.

doc/01-model/01-model.md

@@ -8,7 +8,6 @@ The Open Compoment Model consists of a core model plus extensions. The core mode
 
 The following chapters will provide more details about these concepts.
 
-
 ## Components and Component Versions
 
 Usually, complex software products are divided into logical units (called components in this specification). A component is typically maintained in a version control system. It has a build procedure generating binary artifacts from source code and a release process to make it available for consumers. Usually, releases are repeated from time to time, making new versions available. A component is a logical unit within a software product. It is a semantic bracket around software pieces belonging together because they fulfill a specific purpose. E.g. like, "This is the Frontend Component," "This is the Database component," and "This is the Kubernetes vertical autoscale component."

doc/01-model/02-elements-toplevel.md

@@ -21,11 +21,7 @@ A *Component* is technically defined by a globally unique identifier.
 
 The component identity uses the following naming scheme:
 
-<div>
-
-*&lt;DNS domain>* `/` *&lt;name component> {* `/` *&lt;name component> }*
-
-</div>
+*\<DNS domain>* `/` *\<name component>* { `/` *\<name component>* }
 
 Hereby the DNS domain plus optionally any number of leading name components MUST
 be owned by the provider of a component. For example, `github.com`, as DNS domain
@@ -42,6 +38,7 @@ specification (e.g. `github.com/gardener/external-dns-management:0.15.1`).
 ## Artifacts (Resources and Sources)
 
 The Open Component Model distinguishes two kinds of artifacts:
+
 - *Sources* are optional artifacts that contain the sources, which
   were used to generate the deployment-relevant *Resources*.
 - *Resources* are artifacts that finally make up the deployment-relevant set of artifacts.
@@ -71,7 +68,6 @@ Those attributes are described by formal fields in the component descriptor:
 
   The access specification for the actual artifact (see below)
 
-
 ### Artifact Types
 
 The formal type of an artifact uniquely specifies the logical interpretation of an artifact and its kind,
@@ -161,7 +157,7 @@ There are two kinds of types:
 
   So, the complete pattern looks as follows:
 
-  ```
+  ```text
   <DNS domain name>/[a-z][a-zA-Z0-9]*
   ```
 
@@ -206,8 +202,8 @@ In addition to the common artifact information, a resource may optionally descri
 A resource uses the following additional formal fields:
 
 - **`relation`** (required) *string['local', 'external']*
-  Indicates whether the entity providing a component is also the provider of the resource ('local') or whether the 
-  resource is provided by a separate entity ('external'). This may be useful to determine whether the entity responsible 
+  Indicates whether the entity providing a component is also the provider of the resource ('local') or whether the
+  resource is provided by a separate entity ('external'). This may be useful to determine whether the entity responsible
   for the component is also responsible for the resource.  
   This property is purely informational and completely unrelated to the access method type.
 
@@ -223,12 +219,12 @@ A resource uses the following additional formal fields:
   This field is used to describe the sources used to generate the resource.
   The selection is done by the following two fields:
 
-    - **`identitySelector`** *map[string]string*
+  - **`identitySelector`** *map[string]string*
 
       Identity attributes determining an appropriate source
       element.
 
-    - **`labels`** (optional) *[]Label*
+  - **`labels`** (optional) *[]Label*
 
       A list of arbitrary labels
 
@@ -285,6 +281,7 @@ A `references` element has the following fields:
   The extra identity of the referenced component.
 
 Example:
+
 ```yaml
 ...
   references:

doc/01-model/03-elements-sub.md

@@ -49,6 +49,7 @@ of constraints is then just a partial match of the set of identity attributes.
 You want to describe different image versions to be used
 for different Kubernetes versions deployed on different OS platforms and CPU architectures.
 With identity attributes this can be easily modeled by using
+
 - the `name` attribute for the purpose (e.g. OCM CLI)
 - the `version` attribute for the version
 - and an `extraIdentity` attribute for the intended Kubernetes OS platform and architecture
@@ -120,7 +121,7 @@ The content of a described artifact is accessible by applying its global identit
 <img src="ocmresourceaccess.png" alt="Structure of OCM Specification" width="800"/>
 </div>
 
-The access specification of an artifact may change when component versions are transported among repositories. 
+The access specification of an artifact may change when component versions are transported among repositories.
 
 Examples for access specification types are:
 
@@ -189,7 +190,7 @@ attributes are not allowed at the label entry level.
   They can be changed in any repository the component version has been transferred to.
   This is supported to attach evolving information to a component version.
   But it also implies, that a component version must be updatable (re-transferable) in a certain target repository.
-  This may lead to conflicting changes which might need to be resolved in a non-trivial way. 
+  This may lead to conflicting changes which might need to be resolved in a non-trivial way.
 
   The merge behaviour can be specified together with the label definition using the `merge` attribute.
   It has the following fields:
@@ -246,7 +247,6 @@ Every signature entry has the following formal fields:
 
   The signature for the specified digest.
 
-
 ## Digest Info
 
 A digest is specified by the following fields:

doc/01-model/06-conventions.md

@@ -26,6 +26,6 @@ If platform specific images are described as separate resources instead of using
 
 ## Selection of Usage Scenarios
 
-Usage scenarios for sets of described artifacts are best described by a dedicated [description artifacts](../../specification/contract/README.md#how-does-it-look-like-in-the-open-component-model) with a dedicated tool-specific artifact type. Here, there is the complete freedom to describe the conditions and environments artifacts are to be used. The artifacts are described by [relative resource references](../05-guidelines/03-references.md#relative-artifact-references) in relation to the component version containing the description artifact.
+Usage scenarios for sets of described artifacts are best described by a dedicated description artifact with a dedicated tool-specific artifact type. Here, there is the complete freedom to describe the conditions and environments artifacts are to be used. The artifacts are described by [relative resource references](../05-guidelines/03-references.md#relative-artifact-references) in relation to the component version containing the description artifact.
 
 Another possibility is to use dedicated [labels](./03-elements-sub.md#labels) to describe the usage scenario for dedicated artifacts. Here, the tool working on a component versions does not read a description artifact, but has to analyse the label settings of all the provided artifacts. In both cases there is a dedicated OCM specific interpretation of content provided by the component model. But while the first solution allows to describe a closed scenario in a dedicated resource, where resources from dependent component version can be described by relative resource references and multiple scenarios can be separated by multiple flavors of this resource, the label-based approach is restricted to a local component version and a single scenario. Instead of an artifact type for the description, labels with a defined [name structure](./03-elements-sub.md#labels) are required.