Ensure component term is used properly (open-telemetry#144)

In many places, the term component was used in place of GDI repository.

README.md

@@ -25,7 +25,7 @@ reading by GDI repository consumers.
 
 ## Terms
 
-- Component: Specific feature-set of a GDI repository.
+- Component: Specific subset of a GDI repository.
 - Data Collector: A way to collect telemetry data within an environment.
   Refers to `splunk-otel-collector` repository.
 - GDI: Getting Data In

specification/configuration.md

@@ -172,7 +172,7 @@ Other requirements:
 
 #### Serverless 
 
-By default, serverless components MUST send data directly to Splunk Observability Cloud (direct ingest). 
+By default, serverless instrumentation libraries MUST send data directly to Splunk Observability Cloud (direct ingest). 
 
 Apart from standard set of configuration properties for instrumentation libraries based on OpenTelemetry, serverless MUST honour the following:  
 
@@ -191,7 +191,7 @@ Apart from standard set of configuration properties for instrumentation librarie
 
     If relevant traces exporter endpoint property (eg `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` for `otlp`) or `SPLUNK_METRICS_ENDPOINT` is set, it takes precedence over the `SPLUNK_REALM` setting.
 
-As there is no deployment phase in case of Serverless functions, if a required configuration property is missing, the serverless component MUST log an error but MUST still execute.
+As there is no deployment phase in case of Serverless functions, if a required configuration property is missing, the serverless instrumentation library MUST log an error but MUST still execute.
 
 ## Environment variable alternatives
 

specification/profiling.md

@@ -67,7 +67,7 @@ default (`https://localhost:4317`).
 The instrumentation library must allow the destination for profiling logs to be overridden with 
 the environment variable `SPLUNK_PROFILER_LOGS_ENDPOINT`.
 
-Instrumentation libraries SHOULD reuse persistent gRPC/OTLP connections from other components (traces, metrics).
+Instrumentation libraries SHOULD reuse persistent gRPC/OTLP connections from other signals (traces, metrics).
 
 ## ResourceLogs
 
@@ -159,4 +159,4 @@ after the `lineno`, separated by a space.
 
 # References
 
-* [Otel Logs -> HEC mapping example](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#splunk-hec)
+* [Otel Logs -> HEC mapping example](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#splunk-hec)

specification/repository.md

@@ -128,7 +128,7 @@ approval is granted, GDI repositories MUST NOT cut a GA release.
 - MUST have a signature or a checksum with signature for all release artifacts
   - SHOULD use Splunk signing key
 - MUST use [signed tags](https://docs.github.com/en/github/authenticating-to-github/signing-tags)
-- MUST state version of OpenTelemetry components built against if applicable
+- MUST state version of OpenTelemetry repository built against if applicable
 - MUST update all examples in the [Splunk OpenTelemetry example
   repository](https://github.com/signalfx/tracing-examples/tree/main/opentelemetry-tracing)
   that depends on the repository to use the latest release.

specification/versioning.md

@@ -2,11 +2,11 @@
 
 **Status**: [Stable](../README.md#versioning-and-status-of-the-specification)
 
-All GDI components MUST be versioned according to [Semantic Versioning
-2.0](https://semver.org/spec/v2.0.0.html). GDI components are versioned
-separately from OpenTelemetry components as Splunk-specific breaking changes
-MAY be introduced. GDI components MUST indicate what version of OpenTelemetry
-components they are based on through release notes and SHOULD indicate through
+All GDI repositories MUST be versioned according to [Semantic Versioning
+2.0](https://semver.org/spec/v2.0.0.html). GDI repositories are versioned
+separately from OpenTelemetry repositories as Splunk-specific breaking changes
+MAY be introduced. GDI repositories MUST indicate what version of OpenTelemetry
+repositories they are based on through release notes and SHOULD indicate through
 logging. Additional version number constraints can be found in the sections
 below.
 
@@ -41,16 +41,16 @@ configuration variable to enable, and MUST clearly be marked as experimental.
 
 ## Stable
 
-The initial stable release version number for GDI components MUST be `1.0.0` and
+The initial stable release version number for GDI repositories MUST be `1.0.0` and
 follow Semantic Versioning 2.0 for all subsequent releases. Once an
 experimental component has gone through rigorous beta testing, it MAY
 transition to stable. Long-term dependencies MAY now be taken against this
 component. When a new stable component is introduced to a GDI repository with an
 existing stable release, the `MINOR` version number MUST be incremented and the
 component MUST clearly be marked as stable.
 
-All components MAY become stable together, or MAY transition to
-stability component-by-component.
+All components within a GDI repository MAY become stable together, or MAY
+transition to stability component-by-component.
 
 Once a component is marked as stable, the following rules MUST apply
 until the end of that component’s existence.