Lint fixes.

Author: carlosalberto

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

@@ -31,7 +31,7 @@ Without further ado, here are a set of requirements for “official” OpenTelem
 * Explicit, whitebox OpenTelemetry instrumentation must interoperate with the “automatic” / zero-source-code-modification / blackbox instrumentation.
   * If the blackbox instrumentation starts a Span, whitebox instrumentation must be able to discover it as the active Span (and vice versa)
   * Relatedly, there also must be a way to discover and avoid potential conflicts/overlap/redundancy between explicit whitebox instrumentation and blackbox instrumentation of the same libraries/packages
-    * That is, if a developer has already added the “official” OpenTelemetry plugin for, say, gRPC, then when the blackbox instrumentation effort adds gRPC support, it should *not* “double-instrument” it and create a mess of extra spans/etc
+    * That is, if a developer has already added the “official” OpenTelemetry plugin for, say, gRPC, then when the blackbox instrumentation effort adds gRPC support, it should _not_ “double-instrument” it and create a mess of extra spans/etc
 * From the standpoint of the actual telemetry being gathered, the same standards and expectations (about tagging, metadata, and so on) apply to "whitebox" instrumentation and automatic instrumentation
 * The code in the OpenTelemetry package must not take a hard dependency on any particular vendor/vendors (that sort of functionality should work via a plugin or registry mechanism)
   * Further, the code in the OpenTelemetry package must be isolated to avoid possible conflicts with the host application (e.g., shading in Java, etc)

oteps/0016-named-tracers.md

@@ -35,9 +35,9 @@ Based on the name and version, a Provider could provide a no-op Tracer or Meter
 
 ## Explanation
 
-From a user perspective, working with *Named Tracers / Meters* and `TracerProvider` / `MeterProvider` is conceptually similar to how e.g. the [Java logging API](https://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)) and logging frameworks like [log4j](https://www.slf4j.org/apidocs/org/slf4j/LoggerFactory.html) work. In analogy to requesting Logger objects through LoggerFactories, an instrumentation library would create specific Tracer / Meter objects through a TracerProvider / MeterProvider.
+From a user perspective, working with _Named Tracers / Meters_ and `TracerProvider` / `MeterProvider` is conceptually similar to how e.g. the [Java logging API](https://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)) and logging frameworks like [log4j](https://www.slf4j.org/apidocs/org/slf4j/LoggerFactory.html) work. In analogy to requesting Logger objects through LoggerFactories, an instrumentation library would create specific Tracer / Meter objects through a TracerProvider / MeterProvider.
 
-New Tracers or Meters can be created by providing the name and version of an instrumentation library. The version (following the convention proposed in <https://github.com/open-telemetry/oteps/pull/38>) is basically optional but *should* be supplied since only this information enables following scenarios:
+New Tracers or Meters can be created by providing the name and version of an instrumentation library. The version (following the convention proposed in <https://github.com/open-telemetry/oteps/pull/38>) is basically optional but _should_ be supplied since only this information enables following scenarios:
 
 * Only a specific range of versions of a given instrumentation library need to be suppressed, while other versions are allowed (e.g. due to a bug in those specific versions).
 * Go modules allow multiple versions of the same middleware in a single build so those need to be determined at runtime.
@@ -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/master/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 [Open Telemetry Without Manual Instrumentation OTEP](https://github.com/open-telemetry/oteps/blob/master/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.
@@ -76,7 +76,7 @@ Examples (based on existing contribution libraries from OpenTracing and OpenCens
 
 ## Internal details
 
-By providing a `TracerProvider` / `MeterProvider` and *Named Tracers / Meters*, a vendor or OpenTelemetry implementation gains more flexibility in providing Tracers and Meters and which attributes they set in the resulting Spans and Metrics that are produced.
+By providing a `TracerProvider` / `MeterProvider` and _Named Tracers / Meters_, a vendor or OpenTelemetry implementation gains more flexibility in providing Tracers and Meters and which attributes they set in the resulting Spans and Metrics that are produced.
 
 On an SDK level, the SpanData class and its Metrics counterpart are extended with a `getLibraryResource` function that returns the resource associated with the Tracer / Meter that created it.
 
@@ -117,7 +117,7 @@ Span span = traceComponent.spanBuilder("someMethod").startSpan();
 
 Overall, this would not change a lot compared to the `TracerProvider` since the levels of indirection until producing an actual span are the same.
 
-Instead of setting the `component` property based on the given Tracer names, those names could also be used as *prefixes* for produced span names (e.g. `<TracerName-SpanName>`). However, with regard to data quality and semantic conventions, a dedicated `component` set on spans is probably preferred.
+Instead of setting the `component` property based on the given Tracer names, those names could also be used as _prefixes_ for produced span names (e.g. `<TracerName-SpanName>`). However, with regard to data quality and semantic conventions, a dedicated `component` set on spans is probably preferred.
 
 Instead of using plain strings as an argument for creating new Tracers, a `Resource` identifying an instrumentation library could be used. Such resources must have a _version_ and a _name_ label (there could be semantic convention definitions for those labels). This implementation alternative mainly depends on the availability of the `Resource` data type on an API level (see <https://github.com/open-telemetry/opentelemetry-specification/pull/254>).
 

oteps/0035-opentelemetry-protocol.md

@@ -45,7 +45,7 @@ OTLP is a general-purpose telemetry data delivery protocol designed in the scope
 
 OTLP defines the encoding of telemetry data and the protocol used to exchange data between the client and the server.
 
-This specification defines how OTLP is implemented over [gRPC](https://grpc.io/) and specifies corresponding [Protocol Buffers](https://developers.google.com/protocol-buffers/docs/overview) schema. Future extensions to OTLP may define implementations over other transports. For details of gRPC service definition see section [gRPC Transport](#grpc-transport).
+This specification defines how OTLP is implemented over [gRPC](https://grpc.io/) and specifies corresponding [Protocol Buffers](https://developers.google.com/protocol-buffers/docs/overview) schema. Future extensions to OTLP may define implementations over other transports. For details of gRPC service definition see section [gRPC Transport](#grpc-service-definition).
 
 OTLP is a request/response style protocols: the clients send requests, the server replies with corresponding responses. This document defines one requests and response type: `Export`.
 

oteps/0066-separate-context-propagation.md

@@ -1,24 +1,24 @@
 # Context Propagation: A Layered Approach
 
-* [Motivation](#Motivation)
-* [OpenTelemetry layered architecture](#OpenTelemetry-layered-architecture)
-  * [Cross-Cutting Concerns](#Cross-Cutting-Concerns)
-    * [Observability API](#Observability-API)
-    * [Correlations API](#Correlations-API)
-  * [Context Propagation](#Context-Propagation)
-    * [Context API](#Context-API)
-    * [Propagation API](#Propagation-API)
-* [Prototypes](#Prototypes)
-* [Examples](#Examples)
-  * [Global initialization](#Global-initialization)
-  * [Extracting and injecting from HTTP headers](#Extracting-and-injecting-from-HTTP-headers)
-  * [Simplify the API with automated context propagation](#Simplify-the-API-with-automated-context-propagation)
-  * [Implementing a propagator](#Implementing-a-propagator)
-  * [Implementing a concern](#Implementing-a-concern)
-  * [The scope of current context](#The-scope-of-current-context)
-  * [Referencing multiple contexts](#Referencing-multiple-contexts)
-  * [Falling back to explicit contexts](#Falling-back-to-explicit-contexts)
-* [Internal details](#Internal-details)
+* [Motivation](#motivation)
+* [OpenTelemetry layered architecture](#opentelemetry-layered-architecture)
+  * [Cross-Cutting Concerns](#cross-cutting-concerns)
+    * [Observability API](#observability-api)
+    * [Correlations API](#correlations-api)
+  * [Context Propagation](#context-propagation)
+    * [Context API](#context-api)
+    * [Propagation API](#propagation-api)
+* [Prototypes](#prototypes)
+* [Examples](#examples)
+  * [Global initialization](#global-initialization)
+  * [Extracting and injecting from HTTP headers](#extracting-and-injecting-from-http-headers)
+  * [Simplify the API with automated context propagation](#simplify-the-api-with-automated-context-propagation)
+  * [Implementing a propagator](#implementing-a-propagator)
+  * [Implementing a concern](#implementing-a-concern)
+  * [The scope of current context](#the-scope-of-current-context)
+  * [Referencing multiple contexts](#referencing-multiple-contexts)
+  * [Falling back to explicit contexts](#falling-back-to-explicit-contexts)
+* [Internal details](#internal-details)
 * [FAQ](#faq)
 
 ![drawing](img/0066_context_propagation_overview.png)
@@ -109,7 +109,7 @@ causal relationship between these events. For example, determining that a
 particular browser version is associated with a failure in an image processing
 service.
 
-The Correlations API is based on the [W3C Correlation-Context specification](https://w3c.github.io/correlation-context/),
+The Correlations API is based on the [W3C Baggage specification](https://www.w3.org/TR/baggage/),
 and implements the protocol as it is defined in that working group. There are
 few details provided here as it is outside the scope of this OTEP to finalize
 this API.
@@ -581,7 +581,7 @@ Their properties and requirements are integrated into the OpenTelemetry APIs.
 and `tracestate` headers defined in the [W3C Trace Context specification](https://www.w3.org/TR/trace-context/).
 
 **Correlation Context -** The OpenTelemetry Correlations API is modeled on the
-`Correlation-Context` headers defined in the [W3C Correlation Context specification](https://w3c.github.io/correlation-context/).
+`Baggage` headers defined in the [W3C Baggage specification](https://www.w3.org/TR/baggage/).
 
 ### Context management and in-process propagation
 
@@ -626,7 +626,7 @@ Prior art:
 
 ## Risks
 
-The Correlations API is related to the [W3C Correlation-Context](https://w3c.github.io/correlation-context/)
+The Correlations API is related to the [W3C Baggage](https://www.w3.org/TR/baggage/)
 specification. Work on this specification has begun, but is not complete. While
 unlikely, it is possible that this W3C specification could diverge from the
 design or guarantees needed by the Correlations API.

oteps/0111-auto-resource-detection.md

@@ -157,7 +157,7 @@ specification](https://github.com/census-instrumentation/opencensus-specs/blob/m
   resource detection code is currently in the JS resource package, so this would
   need to be separated.
 - Environment variable resource detection in Java SDK
-  [here](https://github.com/open-telemetry/opentelemetry-java/blob/master/sdk/src/main/java/io/opentelemetry/sdk/resources/EnvVarResource.java):
+  [here](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/ResourceConfiguration.java):
   This implementation does not currently include a detector interface, but is
   used by default for tracer and meter providers
 

oteps/0119-standard-system-metrics.md

@@ -28,7 +28,7 @@ There are already a few implementations of system and/or runtime metric collecti
   * This package does not export metrics with labels, instead exporting individual metrics.
   * [Overview of collected metrics](https://docs.google.com/spreadsheets/d/1r50cC9ass0A8SZIg2ZpLdvZf6HmQJsUSXFOu-rl4yaY/edit#gid=0).
 - **Python**
-  * Python [has instrumentation](https://github.com/open-telemetry/opentelemetry-python/tree/master/ext/opentelemetry-ext-system-metrics) to collect some system and runtime metrics.
+  * Python [has instrumentation](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-system-metrics) to collect some system and runtime metrics.
   * Collects system CPU, memory, and network metrics.
   * Collects runtime CPU, memory, and GC metrics.
   * Makes use of labels, similar to the Collector.

oteps/0152-telemetry-schemas.md

@@ -25,14 +25,14 @@
   * [Schema File Format Number](#schema-file-format-number)
 * [OTLP Changes](#otlp-changes)
 * [API and SDK Changes](#api-and-sdk-changes)
-* [OpenTelemetry Schema 1.0.0](#opentelemetry-schema-100)
+* [OpenTelemetry Schema](#opentelemetry-schema)
 * [Performance Impact](#performance-impact)
 * [Open Questions](#open-questions)
 * [Future Possibilities](#future-possibilities)
   * [Parent Schema](#parent-schema)
-  * [Collector Processor](#collector-processor)
   * [Current State in Schema](#current-state-in-schema)
   * [Other Transformation Types](#other-transformation-types)
+  * [Version Convertability](#version-convertability)
 * [Alternates Considered](#alternates-considered)
   * [Name Aliases](#name-aliases)
   * [Schema Negotiation](#schema-negotiation)
@@ -723,8 +723,8 @@ contained Metric messages.
 The schema_url field in the InstrumentationLibraryLogs message applies to the
 contained LogRecord messages.
 
-If schema_url field is non-empty both in Resource* message and in the contained
-InstrumentationLibrary* message then the value in InstrumentationLibrary*
+If schema_url field is non-empty both in Resource message and in the contained
+InstrumentationLibrary message then the value in InstrumentationLibrary
 message takes the precedence.
 
 ## API and SDK Changes
@@ -816,9 +816,6 @@ Since 1.2.0 is the first published version of OpenTelemetry schema there are no
 "changes" section and we omitted all previous versions from the file since there
 is nothing to record for earlier versions.
 
-This file SHOULD be available for retrieval at
-[https://opentelemetry.io/schemas/1.2.0](https://opentelemetry.io/schemas/1.2.0)
-
 All OpenTelemetry instrumentation solutions will follow this schema.
 
 ## Performance Impact

oteps/0156-columnar-encoding.md

@@ -624,7 +624,7 @@ Specifically:
 
 When Arrow is enabled, the OTelArrow receiver listens for both the standard unary gRPC service OTLP and OTel Arrow stream
 services.  Each stream uses an instance of the OTel-Arrow-Adapter's
-[Consumer](https://pkg.go.dev/github.com/f5/otel-arrow-adapter@v0.0.0-20230112224802-dafb6df21c97/pkg/otel/arrow_record#Consumer). Sets
+[Consumer](https://pkg.go.dev/github.com/f5/otel-arrow-adapter/pkg/otel/arrow_record#Consumer). Sets
 `client.Metadata` in the Context.
 
 #### OTelArrow/gRPC Exporter
@@ -637,7 +637,7 @@ restarting, while honoring the caller's context deadline, to avoid delays introd
 through the `exporterhelper` mechanism.
 
 Each stream uses an instance of the OTel-Arrow-Adapter's
-[Producer](https://pkg.go.dev/github.com/f5/otel-arrow-adapter@v0.0.0-20230112224802-dafb6df21c97/pkg/otel/arrow_record#Producer).
+[Producer](https://pkg.go.dev/github.com/f5/otel-arrow-adapter/pkg/otel/arrow_record#Producer).
 
 When a stream fails specifically because the server does not recognize the Arrow service, it will not restart.  When all
 streams have failed in this manner, the connection downgrades by closing a channel, at which point the exporter behaves

oteps/0182-otlp-remote-parent.md

@@ -54,7 +54,7 @@ A span can be considered an entry-point span if it has no parent (`parent_span_i
 The first part would be to update the trace protobuf, adding a `boolean parent_span_is_remote` field to the
 [`Span` message](https://github.com/open-telemetry/opentelemetry-proto/blob/b43e9b18b76abf3ee040164b55b9c355217151f3/opentelemetry/proto/trace/v1/trace.proto#L84).
 
-[`SpanContext.IsRemote`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#isremote) identifies whether span context has been propagated from a remote parent.
+[`SpanContext.IsRemote`](../specification/trace/api.md#isremote) identifies whether span context has been propagated from a remote parent.
 The OTLP exporter in each SDK would need to be updated to record this in the new `parent_span_is_remote` field.
 
 For backwards compatibility with older OTLP versions, the protobuf field should be `nullable` (`true`, `false`, or unspecified)