Move specifications into sub-directories per signal

Signed-off-by: Bogdan Drutu <[email protected]>

Author: bogdandrutu

README.md

@@ -14,19 +14,19 @@ The OpenTelemetry specification describes the cross-language requirements and ex
   - [Package/Library Layout](specification/library-layout.md)
   - [Concurrency and Thread-Safety](specification/concurrency.md)
 - API Specification
-  - [CorrelationContext](specification/api-correlationcontext.md)
-    - [Propagators](specification/api-propagators.md)
-  - [Tracing](specification/api-tracing.md)
-  - [Metrics](specification/api-metrics.md)
-    - [User-Facing API](specification/api-metrics-user.md)
-    - [Meter API](specification/api-metrics-meter.md)
+  - [CorrelationContext](specification/correlationcontext/api.md)
+    - [Propagators](specification/context/api-propagators.md)
+  - [Tracing](specification/trace/api.md)
+  - [Metrics](specification/metrics/api.md)
+    - [User-Facing API](specification/metrics/api-user.md)
+    - [Meter API](specification/metrics/api-meter.md)
 - SDK Specification
-  - [Tracing](specification/sdk-tracing.md)
-  - [Resource](specification/sdk-resource.md)
+  - [Tracing](specification/trace/sdk.md)
+  - [Resource](specification/resource/sdk.md)
   - [Configuration](specification/sdk-configuration.md)
 - Data Specification
-  - [Semantic Conventions](specification/data-semantic-conventions.md)
-  - [Protocol](specification/protocol.md)
+  - [Semantic Conventions](specification/overview.md#semantic-conventions.md)
+  - [Protocol](specification/protocol/README.md)
 - About the Project
   - [Timeline](#project-timeline)
   - [Notation Conventions and Compliance](#notation-conventions-and-compliance)

specification/img/library-design.png renamed to internal/img/library-design.png

@@ -27,7 +27,7 @@ Parity can be defined as the following features:
 - An SDK implementing OpenTelemetry specification.
 - Backwards compatibility with OpenTracing and OpenCensus via bridges.
 - Metadata helpers or other means for recording common operations defined in the
-  OpenTelemetry [semantic conventions](specification/data-semantic-conventions.md).
+  OpenTelemetry [semantic conventions](specification/overview.md#semantic-conventions.md).
 - Tests which provide evidence of interoperability.
 - Benchmarks which provide evidence of expected resource utilization.
 - Documentation and getting started guide.

specification/img/library-full.png renamed to internal/img/library-full.png

@@ -8,7 +8,7 @@ specification.
 Denotes the library that implements the *OpenTelemetry API*.
 
 See [Library Guidelines](library-guidelines.md#sdk-implementation) and
-[Library resource semantic conventions](data-resource-semantic-conventions.md#telemetry-sdk)
+[Library resource semantic conventions](resource/semantic_conventions/README.md#telemetry-sdk)
 
 <a name="instrumented_library"></a>
 
@@ -38,11 +38,11 @@ Synonyms: *Instrumentation Library*, *Integration*.
 ## Tracer Name / Meter Name
 
 This refers to the `name` and (optional) `version` arguments specified when
-creating a new `Tracer` or `Meter` (see [Obtaining a Tracer](api-tracing.md#obtaining-a-tracer)/[Obtaining a Meter](api-metrics-user.md#obtaining-a-meter)). It identifies the [Instrumenting Library](#instrumenting_library).
+creating a new `Tracer` or `Meter` (see [Obtaining a Tracer](trace/api.md#obtaining-a-tracer)/[Obtaining a Meter](metrics/api-user.md#obtaining-a-meter)). It identifies the [Instrumenting Library](#instrumenting_library).
 
 ## Namespace
 
-This term applies to [Metric names](api-metrics-user.md#metric-names) only. The namespace is used to disambiguate identical metric
+This term applies to [Metric names](metrics/api-user.md#metric-names) only. The namespace is used to disambiguate identical metric
 names used in different [instrumenting libraries](#instrumenting_library). The [Name](#name) provided
 for creating a `Meter` serves as its namespace in addition to the primary semantics
 described [here](#name).

specification/img/library-minimal.png renamed to internal/img/library-minimal.png

@@ -35,7 +35,7 @@ _Note to Language Library Authors:_ OpenTelemetry specification, API and SDK imp
 
 Here is a generic design for a language library (arrows indicate calls):
 
-![Language Library Design Diagram](img/library-design.png)
+![Language Library Design Diagram](../internal/img/library-design.png)
 
 ### Expected Usage
 
@@ -55,7 +55,7 @@ This self-sufficiency is achieved the following way.
 
 The API dependency contains a minimal implementation of the API. When no other implementation is explicitly included in the application no telemetry data will be collected. Here is what active components look like in this case:
 
-![Minimal Operation Diagram](img/library-minimal.png)
+![Minimal Operation Diagram](../internal/img/library-minimal.png)
 
 It is important that values returned from this minimal implementation of API are valid and do not require the caller to perform extra checks (e.g. createSpan() method should not fail and should return a valid non-null Span object). The caller should not need to know and worry about the fact that minimal implementation is in effect. This minimizes the boilerplate and error handling in the instrumented code.
 
@@ -67,17 +67,17 @@ SDK implementation is a separate (optional) dependency. When it is plugged in it
 
 SDK implements core functionality that is required for translating API calls into telemetry data that is ready for exporting. Here is how OpenTelemetry components look like when SDK is enabled:
 
-![Full Operation Diagram](img/library-full.png)
+![Full Operation Diagram](../internal/img/library-full.png)
 
-SDK defines an [Exporter interface](sdk-tracing.md#span-exporter). Protocol-specific exporters that are responsible for sending telemetry data to backends must implement this interface.
+SDK defines an [Exporter interface](trace/sdk.md#span-exporter). Protocol-specific exporters that are responsible for sending telemetry data to backends must implement this interface.
 
 SDK also includes optional helper exporters that can be composed for additional functionality if needed.
 
-Library designers need to define the language-specific `Exporter` interface based on [this generic specification](sdk-tracing.md#span-exporter).
+Library designers need to define the language-specific `Exporter` interface based on [this generic specification](trace/sdk.md#span-exporter).
 
 #### Protocol Exporters
 
-Telemetry backend vendors are expected to implement [Exporter interface](sdk-tracing.md#span-exporter). Data received via Export() function should be serialized and sent to the backend in a vendor-specific way.
+Telemetry backend vendors are expected to implement [Exporter interface](trace/sdk.md#span-exporter). Data received via Export() function should be serialized and sent to the backend in a vendor-specific way.
 
 Vendors are encouraged to keep protocol-specific exporters as simple as possible and achieve desirable additional functionality such as queuing and retrying using helpers provided by SDK.