chore: Perform spelling fixes identified by cspell #4728

CHANGELOG.md

@@ -194,10 +194,10 @@ release.
 
 ### Compatibility
 
-- Flexibilie escaping of characters that are discouraged by Prometheus Conventions
+- Introduced flexible escaping of characters that are discouraged by Prometheus Conventions
   in Prometheus exporters.
   ([#4533](https://github.com/open-telemetry/opentelemetry-specification/pull/4533))
-- Flexibilize addition of unit/type related suffixes in Prometheus exporters.
+- Introduced flexible addition of unit/type related suffixes in Prometheus exporters.
   ([#4533](https://github.com/open-telemetry/opentelemetry-specification/pull/4533))
 - Define the configuration option "Translation Strategies" for Prometheus exporters.
   ([#4533](https://github.com/open-telemetry/opentelemetry-specification/pull/4533))
@@ -611,7 +611,7 @@ release.
 
 ### Compatibility
 
-- Clarify prometheus exporter should have `host` and `port` configuration options.
+- Clarify Prometheus exporter should have `host` and `port` configuration options.
   ([#4147](https://github.com/open-telemetry/opentelemetry-specification/pull/4147))
 
 ### Common
@@ -793,7 +793,7 @@ release.
   ([#3945](https://github.com/open-telemetry/opentelemetry-specification/pull/3945))
 - Prometheus: represent Prometheus Info, StateSet and Unknown-typed metrics in OTLP.
   ([#3868](https://github.com/open-telemetry/opentelemetry-specification/pull/3868))
-- Update and reorganize the prometheus sdk exporter specification.
+- Update and reorganize the Prometheus sdk exporter specification.
   ([#3872](https://github.com/open-telemetry/opentelemetry-specification/pull/3872))
 
 ### SDK Configuration
@@ -993,7 +993,7 @@ release.
 
 - Add optional configuration for Prometheus exporters to promote resource attributes to metric attributes
   ([#3761](https://github.com/open-telemetry/opentelemetry-specification/pull/3761))
-- Clarifications and flexibility in Exemplar speicification.
+- Clarifications and flexibility in Exemplar specification.
   ([#3760](https://github.com/open-telemetry/opentelemetry-specification/pull/3760))
 
 ### Logs
@@ -1197,7 +1197,7 @@ release.
 
 - No changes.
 
-### Supplemenatary Guidelines
+### Supplementary Guidelines
 
 - No changes.
 
@@ -1252,7 +1252,7 @@ release.
 
 - No changes.
 
-### Supplemenatary Guidelines
+### Supplementary Guidelines
 
 - No changes.
 
@@ -1313,7 +1313,7 @@ release.
 
 - No changes.
 
-### Supplemenatary Guidelines
+### Supplementary Guidelines
 
 - No changes.
 
@@ -1363,7 +1363,7 @@ release.
   namespaces.
   ([#3507](https://github.com/open-telemetry/opentelemetry-specification/pull/3507))
 
-### Supplemenatary Guidelines
+### Supplementary Guidelines
 
 - No changes.
 
@@ -1442,7 +1442,7 @@ release.
 - Add log entries to specification README.md contents.
   ([#3435](https://github.com/open-telemetry/opentelemetry-specification/pull/3435))
 
-### Supplemenatary Guidelines
+### Supplementary Guidelines
 
 - Add guidance to use service-supported propagation formats as default for AWS SDK client calls.
   ([#3212](https://github.com/open-telemetry/opentelemetry-specification/pull/3212))
@@ -1583,13 +1583,13 @@ release.
 
 - Move X-Ray Env Variable propagation to span link instead of parent for AWS Lambda.
   ([#3166](https://github.com/open-telemetry/opentelemetry-specification/pull/3166))
-- Add heroku resource semantic conventions.
+- Add Heroku resource semantic conventions.
   [#3075](https://github.com/open-telemetry/opentelemetry-specification/pull/3075)
-- BREAKING: Rename faas.execution to faas.invocation_id
+- BREAKING: Rename `faas.execution` to `faas.invocation_id`
   ([#3209](https://github.com/open-telemetry/opentelemetry-specification/pull/3209))
-- BREAKING: Change faas.max_memory units to Bytes instead of MB
+- BREAKING: Change `faas.max_memory` units to Bytes instead of MB
   ([#3209](https://github.com/open-telemetry/opentelemetry-specification/pull/3209))
-- BREAKING: Expand scope of faas.id to cloud.resource_id
+- BREAKING: Expand scope of `faas.id` to `cloud.resource_id`
   ([#3188](https://github.com/open-telemetry/opentelemetry-specification/pull/3188))
 - Add Connect RPC specific conventions
   ([#3116](https://github.com/open-telemetry/opentelemetry-specification/pull/3116))
@@ -1689,7 +1689,7 @@ release.
 
 - Add condition with sum and count for Prometheus summaries
   ([3059](https://github.com/open-telemetry/opentelemetry-specification/pull/3059)).
-- Clarify prometheus unit conversions
+- Clarify Prometheus unit conversions
   ([#3066](https://github.com/open-telemetry/opentelemetry-specification/pull/3066)).
 - Define conversion mapping from OTel Exponential Histograms to Prometheus Native
   Histograms.
@@ -1932,7 +1932,7 @@ release.
   ([#2874](https://github.com/open-telemetry/opentelemetry-specification/pull/2874))
 - Add `process.paging.faults` metric to semantic conventions
   ([#2827](https://github.com/open-telemetry/opentelemetry-specification/pull/2827))
-- Define semantic conventions yaml for non-otlp conventions
+- Define semantic conventions yaml for Non-OTLP conventions
   ([#2850](https://github.com/open-telemetry/opentelemetry-specification/pull/2850))
 - Add more semantic convetion attributes of Apache RocketMQ
   ([#2881](https://github.com/open-telemetry/opentelemetry-specification/pull/2881))
@@ -1977,7 +1977,7 @@ release.
 - Changed the default buckets for Explicit Bucket Histogram to better match the
   official Prometheus clients.
   ([#2770](https://github.com/open-telemetry/opentelemetry-specification/pull/2770)).
-- Fix OpenMetrics valid label keys, and specify prometheus conversion for metric name.
+- Fix OpenMetrics valid label keys, and specify Prometheus conversion for metric name.
   ([#2788](https://github.com/open-telemetry/opentelemetry-specification/pull/2788))
 
 ### Logs
@@ -2230,7 +2230,7 @@ release.
 
 ### Common
 
-- Move non-otlp.md to common directory
+- Move `non-otlp.md` to common directory
   ([#2587](https://github.com/open-telemetry/opentelemetry-specification/pull/2587)).
 
 ## v1.11.0 (2022-05-04)
@@ -2339,7 +2339,7 @@ release.
   ([#2317](https://github.com/open-telemetry/opentelemetry-specification/pull/2317)).
 - Clarify that expectations for user callback behavior are documentation REQUIREMENTs.
   ([#2361](https://github.com/open-telemetry/opentelemetry-specification/pull/2361)).
-- Specify how to handle prometheus exemplar timestamp and attributes
+- Specify how to handle Prometheus exemplar timestamp and attributes
   ([#2376](https://github.com/open-telemetry/opentelemetry-specification/pull/2376))
 - Clarify that the periodic metric reader is the default metric reader to be
   paired with push metric exporters (OTLP, stdout, in-memory)
@@ -2348,7 +2348,7 @@ release.
   ([#2380](https://github.com/open-telemetry/opentelemetry-specification/pull/2380))
 - Clarify that MetricReader has one-to-one mapping to MeterProvider.
   ([#2406](https://github.com/open-telemetry/opentelemetry-specification/pull/2406)).
-- For prometheus metrics without sums, leave the sum unset
+- For Prometheus metrics without sums, leave the sum unset
   ([#2413](https://github.com/open-telemetry/opentelemetry-specification/pull/2413))
 - Specify default configuration for a periodic metric reader that is associated with
   the stdout metric exporter.
@@ -2599,7 +2599,7 @@ release.
   ([#1945](https://github.com/open-telemetry/opentelemetry-specification/pull/1945))
 - Add "IBM z/Architecture" (`s390x`) to `host.arch`
   ([#2055](https://github.com/open-telemetry/opentelemetry-specification/pull/2055))
-- BREAKING: Remove db.cassandra.keyspace and db.hbase.namespace, and clarify db.name
+- BREAKING: Remove `db.cassandra.keyspace` and `db.hbase.namespace`, and clarify db.name
   ([#1973](https://github.com/open-telemetry/opentelemetry-specification/pull/1973))
 - Add AWS App Runner as a cloud platform
   ([#2004](https://github.com/open-telemetry/opentelemetry-specification/pull/2004))
@@ -2703,7 +2703,7 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 ### OpenTelemetry Protocol
 
 - Add environment variables for configuring the OTLP exporter protocol (`grpc`, `http/protobuf`, `http/json`) ([#1880](https://github.com/open-telemetry/opentelemetry-specification/pull/1880))
-- Allow implementations to use their own default for OTLP compression, with `none` denotating no compression
+- Allow implementations to use their own default for OTLP compression, with `none` indicating no compression
   ([#1923](https://github.com/open-telemetry/opentelemetry-specification/pull/1923))
 - Clarify OTLP server components MUST support none/gzip compression
   ([#1955](https://github.com/open-telemetry/opentelemetry-specification/pull/1955))
@@ -2747,7 +2747,7 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 ### Semantic Conventions
 
 - Add mobile-related network state: `net.host.connection.type`, `net.host.connection.subtype` & `net.host.carrier.*` [#1647](https://github.com/open-telemetry/opentelemetry-specification/issues/1647)
-- Adding alibaba cloud as a cloud provider.
+- Adding Alibaba cloud as a cloud provider.
   ([#1831](https://github.com/open-telemetry/opentelemetry-specification/pull/1831))
 
 ### Compatibility
@@ -2822,7 +2822,7 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 ### Traces
 
 - Add schema_url support to `Tracer`. ([#1666](https://github.com/open-telemetry/opentelemetry-specification/pull/1666))
-- Add Dropped Links Count to non-otlp exporters section ([#1697](https://github.com/open-telemetry/opentelemetry-specification/pull/1697))
+- Add Dropped Links Count to Non-OTLP exporters section ([#1697](https://github.com/open-telemetry/opentelemetry-specification/pull/1697))
 - Add note about reporting dropped counts for attributes, events, links. ([#1699](https://github.com/open-telemetry/opentelemetry-specification/pull/1699))
 
 ### Metrics
@@ -3075,7 +3075,7 @@ New:
   ([#1066](https://github.com/open-telemetry/opentelemetry-specification/pull/1066))
 - Change Status to be consistent with Link and Event
   ([#1067](https://github.com/open-telemetry/opentelemetry-specification/pull/1067))
-- Clarify env variables in otlp exporter
+- Clarify env variables in OTLP exporter
   ([#975](https://github.com/open-telemetry/opentelemetry-specification/pull/975))
 - Add Prometheus exporter environment variables
   ([#1021](https://github.com/open-telemetry/opentelemetry-specification/pull/1021))
@@ -3319,7 +3319,7 @@ Updates:
 - [OTEP-0002](oteps/trace/0002-remove-spandata.md):
   Removed SpanData interface in favor of Span Start and End options.
 - [OTEP-0003](oteps/metrics/0003-measure-metric-type.md)
-  Consolidatesd pre-aggregated and raw metrics APIs.
+  Consolidated pre-aggregated and raw metrics APIs.
 - [OTEP-0008](oteps/metrics/0008-metric-observer.md)
   Added Metrics Observers API.
 - [OTEP-0009](oteps/metrics/0009-metric-handles.md)

CONTRIBUTING.md

@@ -312,7 +312,7 @@ Release Procedure:
    (e.g., in the last released version rather than Unreleased).
 4. Add the changelog entries from `CHANGELOG.md` to the description of the
    [release PR](
-   https://github.com/open-telemetry/opentelemetry-specification/releases) and undraft it.
+   https://github.com/open-telemetry/opentelemetry-specification/releases) and un-draft it.
 5. Once it is approved, confirm the date in the CHANGELOG is up-to-date, and merge it,
    creating a new release tag, e.g. "v1.50.0", containing the CHANGELOG contents.
 

development/trace/zpages.md

@@ -1,3 +1,4 @@
+<!--- cspell:ignorewords configz rpcz statsz tracez --->
 # zPages
 
 ## Table of Contents

oteps/0001-telemetry-without-manual-instrumentation.md

@@ -43,7 +43,7 @@ Without further ado, here are a set of requirements for “official” OpenTelem
   * Note that this also makes it easy to test against multiple different versions of any given library
 * A fully pluggable architecture, where plugins can be registered at runtime without requiring changes to the central repo at github.com/open-telemetry
   * E.g., for ops teams that want to write a plugin for a proprietary piece of legacy software they are unable to recompile
-* Augemntation of whitebox instrumentation by blackbox instrumentation (or, perhaps, vice versa). That is, not only can the trace context be shared by these different flavors of instrumentation, but even things like in-flight Span objects can be shared and co-modified (e.g., to use runtime interposition to grab local variables and attach them to a manually-instrumented span).
+* Augmentation of whitebox instrumentation by blackbox instrumentation (or, perhaps, vice versa). That is, not only can the trace context be shared by these different flavors of instrumentation, but even things like in-flight Span objects can be shared and co-modified (e.g., to use runtime interposition to grab local variables and attach them to a manually-instrumented span).
 
 ## Trade-offs and mitigations
 

oteps/0016-named-tracers.md

@@ -1,6 +1,6 @@
 # Named Tracers and Meters
 
-_Associate Tracers and Meters with the name and version of the instrumentation library which reports telemetry data by parameterizing the API which the library uses to acquire the Tracer or Meter._
+_Associate Tracers and Meters with the name and version of the instrumentation library which reports telemetry data by parameterization of the API which the library uses to acquire the Tracer or Meter._
 
 ## Suggested reading
 
@@ -50,7 +50,7 @@ Meter meter = OpenTelemetry.getMeterProvider().getMeter("io.opentelemetry.contri
 
 These factories (`TracerProvider` and `MeterProvider`) replace the global `Tracer` / `Meter` singleton objects as ubiquitous points to request Tracer and Meter instances.
 
- The _name_ used to create a Tracer or Meter must identify the _instrumentation_ libraries (also referred to as _integrations_) and not the library being instrumented. These instrumentation libraries could be libraries developed in an OpenTelemetry repository, a 3rd party implementation, or even auto-injected code (see [Open Telemetry Without Manual Instrumentation OTEP](https://github.com/open-telemetry/oteps/blob/main/text/0001-telemetry-without-manual-instrumentation.md)). See also the examples for identifiers at the end.
+ The _name_ used to create a Tracer or Meter must identify the _instrumentation_ libraries (also referred to as _integrations_) and not the library being instrumented. These instrumentation libraries could be libraries developed in an OpenTelemetry repository, a 3rd party implementation, or even auto-injected code (see [OpenTelemetry Without Manual Instrumentation OTEP](https://github.com/open-telemetry/oteps/blob/main/text/0001-telemetry-without-manual-instrumentation.md)). See also the examples for identifiers at the end.
 If a library (or application) has instrumentation built-in, it is both the instrumenting and instrumented library and should pass its own name here. In all other cases (and to distinguish them from that case), the distinction between instrumenting and instrumented library is very important. For example, if an HTTP library `com.example.http` is instrumented by either `io.opentelemetry.contrib.examplehttp`, then it is important that the Tracer is not named `com.example.http`, but `io.opentelemetry.contrib.examplehttp` after the actual instrumentation library.
 
 If no name (null or empty string) is specified, following the suggestions in ["error handling proposal"](https://github.com/open-telemetry/opentelemetry-specification/pull/153), a "smart default" will be applied and a default Tracer / Meter implementation is returned.
@@ -68,7 +68,7 @@ Examples (based on existing contribution libraries from OpenTracing and OpenCens
 * `io.opentracing.contrib.asynchttpclient`
 * `io.opencensus.contrib.http.servlet`
 * `io.opencensus.contrib.spring.sleuth.v1x`
-* `io.opencesus.contrib.http.jaxrs`
+* `io.opencensus.contrib.http.jaxrs`
 * `github.com/opentracing-contrib/go-amqp` (Go)
 * `github.com/opentracing-contrib/go-grpc` (Go)
 * `OpenTracing.Contrib.NetCore.AspNetCore` (.NET)

oteps/0035-opentelemetry-protocol.md

@@ -1,3 +1,4 @@
+<!--- cspell:ignore rfcnnnn --->
 # OpenTelemetry Protocol Specification
 
 **Author**: Tigran Najaryan, Omnition Inc.

oteps/0066-separate-context-propagation.md

@@ -96,7 +96,7 @@ When a span is started, a new context is returned, with the new span set as the
 current span.
 
 **`GetSpanPropagator() -> (HTTP_Extractor, HTTP_Injector)`**  
-When a span is extracted, the extracted value is stored in the context seprately
+When a span is extracted, the extracted value is stored in the context separately
 from the current span.
 
 ### Correlations API

oteps/0083-component.md

@@ -50,7 +50,7 @@ Application servers) every Application will have it's own `TracerProvider` and
 
 ## Internal details
 
-This proposal affects only the OpenTelemtry protocol, and proposes a way to
+This proposal affects only the OpenTelemetry protocol, and proposes a way to
 represent the telemetry data in a structured way.
 For example, here is the protobuf definition for metrics:
 metrics:

oteps/0122-otlp-http-json.md

@@ -19,7 +19,7 @@ This is a proposal to add HTTP Transport extension supporting json serialization
 
 ## Motivation
 
-Protobuf is a relatively big dependency, which some clients are not willing to take. For example, webjs, iOS/Android (in some scenarios, the size of the installation package is limited, do not want to introduce protobuf dependencies). Plain JSON is a smaller dependency and is built in the standard libraries of many programming languages.
+Protobuf is a relatively big dependency, which some clients are not willing to take. For example, WebJS, iOS/Android (in some scenarios, the size of the installation package is limited, do not want to introduce protobuf dependencies). Plain JSON is a smaller dependency and is built in the standard libraries of many programming languages.
 
 ## OTLP/HTTP+JSON Protocol Details
 

oteps/0149-exponential-histogram.md

@@ -70,7 +70,7 @@ The followings are restrictions of ExponentialBuckets:
 
 Merging histograms of different types, or even the same type, but with different parameters remains an issue. There are lengthy discussions in [#226](https://github.com/open-telemetry/opentelemetry-proto/pull/226#issuecomment-776526864)
 
-Some merge method may introduce artifacts (information not present in original data). Generally, splitting a bucket introduces artifacts. For example, when using linear interpolation to split a bucket, we are assumming uniform distribution within the bucket. "Uniform distribution" is information not present in original data. Merging buckets on the other hand, does not introduce artifacts. Merging buckets with identical bounds from two histograms is totally artifact free. Merging multiple adjacent buckets in one histogram is also artifact free, but it does reduce the resolution of the histogram. Whether such a merge is "lossy" is arguable. Because of this ambiguity, the term "lossy" is not used in this doc.
+Some merge method may introduce artifacts (information not present in original data). Generally, splitting a bucket introduces artifacts. For example, when using linear interpolation to split a bucket, we are assuming uniform distribution within the bucket. "Uniform distribution" is information not present in original data. Merging buckets on the other hand, does not introduce artifacts. Merging buckets with identical bounds from two histograms is totally artifact free. Merging multiple adjacent buckets in one histogram is also artifact free, but it does reduce the resolution of the histogram. Whether such a merge is "lossy" is arguable. Because of this ambiguity, the term "lossy" is not used in this doc.
 
 For exponential histograms, if base1 = base2 ^ N, where N is an integer, the two histograms can be merged without artifacts. Furthermore, we can introduce a series of bases where
 

oteps/0182-otlp-remote-parent.md

@@ -117,7 +117,7 @@ The first property described by SpanKind reflects whether the Span is a "logical
 
 However, the specification stay ambiguous for the `CONSUMER` span kind with respect to the property of the "logical" remote parent.
 Nevertheless, the proposed field `parent_span_is_remote` has some overlap with that `SpanKind` property.
-The specification would require some clearification on the `SpanKind` and its relation to `parent_span_is_remote`.
+The specification would require some clarification on the `SpanKind` and its relation to `parent_span_is_remote`.
 
 ## Future possibilities