update_relative_links

camaraproject · Aug 14, 2024 · 85f1c15 · 85f1c15
1 parent cc707ac
commit 85f1c15
Show file tree

Hide file tree

Showing 3 changed files with 27 additions and 27 deletions.
diff --git a/documentation/API-design-guidelines.md b/documentation/API-design-guidelines.md
@@ -1641,7 +1641,7 @@ but the 'eventType' attribute is used to distinguish distinct events subscribed.
 To ease developer adoption,
 the pattern for Resource-based event subscription should be consistent with all API providing this feature.
 
-CAMARA subscription model leverages **[CloudEvents](https://cloudevents.io/)** and is based on release [0.1-wip](https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md) as it is a vendor-neutral specification for defining the format of subscription. A generic neutral CloudEvent subscription OpenAPI specification is available in [Commonalities/artifacts/camara-cloudevents](../artifacts/camara-cloudevents) directory (event-subscription-template.yaml).
+CAMARA subscription model leverages **[CloudEvents](https://cloudevents.io/)** and is based on release [0.1-wip](https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md) as it is a vendor-neutral specification for defining the format of subscription. A generic neutral CloudEvent subscription OpenAPI specification is available in [Commonalities/artifacts/camara-cloudevents](/artifacts/camara-cloudevents/) directory (event-subscription-template.yaml).
 
 To ensure consistency across Camara subprojects, it is necessary that explicit subscriptions are handled within separate API/s. It is mandatory to append the keyword "subscriptions" at the end of the API name. For e.g. device-roaming-subscriptions.yaml
 
@@ -1738,7 +1738,7 @@ The Following Error codes must be present:
 * for `GET .../{subscriptionId}`: 400, 401, 403, 404, 500, 503
 * for `DELETE`: 400, 401, 403, 404, 500, 503
 
-Please see in [Commonalities/artifacts/camara-cloudevents](../artifacts/camara-cloudevents) directory ``event-subscription-template.yaml`` for more information and error examples. 
+Please see in [Commonalities/artifacts/camara-cloudevents](/artifacts/camara-cloudevents) directory ``event-subscription-template.yaml`` for more information and error examples. 
 
 
 ##### Termination for resource-based (explicit) subscription
@@ -1978,7 +1978,7 @@ response:
 
 ## Appendix A: `info.description` template for `device` identification from access token
 
-The documentation template below is recommended to be used as part of the API documentation in `info.description` property in the CAMARA API specs which use the `device`object defined in [CAMARA_common.yaml](../artifacts/CAMARA_common.yaml) artifact. This template provides guidance on how to handle device information in API requests **when using 3-legged access tokens and the device can be uniquely identified by the token**.
+The documentation template below is recommended to be used as part of the API documentation in `info.description` property in the CAMARA API specs which use the `device`object defined in [CAMARA_common.yaml](/artifacts/CAMARA_common.yaml) artifact. This template provides guidance on how to handle device information in API requests **when using 3-legged access tokens and the device can be uniquely identified by the token**.
 
 Note: With the current 3-legged authorization flows used by CAMARA, only a single end user can be associated with the access token. For the OIDC authorization code flow, only a single device can call the `/authorize` endpoint and get the code. And for CIBA, `login_hint` is currently limited to a single phone number or IP address (which can optionally include a port).
 

diff --git a/documentation/Issue and PR template Howto.md b/documentation/Issue and PR template Howto.md
@@ -16,7 +16,7 @@ GitHub uses templates for the repository if the respective template configuratio
 
 To use templates for issues and pull request for the CAMARA Subproject, the following steps need to be taken:
 
-1.) Copy the folder [.github](../artifacts/Github_templates/.github)
+1.) Copy the folder [.github](/artifacts/Github_templates/.github)
 to the root of Subproject repository.
 
 2.) Edit the `config.yml` file inside `.github/ISSUE_TEMPLATE/` folder:

diff --git a/documentation/Linting-rules.md b/documentation/Linting-rules.md
@@ -84,7 +84,7 @@ CAMARA API specification files include inline documentation.
 
 The description attributes should be checked for typos.
 
-_Spectral rule_: [camara-language-spelling](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-language-spelling](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -105,7 +105,7 @@ See also [CAMARA Glossary](Glossary.md)
 | `mobile network`         | `network`              |
 
 
-_Spectral rule_: [camara-language-avoid-telco](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-language-avoid-telco](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `hint`
 
@@ -128,7 +128,7 @@ The API functionalities must be implemented following the specifications of the
 |--------------------------|------------------------|
 | `openapi: 3.0.1`         | `openapi: 3.0.3`       |
 
-_Spectral rule_: [camara-oas-version](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-oas-version](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -141,7 +141,7 @@ API Design Guidelines:
 Info object must include the following information: API title with public name.
 
 
-_Spectral rule_: [camara-info−title](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-info−title](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -153,7 +153,7 @@ API Design Guidelines:
 Info object must include the following information: API Version in the format: X.Y.Z.
 
 
-_Spectral rule_: [camara-info−version-format](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-info−version-format](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn` <br>
 ❕ Note: Currently the format like  `version: 0.10.0-wip` is used in the API development branch
@@ -173,7 +173,7 @@ Point 2 The attribute must be identifying itself, it is not enough with "{id}"
 |--------------------------------------|------------------------------------------|
 | `/users/{id}/documents/{documentId}` | `/users/{userId}/documents/{documentId}` |
 
-_Spectral rule_: [camara-path-param-id](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-path-param-id](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -186,7 +186,7 @@ Point 3 The identifier should have a similar morphology on all endpoints. For ex
 | `/vehicles/{vehicleId}`                |
 | `/users/{userId}/vehicles/{vehicleId}` |
 
-_Spectral rule_: [camara-path-param-id-morphology](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-path-param-id-morphology](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -196,7 +196,7 @@ Sensitive data (msisdn/imsi) cannot be a path or query parameter.
 <br>❕ Note: Needs to list down if we have other sensitive parameters other than MSISDN/IMSI - cf.  *monite-security-no-secrets-in-path-or-query-parameters*
 
 
-_Spectral rule_: [camara-security-no-secrets-in-path-or-query-parameters](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-security-no-secrets-in-path-or-query-parameters](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -207,7 +207,7 @@ API Design Guidelines:
 
 Valid methods are: GET, PUT, POST, DELETE, PATCH, OPTIONS
 
-_Spectral rule_: [camara-http-methods](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-http-methods](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -216,7 +216,7 @@ _Spectral rule_: [camara-http-methods](../artifacts/linting_rules/.spectral.yml)
 'GET' and 'DELETE' http methods MUST NOT accept a 'requestBody' attribute 
 <br>❕ Note: https://github.com/team-monite/api-style-guide/blob/main/spectral/monite.section8-requests.yaml
 
-_Spectral rule_: [camara-get-no-request-body](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-get-no-request-body](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -244,14 +244,14 @@ A reserved word is one whose usage is reserved by any of the following Open API
 - [OpenAPI Generator (Kotlin)](https://openapi-generator.tech/docs/generators/kotlin/#reserved-words)
 - [OpenAPI Generator (Swift5)](https://openapi-generator.tech/docs/generators/swift5#reserved-words)
 
-_Spectral rule_: [camara-reserved-words](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-reserved-words](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
 
 Resource names must not contain the method name: get, put, post, delete, patch.
 
-_Spectral rule_: [camara-resource-reserved-words](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-resource-reserved-words](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -262,37 +262,37 @@ API Design Guidelines: [11.2 Published routes](API-design-guidelines.md#112-publ
 
 Functionality methods must have a description.
 
-_Spectral rule_: [camara-routes-descriptions](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-routes-descriptions](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
 API Design Guidelines: [11.3 Request Parameters](API-design-guidelines.md#113-request-parameters)
 
 All parameters must have a description. 
 
-_Spectral rule_: [camara-parameters-descriptions](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-parameters-descriptions](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
 API Design Guidelines: [11.4 Response Structure](API-design-guidelines.md#114-response-structure)
 
 All response objects must have a description. 
 
-_Spectral rule_: [camara-response-descriptions](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-response-descriptions](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
 API Design Guidelines: [11.5 Data Definitions](API-design-guidelines.md#115-data-definitions)
 
 All properties within the object must have a description. 
 
-_Spectral rule_: [camara-properties-descriptions](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-properties-descriptions](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
 API Design Guidelines: [11.2 Published Routes](API-design-guidelines.md#112-published-routes)
 Summary must be defined on each operation, describing with a short summary what the operation does.  
-_Spectral rule_: [camara-operation-summary](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-operation-summary](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`
 
@@ -303,7 +303,7 @@ API Design Guidelines:
 
 When request bodies or response payloads may be one of a number of different schemas (containing `oneOf` or `anyOf` section), a `discriminator` object can be used to aid in serialization, deserialization, and validation. 
 
-_Spectral rule_: [camara-discriminator-use](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-discriminator-use](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `hint`
 
@@ -327,7 +327,7 @@ API Design Guidelines: **No clear requirement**
 
 ❓ This rule verifies that `enum` fields contain values that follow a specific case convention: `macro`.
 
-_Spectral rule_: [camara-enum-casing-convention](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-enum-casing-convention](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `info`
 
@@ -341,7 +341,7 @@ API Design Guidelines:
 
 Operation ids should follow a specific case convention: `camel` case.
 
-_Spectral rule_: [camara-operationid-casing-convention](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-operationid-casing-convention](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -352,7 +352,7 @@ API Design Guidelines: [4.1 URL Definition](API-design-guidelines.md#41-url-defi
 
 Path parameter should follow a specific case convention, with the default being `kebab` case.
 
-_Spectral rule_: [camara-parameter-casing-convention](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-parameter-casing-convention](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -366,7 +366,7 @@ API Design Guidelines: [4.1 URL Definition](API-design-guidelines.md#41-url-defi
 
 Property names should follow a specific case convention, with the default being `camel` case.
 
-_Spectral rule_: [camara-property-casing-convention](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-property-casing-convention](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `error`
 
@@ -377,7 +377,7 @@ API Design Guidelines: **No clear requirement**
 Schema names (the keys in `components -> schemas`) should follow the "upper camel case" convention - `pascal`
 
 
-_Spectral rule_: [camara-schema-casing-convention](../artifacts/linting_rules/.spectral.yml)
+_Spectral rule_: [camara-schema-casing-convention](/artifacts/linting_rules/.spectral.yml)
 
 *Severity*: `warn`