More lint.

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)
@@ -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)

oteps/0199-support-elastic-common-schema-in-opentelemetry.md

@@ -44,7 +44,7 @@ In addition to the use case of structured logs, the maturity of ECS for SIEM (Se
 
 Another significant use case is providing first-class support for Kubernetes application logs, system logs, and application introspection events. We would also like to see support for structured events (e.g. [k8seventsreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver)) and using 'content-type' to identify event types.
 
-We'd like to see different categories of structured logs being well-supported in the [OTel Log Data Model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md), presumably through [semantic conventions for log attributes](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-attributes). For example, NGINX access logs and Apache access logs should be processed the same way as structured logs. This would help in trace and metric correlation with such log data as well as it would help grow the ecosystem of curated UIs provided by observability backends and monitoring dashboards (e.g. one single HTTP access log dashboard benefiting Apache httpd, Nginx, and HAProxy).
+We'd like to see different categories of structured logs being well-supported in the [OTel Log Data Model](../specification/logs/data-model.md), presumably through [semantic conventions for log attributes](../specification/logs/data-model.md#field-attributes). For example, NGINX access logs and Apache access logs should be processed the same way as structured logs. This would help in trace and metric correlation with such log data as well as it would help grow the ecosystem of curated UIs provided by observability backends and monitoring dashboards (e.g. one single HTTP access log dashboard benefiting Apache httpd, Nginx, and HAProxy).
 
 ## Customer Motivation
 
@@ -147,7 +147,7 @@ Example of a Nginx Access Log entry structured with ECS
 
 ## Principles
 
-| Description | [OTel Logs and Event Record](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) | [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html) |
+| Description | [OTel Logs and Event Record](../specification/logs/data-model.md#log-and-event-record-definition) | [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html) |
 |-------------|-------------|--------|
 | Metadata shared by all the Log Messages / Spans / Metrics of an application instance | Resource Attributes | ECS fields |
 | Metadata specific to each Log Message / Span / Metric data point | Attributes | ECS Fields |
@@ -158,7 +158,7 @@ Example of a Nginx Access Log entry structured with ECS
 
 ## Data Types
 
-| Category | <a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a> (all or a subset of <a href="https://developers.google.com/protocol-buffers/docs/proto3">GRPC data types</a>) | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-types.html">ECS Data Types</a> |
+| Category | <a href="../specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a> (all or a subset of <a href="https://developers.google.com/protocol-buffers/docs/proto3">GRPC data types</a>) | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-types.html">ECS Data Types</a> |
 |---|---|---|
 | Text | string | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/text.html#text-field-type">text</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/text.html#match-only-text-field-type">match_only_text</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#keyword-field-type">keyword</a> <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#constant-keyword-field-type">constant_keyword</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#wildcard-field-type">wildcard</a> |
 | Dates | uint64 nanoseconds since Unix epoch | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/date.html">date</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/date_nanos.html">date_nanos</a> |
@@ -177,23 +177,23 @@ As the markdown code of the tables is hard to read and maintain with very long l
 
 <table>
   <tr>
-   <td><strong><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a></strong>
+   <td><strong><a href="../specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a></strong>
    </td>
    <td><strong><a href="https://www.elastic.co/guide/en/ecs/current/ecs-reference.html">Elastic Common Schema (ECS)</a></strong>
    </td>
    <td><strong>Description</strong>
    </td>
   </tr>
   <tr>
-   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">Timestamp</a> (uint64 nanoseconds since Unix epoch)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">Timestamp</a> (uint64 nanoseconds since Unix epoch)
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-timestamp">@timestamp</a> (date)
    </td>
    <td>
    </td>
   </tr>
   <tr>
-   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">TraceId</a> (byte sequence), <a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SpanId</a> (byte sequence)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">TraceId</a> (byte sequence), <a href="../specification/logs/data-model.md#log-and-event-record-definition">SpanId</a> (byte sequence)
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-trace-id">trace.id</a> (keyword), <a href="https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-trace-id">span.id</a> (keyword)
    </td>
@@ -209,23 +209,23 @@ As the markdown code of the tables is hard to read and maintain with very long l
    </td>
   </tr>
   <tr>
-   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SeverityText</a> (string)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">SeverityText</a> (string)
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-syslog-severity-name">log.syslog.severity.name</a> (keyword), <a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-level">log.level</a> (keyword)
    </td>
    <td>
    </td>
   </tr>
   <tr>
-   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SeverityNumber</a> (number)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">SeverityNumber</a> (number)
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-syslog-severity-code">log.syslog.severity.code</a>
    </td>
    <td>
    </td>
   </tr>
   <tr>
-   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">Body</a> (any)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">Body</a> (any)
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-message">message</a> (match_only_text)
    </td>
@@ -235,9 +235,9 @@ As the markdown code of the tables is hard to read and maintain with very long l
   <tr>
    <td>process.cpu.load (not specified but collected by OTel Collector)
 <br/>
-<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/process-metrics.md">process.cpu.time</a> (async counter)
+<a href="https://github.com/open-telemetry/semantic-conventions/blob/main/docs/system/process-metrics.md">process.cpu.time</a> (async counter)
 <br/>
-<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/system-metrics.md">system.cpu.utilization</a>
+<a href="https://github.com/open-telemetry/semantic-conventions/blob/main/docs/system/system-metrics.md">system.cpu.utilization</a>
    </td>
    <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-host.html#field-host-cpu-usage">host.cpu.usage</a> (scaled_float) with a slightly different measurement than what OTel metrics measure
    </td>
@@ -290,5 +290,5 @@ Some areas that need to be addressed in the long run as ECS is integrated into O
 ensuring the OTel specification incorporates the changes to accommodate ECS, and a process for handling breaking changes if any (the proposal
 [Define semantic conventions and instrumentation stability #2180](https://github.com/open-telemetry/opentelemetry-specification/pull/2180)
 should tackle this point). Also, migration of existing naming (e.g. Prometheus exporter) to standardized convention (see
-[Semantic Conventions for System Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/system-metrics.md) ,
-[Semantic Conventions for OS Process Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/process-metrics.md)).
+[Semantic Conventions for System Metrics](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/system/system-metrics.md) ,
+[Semantic Conventions for OS Process Metrics](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/system/process-metrics.md)).

oteps/0202-events-and-logs-api.md

@@ -20,7 +20,7 @@ Here are a few situations that require recording of Events, there will be more.
   - Standalone events that occur when there is no span in progress, such as errors, user interaction events and web vitals.
 - Recording kubernetes events
 - Collector Entity events [link](https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/edit)
-- Few other event systems described in [example mappings](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#appendix-a-example-mappings) in the data model.
+- Few other event systems described in [example mappings](../specification/logs/data-model.md#appendix-a-example-mappings) in the data model.
 
 ### Can the current Log API interfaces be used for events?
 
@@ -46,7 +46,7 @@ All Events will have a name and a domain. The name is MANDATORY. The domain will
 
 ### Events and Logs API
 
-We also propose having an API interface for creating Events and Logs. Currently, there is only an SDK called [LogEmitterProvider](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/logging-library-sdk.md#logemitterprovider) for creating `LogRecord`s.
+We also propose having an API interface for creating Events and Logs. Currently, there is only an SDK called [LoggerProvider](../specification/logs/sdk.md#loggerprovider) for creating `LogRecord`s.
 
 However, there is a question of whether OTel should have an API for logs. A part of the OTel community thinks that we should not have a full-fledged logging API unless there is a language that doesn't already have a plethora of logging libraries and APIs to choose from where it might make sense to define one. Further, we will not be able to have the [rich set of configuration options](https://logging.apache.org/log4j/2.x/manual/configuration.html) that some popular logging frameworks provide so the logging API in OTel will only become yet another API. However, it was noted that the Log Appender API is very similar to the API for Events and so instead of having API for Events and API for Log Appenders separately it was agreed to have one API for Events and Logs, and that the API for Logs is targeted only to Log Appenders. This will also keep it consistent with Traces and Metrics in having one API for each signal.
 

oteps/0225-configuration.md

@@ -119,7 +119,7 @@ Create a `Configurer` from a [configuration model](#configuration-model).
 
 #### Get TracerProvider, MeterProvider, LoggerProvider
 
-Interpret the [configuration model](#configuration-model) and return SDK TracerProvider, MeterProvider, LoggerProvider which strictly reflect the configuration object's details and ignores the [opentelemetry environment variable configuration scheme](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md).
+Interpret the [configuration model](#configuration-model) and return SDK TracerProvider, MeterProvider, LoggerProvider which strictly reflect the configuration object's details and ignores the [opentelemetry environment variable configuration scheme](../specification/configuration/sdk-environment-variables.md).
 
 ### Configuration model