Fix a lot of typos (#2778)

CHANGELOG.md

@@ -589,7 +589,7 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 
 ### Traces
 
-- Prefer global user defined limits over model-sepcific default values.
+- Prefer global user defined limits over model-specific default values.
   ([#1893](https://github.com/open-telemetry/opentelemetry-specification/pull/1893))
 - Generalize the "message" event to apply to all RPC systems not just gRPC
   ([#1914](https://github.com/open-telemetry/opentelemetry-specification/pull/1914))

internal/tools/schema_check.sh

@@ -8,7 +8,7 @@ set -e
 
 BUILD_TOOL_SCHEMAS_VERSION=0.13.0
 
-# List of vesions that do not require or have a schema.
+# List of versions that do not require or have a schema.
 declare -a skip_versions=("1.0.0" "1.0.1" "1.1.0" "1.2.0" "1.3.0" "1.6.0")
 
 root_dir=$PWD

specification/compatibility/opencensus.md

@@ -66,7 +66,7 @@ Finally, the Application would update all usages of OpenCensus to OpenTelemetry.
 OpenCensus supports two primary types of telemetry: Traces and Stats (Metrics).
 Compatibility for these is defined separately.
 
-> The overridding philosophy for compatibility is that OpenCensus instrumented
+> The overriding philosophy for compatibility is that OpenCensus instrumented
 > libraries and applications need make *no change* to their API usage in order
 > to use OpenTelemetry. All changes should be solely configuration / setup.
 
@@ -109,7 +109,7 @@ OpenTelemetry.
 
 Below are listed known incompatibilities between OpenTelemetry and OpenCensus
 specifications.   Applications leveraging unspecified behavior from OpenCensus
-that *is* specified incompatibly within OpenTelemetry are not eligble for
+that *is* specified incompatibly within OpenTelemetry are not eligible for
 using the OpenCensus <-> OpenTelemetry bridge.
 
 1. In OpenCensus, there is [no specification](https://github.com/census-instrumentation/opencensus-specs/blob/master/trace/Span.md#span-creation)
@@ -127,7 +127,7 @@ using the OpenCensus <-> OpenTelemetry bridge.
 4. TraceFlags in both OpenCensus and OpenTelemetry only specify the single
    `sampled` flag ([OpenTelemetry](../trace/api.md#spancontext),
    [OpenCensus](https://github.com/census-instrumentation/opencensus-specs/blob/master/trace/TraceConfig.md#traceparams)).
-   Some OpenCensus APIs support "debug" and "defer" tracing flags in additon to
+   Some OpenCensus APIs support "debug" and "defer" tracing flags in addition to
    "sampled".  In this case, the OpenCensus bridge will do its best to support
    and translate unspecified flags into the closest OpenTelemetry equivalent.
 

specification/compatibility/opentracing.md

@@ -121,7 +121,7 @@ Parameters:
 - An optional explicit start timestamp, a numeric value.
 
 For OpenTracing languages implementing the [ScopeManager](#scopemanager-shim)
-interface, the folllowing parameters are defined as well:
+interface, the following parameters are defined as well:
 
 - An optional boolean specifying whether the current `Span`
   should be ignored as automatic parent.

specification/error-handling.md

@@ -27,7 +27,7 @@ OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.
    In general, internal exceptions should only affect the execution context of the request that caused the exception.
 4. Internal error handling should follow language-specific conventions.
    In general, developers should minimize the scope of error handlers and add special processing for expected exceptions.
-5. Beware external callbacks and overrideable interfaces: Expect them to throw.
+5. Beware external callbacks and overridable interfaces: Expect them to throw.
 6. Beware to call any methods that wasn't explicitly provided by API and SDK users as a callbacks.
    Method `ToString` that SDK may decide to call on user object may be badly implemented and lead to stack overflow.
    It is common that the application never calls this method and this bad implementation would never be caught by an application owner.

specification/metrics/data-model.md

@@ -864,7 +864,7 @@ boundary could be mapped into the incorrect bucket due to inaccuracy.
 Defining an exact mapping function is out of scope for this document.
 
 However, when inputs are an exact power of two, it is possible to
-calculate the exactly corect bucket index.  Since it is relatively
+calculate the exactly correct bucket index.  Since it is relatively
 simple to check for exact powers of two, implementations SHOULD
 apply such a special case:
 
@@ -1312,7 +1312,7 @@ type-specific suffixes, such as `_total` for counters, the unit MUST be trimmed
 from the suffix as well, if the metric suffix matches the unit.
 
 The [OpenMetrics HELP metadata](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#metricfamily),
-if present, MUST be added as the desciption of the OTLP metric.
+if present, MUST be added as the description of the OTLP metric.
 
 The [OpenMetrics TYPE metadata](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#metricfamily),
 if present, MUST be used to determine the OTLP data type, and dictates

specification/sdk-configuration.md

@@ -32,7 +32,7 @@ All other configuration mechanisms SHOULD be built on top of this interface.
 An example of this programmatic interface is accepting a well-defined
 struct on an SDK builder class. From that, one could build a CLI that accepts a
 file (YAML, JSON, TOML, ...) and then transforms into that well-defined struct
-consumable by the programatic interface.
+consumable by the programmatic interface.
 
 ### Other Mechanisms
 

specification/sdk-environment-variables.md

@@ -185,7 +185,7 @@ Environment variables specific for the `udp/thrift.binary` transport protocol:
 | OTEL_EXPORTER_ZIPKIN_ENDPOINT | Endpoint for Zipkin traces | <!-- markdown-link-check-disable --> "http://localhost:9411/api/v2/spans"<!-- markdown-link-check-enable --> |
 | OTEL_EXPORTER_ZIPKIN_TIMEOUT  | Maximum time the Zipkin exporter will wait for each batch export | 10s                                                                                              |
 
-Addtionally, the following environment variables are reserved for future
+Additionally, the following environment variables are reserved for future
 usage in Zipkin Exporter configuration:
 
 - `OTEL_EXPORTER_ZIPKIN_PROTOCOL`
@@ -245,7 +245,7 @@ Known values for `OTEL_LOGS_EXPORTER` are:
 
 Known values for `OTEL_METRICS_EXEMPLAR_FILTER` are:
 
-- `"none"`: No measurements are eligble for exemplar sampling.
+- `"none"`: No measurements are eligible for exemplar sampling.
 - `"all"`: All measurements are eligible for exemplar sampling.
 - `"with_sampled_trace"`: Only allow measurements with a sampled parent span in context.