[chore] #189 standardise list symbol

docs/README.md

@@ -19,32 +19,32 @@ The benefit to using Semantic Conventions is in following a common naming scheme
 
 Semantic Conventions are defined for the following areas:
 
-* **[General](general/README.md): General Semantic Conventions**.
-* [CICD](cicd/README.md): Semantic Conventions for CICD systems.
-* [Cloud Providers](cloud-providers/README.md): Semantic Conventions for cloud providers libraries.
-* [CloudEvents](cloudevents/README.md): Semantic Conventions for the CloudEvents specification.
-* [Database](database/README.md): Semantic Conventions for database operations.
-* [Exceptions](exceptions/README.md): Semantic Conventions for exceptions.
-* [FaaS](faas/README.md): Semantic Conventions for Function as a Service (FaaS) operations.
-* [Feature Flags](feature-flags/README.md): Semantic Conventions for feature flag evaluations.
-* [Generative AI](gen-ai/README.md): Semantic Conventions for generative AI (LLM, etc.) operations.
-* [GraphQL](graphql/README.md): Semantic Conventions for GraphQL implementations.
-* [HTTP](http/README.md): Semantic Conventions for HTTP client and server operations.
-* [Messaging](messaging/README.md): Semantic Conventions for messaging operations and systems.
-* [Object Stores](object-stores/README.md): Semantic Conventions for object stores operations.
-* [RPC](rpc/README.md): Semantic Conventions for RPC client and server operations.
-* [System](system/README.md): System Semantic Conventions.
+- **[General](general/README.md): General Semantic Conventions**.
+- [CICD](cicd/README.md): Semantic Conventions for CICD systems.
+- [Cloud Providers](cloud-providers/README.md): Semantic Conventions for cloud providers libraries.
+- [CloudEvents](cloudevents/README.md): Semantic Conventions for the CloudEvents specification.
+- [Database](database/README.md): Semantic Conventions for database operations.
+- [Exceptions](exceptions/README.md): Semantic Conventions for exceptions.
+- [FaaS](faas/README.md): Semantic Conventions for Function as a Service (FaaS) operations.
+- [Feature Flags](feature-flags/README.md): Semantic Conventions for feature flag evaluations.
+- [Generative AI](gen-ai/README.md): Semantic Conventions for generative AI (LLM, etc.) operations.
+- [GraphQL](graphql/README.md): Semantic Conventions for GraphQL implementations.
+- [HTTP](http/README.md): Semantic Conventions for HTTP client and server operations.
+- [Messaging](messaging/README.md): Semantic Conventions for messaging operations and systems.
+- [Object Stores](object-stores/README.md): Semantic Conventions for object stores operations.
+- [RPC](rpc/README.md): Semantic Conventions for RPC client and server operations.
+- [System](system/README.md): System Semantic Conventions.
 
 Semantic Conventions by signals:
 
-* [Events](general/events.md): Semantic Conventions for event data.
-* [Logs](general/logs.md): Semantic Conventions for logs data.
-* [Metrics](general/metrics.md): Semantic Conventions for metrics.
-* [Profiles](general/profiles.md): Semantic Conventions for profiles.
-* [Resource](resource/README.md): Semantic Conventions for resources.
-* [Trace](general/trace.md): Semantic Conventions for traces and spans.
+- [Events](general/events.md): Semantic Conventions for event data.
+- [Logs](general/logs.md): Semantic Conventions for logs data.
+- [Metrics](general/metrics.md): Semantic Conventions for metrics.
+- [Profiles](general/profiles.md): Semantic Conventions for profiles.
+- [Resource](resource/README.md): Semantic Conventions for resources.
+- [Trace](general/trace.md): Semantic Conventions for traces and spans.
 
 Also see:
 
-* [How to write semantic conventions](how-to-write-conventions/README.md)
-* [Non-normative supplementary information](non-normative/README.md)
+- [How to write semantic conventions](how-to-write-conventions/README.md)
+- [Non-normative supplementary information](non-normative/README.md)

docs/app/README.md

@@ -8,6 +8,6 @@ linkTitle: App
 
 Semantic conventions for Apps are defined for the following signals:
 
-* [App Events](app-events.md)
+- [App Events](app-events.md)
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/azure/README.md

@@ -10,7 +10,7 @@ This document describes Azure Resource Logs, see [Azure Resource Log Top-level S
 
 Semantic conventions are defined for the following signals:
 
-* [Events](azure-events.md)
+- [Events](azure-events.md)
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status
 [AzureResourceSchema]: https://learn.microsoft.com/azure/azure-monitor/essentials/resource-logs-schema#top-level-common-schema

docs/browser/README.md

@@ -10,6 +10,6 @@ This document defines semantic conventions for Browser.
 
 Semantic conventions are defined for the following signals:
 
-* [Events](browser-events.md)
+- [Events](browser-events.md)
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/cicd/README.md

@@ -10,8 +10,8 @@ This document defines semantic conventions for Continuous Integration and Contin
 
 Semantic conventions for CICD are defined for the following signals:
 
-* [CICD Spans](cicd-spans.md): Semantic Conventions for CICD *spans*.
-* [CICD Metrics](cicd-metrics.md): Semantic Conventions for CICD *metrics*.
-* [CICD Logs](cicd-logs.md): Semantic Conventions for CICD *logs*.
+- [CICD Spans](cicd-spans.md): Semantic Conventions for CICD *spans*.
+- [CICD Metrics](cicd-metrics.md): Semantic Conventions for CICD *metrics*.
+- [CICD Logs](cicd-logs.md): Semantic Conventions for CICD *logs*.
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/cicd/cicd-metrics.md

@@ -41,9 +41,9 @@ but more may be added in the future.
 It might be useful to gather metrics specific to each pipeline run.<br>
 Examples of such metrics include:
 
-* host metrics like cpu, memory, disk of the worker on which a pipeline run executes
-* container metrics like cpu, memory requests and limits
-* runtime metrics of any processes executed as part of the pipeline run like JVM metrics
+- host metrics like cpu, memory, disk of the worker on which a pipeline run executes
+- container metrics like cpu, memory requests and limits
+- runtime metrics of any processes executed as part of the pipeline run like JVM metrics
 
 These metrics could be used to correlate build failures with environment issues like overload or out-of-memory.
 They could also be used in pipeline-level aggregations to inform adjustements of allocated worker resources.

docs/cicd/cicd-spans.md

@@ -159,9 +159,9 @@ it's RECOMMENDED to:
 The following attributes can be important for making sampling decisions
 and SHOULD be provided **at span creation time** (if provided at all):
 
-* [`cicd.pipeline.task.name`](/docs/registry/attributes/cicd.md)
-* [`cicd.pipeline.task.run.id`](/docs/registry/attributes/cicd.md)
-* [`cicd.pipeline.task.run.url.full`](/docs/registry/attributes/cicd.md)
+- [`cicd.pipeline.task.name`](/docs/registry/attributes/cicd.md)
+- [`cicd.pipeline.task.run.id`](/docs/registry/attributes/cicd.md)
+- [`cicd.pipeline.task.run.url.full`](/docs/registry/attributes/cicd.md)
 
 ---
 

docs/cli/README.md

@@ -8,6 +8,6 @@ linkTitle: CLI programs
 
 Semantic conventions for CLI programs are defined for the following signals:
 
-* [CLI Spans](cli-spans.md)
+- [CLI Spans](cli-spans.md)
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/database/README.md

@@ -15,43 +15,43 @@ database metrics and logs.
 > [v1.24.0 of this document](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/database/database-spans.md)
 > (or prior):
 >
-> * SHOULD NOT change the version of the database conventions that they emit by
+> - SHOULD NOT change the version of the database conventions that they emit by
 >   default in their existing major version. Conventions include (but are not
 >   limited to) attributes, metric and span names, and unit of measure.
-> * SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN`
+> - SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN`
 >   in their existing major version as a comma-separated list of category-specific values
 >   (e.g., http, databases, messaging). The list of values includes:
->   * `database` - emit the stable database conventions, and stop emitting
+>   - `database` - emit the stable database conventions, and stop emitting
 >     the experimental database conventions that the instrumentation emitted
 >     previously.
->   * `database/dup` - emit both the experimental and stable database conventions,
+>   - `database/dup` - emit both the experimental and stable database conventions,
 >     allowing for a phased rollout of the stable semantic conventions.
->   * The default behavior (in the absence of one of these values) is to continue
+>   - The default behavior (in the absence of one of these values) is to continue
 >     emitting whatever version of the old experimental database conventions
 >     the instrumentation was emitting previously.
->   * Note: `database/dup` has higher precedence than `database` in case both values are present
-> * SHOULD maintain (security patching at a minimum) their existing major version
+>   - Note: `database/dup` has higher precedence than `database` in case both values are present
+> - SHOULD maintain (security patching at a minimum) their existing major version
 >   for at least six months after it starts emitting both sets of conventions.
-> * MAY drop the environment variable in their next major version and emit only
+> - MAY drop the environment variable in their next major version and emit only
 >   the stable database conventions.
 
 Semantic conventions for database operations are defined for the following signals:
 
-* [DB Spans](database-spans.md): Semantic Conventions for database client *spans*.
-* [DB Metrics](database-metrics.md): Semantic Conventions for database operation *metrics*.
+- [DB Spans](database-spans.md): Semantic Conventions for database client *spans*.
+- [DB Metrics](database-metrics.md): Semantic Conventions for database operation *metrics*.
 
 Technology specific semantic conventions are defined for the following databases:
 
-* [AWS DynamoDB](dynamodb.md): Semantic Conventions for *AWS DynamoDB*.
-* [Cassandra](cassandra.md): Semantic Conventions for *Cassandra*.
-* [Azure Cosmos DB](cosmosdb.md): Semantic Conventions for *Azure Cosmos DB*.
-* [CouchDB](couchdb.md): Semantic Conventions for *CouchDB*.
-* [Elasticsearch](elasticsearch.md): Semantic Conventions for *Elasticsearch*.
-* [HBase](hbase.md): Semantic Conventions for *HBase*.
-* [MongoDB](mongodb.md): Semantic Conventions for *MongoDB*.
-* [Microsoft SQL Server](sql-server.md): Semantic Conventions for *Microsoft SQL Server*.
-* [Oracle Database](oracledb.md): Semantic Conventions for *Oracle Database*.
-* [Redis](redis.md): Semantic Conventions for *Redis*.
-* [SQL](sql.md): Semantic Conventions for *SQL* databases.
+- [AWS DynamoDB](dynamodb.md): Semantic Conventions for *AWS DynamoDB*.
+- [Cassandra](cassandra.md): Semantic Conventions for *Cassandra*.
+- [Azure Cosmos DB](cosmosdb.md): Semantic Conventions for *Azure Cosmos DB*.
+- [CouchDB](couchdb.md): Semantic Conventions for *CouchDB*.
+- [Elasticsearch](elasticsearch.md): Semantic Conventions for *Elasticsearch*.
+- [HBase](hbase.md): Semantic Conventions for *HBase*.
+- [MongoDB](mongodb.md): Semantic Conventions for *MongoDB*.
+- [Microsoft SQL Server](sql-server.md): Semantic Conventions for *Microsoft SQL Server*.
+- [Oracle Database](oracledb.md): Semantic Conventions for *Oracle Database*.
+- [Redis](redis.md): Semantic Conventions for *Redis*.
+- [SQL](sql.md): Semantic Conventions for *SQL* databases.
 
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/database/cassandra.md

@@ -147,13 +147,13 @@ Examples:
 The following attributes can be important for making sampling decisions
 and SHOULD be provided **at span creation time** (if provided at all):
 
-* [`db.collection.name`](/docs/registry/attributes/db.md)
-* [`db.namespace`](/docs/registry/attributes/db.md)
-* [`db.operation.name`](/docs/registry/attributes/db.md)
-* [`db.query.summary`](/docs/registry/attributes/db.md)
-* [`db.query.text`](/docs/registry/attributes/db.md)
-* [`server.address`](/docs/registry/attributes/server.md)
-* [`server.port`](/docs/registry/attributes/server.md)
+- [`db.collection.name`](/docs/registry/attributes/db.md)
+- [`db.namespace`](/docs/registry/attributes/db.md)
+- [`db.operation.name`](/docs/registry/attributes/db.md)
+- [`db.query.summary`](/docs/registry/attributes/db.md)
+- [`db.query.text`](/docs/registry/attributes/db.md)
+- [`server.address`](/docs/registry/attributes/server.md)
+- [`server.port`](/docs/registry/attributes/server.md)
 
 ---
 

docs/database/cosmosdb.md

@@ -251,11 +251,11 @@ Examples:
 The following attributes can be important for making sampling decisions
 and SHOULD be provided **at span creation time** (if provided at all):
 
-* [`db.collection.name`](/docs/registry/attributes/db.md)
-* [`db.namespace`](/docs/registry/attributes/db.md)
-* [`db.operation.name`](/docs/registry/attributes/db.md)
-* [`server.address`](/docs/registry/attributes/server.md)
-* [`server.port`](/docs/registry/attributes/server.md)
+- [`db.collection.name`](/docs/registry/attributes/db.md)
+- [`db.namespace`](/docs/registry/attributes/db.md)
+- [`db.operation.name`](/docs/registry/attributes/db.md)
+- [`server.address`](/docs/registry/attributes/server.md)
+- [`server.port`](/docs/registry/attributes/server.md)
 
 ---
 

docs/database/couchdb.md

@@ -73,10 +73,10 @@ Instrumentations SHOULD document how `error.type` is populated.
 The following attributes can be important for making sampling decisions
 and SHOULD be provided **at span creation time** (if provided at all):
 
-* [`db.namespace`](/docs/registry/attributes/db.md)
-* [`db.operation.name`](/docs/registry/attributes/db.md)
-* [`server.address`](/docs/registry/attributes/server.md)
-* [`server.port`](/docs/registry/attributes/server.md)
+- [`db.namespace`](/docs/registry/attributes/db.md)
+- [`db.operation.name`](/docs/registry/attributes/db.md)
+- [`server.address`](/docs/registry/attributes/server.md)
+- [`server.port`](/docs/registry/attributes/server.md)
 
 ---
 

docs/database/database-metrics.md

@@ -32,24 +32,24 @@ linkTitle: Metrics
 > [v1.24.0 of this document](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/database/database-spans.md)
 > (or prior):
 >
-> * SHOULD NOT change the version of the database conventions that they emit by
+> - SHOULD NOT change the version of the database conventions that they emit by
 >   default in their existing major version. Conventions include (but are not
 >   limited to) attributes, metric and span names, and unit of measure.
-> * SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN`
+> - SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN`
 >   in their existing major version as a comma-separated list of category-specific values
 >   (e.g., http, databases, messaging). The list of values includes:
->   * `database` - emit the stable database conventions, and stop emitting
+>   - `database` - emit the stable database conventions, and stop emitting
 >     the experimental database conventions that the instrumentation emitted
 >     previously.
->   * `database/dup` - emit both the experimental and stable database conventions,
+>   - `database/dup` - emit both the experimental and stable database conventions,
 >     allowing for a phased rollout of the stable semantic conventions.
->   * The default behavior (in the absence of one of these values) is to continue
+>   - The default behavior (in the absence of one of these values) is to continue
 >     emitting whatever version of the old experimental database conventions
 >     the instrumentation was emitting previously.
->   * Note: `database/dup` has higher precedence than `database` in case both values are present
-> * SHOULD maintain (security patching at a minimum) their existing major version
+>   - Note: `database/dup` has higher precedence than `database` in case both values are present
+> - SHOULD maintain (security patching at a minimum) their existing major version
 >   for at least six months after it starts emitting both sets of conventions.
-> * MAY drop the environment variable in their next major version and emit only
+> - MAY drop the environment variable in their next major version and emit only
 >   the stable database conventions.
 
 ## Database operation