Update OTel specification, drop workarounds, fix links

.htmltest.yml

@@ -9,10 +9,6 @@ IgnoreURLs: # list of regexs of paths or URLs to be ignored
   - ^/docs/instrumentation/net/(metrics-api|traces-api)/
   - ^/community/end-user/feedback-survey/$
   - ^(/docs/migration/)?opencensus/$
-  # TODO: drop the following rules after OTel spec rework is complete
-  # re. https://github.com/open-telemetry/opentelemetry.io/issues/2698
-  - ^/docs/reference/specification
-  - ^/docs/specification
 
   - ^https://deploy-preview-\d+--opentelemetry.netlify.app/
   - ^https://www\.googletagmanager\.com

content/en/docs/demo/services/frontend.md

@@ -17,7 +17,7 @@ libraries to leverage, or make use of the `getNodeAutoInstrumentations()`
 function which includes most popular frameworks. The
 `utils/telemetry/Instrumentation.js` file contains all code required to
 initialize the SDK and auto-instrumentation based on standard
-[OpenTelemetry environment variables](/docs/specs/otel/sdk-environment-variables/)
+[OpenTelemetry environment variables](/docs/specs/otel/configuration/sdk-environment-variables/)
 for OTLP export, resource attributes, and service name.
 
 ```javascript

content/en/docs/demo/services/load-generator.md

@@ -18,7 +18,7 @@ Since this service is a
 OpenTelemetry SDK is initialized after the import statements. This code will
 create a tracer provider, and establish a Span Processor to use. Export
 endpoints, resource attributes, and service name are automatically set using
-[OpenTelemetry environment variables](/docs/specs/otel/sdk-environment-variables/).
+[OpenTelemetry environment variables](/docs/specs/otel/configuration/sdk-environment-variables/).
 
 ```python
 tracer_provider = TracerProvider()

content/en/docs/instrumentation/erlang/getting-started/_index.md

@@ -388,8 +388,9 @@ and the [Zipkin protocol](https://hex.pm/packages/opentelemetry_zipkin).
 
 Configuration is done through the
 [Application environment](https://erlang.org/doc/design_principles/applications.html#configuring-an-application)
-or [OS Environment Variables](/docs/specs/otel/sdk-environment-variables/). The
-SDK (`opentelemetry` Application) uses the configuration to initialize a
+or
+[OS Environment Variables](/docs/specs/otel/configuration/sdk-environment-variables/).
+The SDK (`opentelemetry` Application) uses the configuration to initialize a
 [Tracer Provider](https://hexdocs.pm/opentelemetry/otel_tracer_server.html), its
 [Span Processors](https://hexdocs.pm/opentelemetry/otel_span_processor.html) and
 the [Exporter](https://hexdocs.pm/opentelemetry/otel_exporter.html).

content/en/docs/instrumentation/js/automatic/module-config.md

@@ -5,7 +5,7 @@ weight: 45
 ---
 
 This module is highly configurable by setting
-[environment variables](/docs/reference/specification/sdk-environment-variables/).
+[environment variables](/docs/specs/otel/configuration/sdk-environment-variables/).
 Many aspects of the auto instrumentation's behavior can be configured for your
 needs, such as resource detectors, exporters, trace context propagation headers,
 and more.

content/en/docs/instrumentation/php/exporters.md

@@ -1,7 +1,7 @@
 ---
 title: Exporters
 weight: 5
-spelling: cSpell:ignore openzipkin ndjson fastcgi
+spelling: cSpell:ignore fastcgi jaegertracing openzipkin ndjson zipkin
 ---
 
 In order to visualize and analyze your telemetry, you will need to export it to
@@ -131,7 +131,7 @@ $tracer = $tracerProvider->getTracer('io.opentelemetry.contrib.php');
 ## Minimizing export delays
 
 Most PHP runtimes are synchronous and blocking. Sending telemetry data
-[can delay](/docs/reference/specification/performance/#shutdown-and-explicit-flushing-could-block)
+[can delay](/docs/specs/otel/performance/#shutdown-and-explicit-flushing-could-block)
 HTTP responses being received by your users.
 
 If you are using `fastcgi`, you could issue a call to `fastcgi_finish_request()`
@@ -140,6 +140,6 @@ will not hold up request processing.
 
 To minimize the impact of slow transport of telemetry data, particularly for
 external or cloud-based backends, you should consider using a local
-[OpenTelemetry Collector](/docs/collector). A local collector can quickly
+[OpenTelemetry Collector](/docs/collector/). A local collector can quickly
 accept, then batch and send all of your telemetry to the backend. Such a setup
 will make your system more robust and scalable.

content/en/docs/instrumentation/python/automatic/agent-config.md

@@ -8,7 +8,8 @@ spelling: cSpell:ignore distro mkdir myapp uninstrumented virtualenv
 The agent is highly configurable, either by:
 
 - Passing configuration properties from the CLI
-- Setting [environment variables](/docs/specs/otel/sdk-environment-variables/)
+- Setting
+  [environment variables](/docs/specs/otel/configuration/sdk-environment-variables/)
 
 ## Configuration properties
 

scripts/content-modules/adjust-pages.pl

@@ -27,9 +27,6 @@ ()
   print "---\n";
   if ($title eq 'OpenTelemetry Specification') {
     $title .= " $otelSpecVers";
-    # start:temporary adjustment to front matter until spec is updated:
-    $frontMatterFromFile =~ s/linkTitle: .*/linkTitle: OTel spec/;
-    # end:temporary adjustment
     $frontMatterFromFile =~ s/linkTitle: .*/$& $otelSpecVers/;
   } elsif ( $title eq 'OpenTelemetry Protocol' ) {
     # $frontMatterFromFile = "linkTitle: OTLP\n";
@@ -38,8 +35,6 @@ ()
   print "title: $titleMaybeQuoted\n";
   ($linkTitle) = $title =~ /^OpenTelemetry (.*)/;
   print "linkTitle: $linkTitle\n" if $linkTitle and $frontMatterFromFile !~ /linkTitle: /;
-  # Temporary adjustment until OTel spec is updated: https://github.com/open-telemetry/opentelemetry.io/issues/2704
-  $frontMatterFromFile =~ s|(path_base_for_github_subdir: content/en/docs)/reference/specification/|$1/specs/otel/|;
   print "$frontMatterFromFile" if $frontMatterFromFile;
   if ($ARGV =~ /otel\/specification\/(.*?)_index.md$/) {
     print "path_base_for_github_subdir:\n";