Fixing misspell issues

text/187-data-classification.md → text/0187-data-classification.md

@@ -7,7 +7,7 @@ Adding optional classification to the attributes and resources to support simpli
 
 As the scope of Observability changes to include user monitoring and analytics (Real User Monitoring for now), ensuring that data is handled correctly is becoming more problematic as the problem space changes to include more. The need for pre processing data in order that high cardinality, sensitive user data, and handling sparse data impacts the reliability and usability of the data. Furthermore, some vendors are not able to selectively remove sensitive user data or some agreements with customers mandate that sensitive data not to leave the internal edge. Moreover, attribute values that are known high cardinality (for example a container id within a cloud based environment) that are expensive to store within observability systems, making it easier to omit attributes as part of exporter or collector configuration can greatly reduce cost of the observability suite.; not all attributes and resource data hold the same value or have the same processing requirements.
 
-Updating the SDK to include the convention of data classification would mean that users can extend their current telemetry via an opt in process to enable enhanced controls over the telemetry data without impacting the developer experience. Instrumentation authors are not limited by what attributes they can use when developing their telemetry and not a hinderance for existing standards within Open Telemetry. Organisations can define what resource classifications are allowed to be processed by an observability suite, what is subject to additional processing, and understand the types of data being sent. For example, all high cardinality data can be sent to on prem short term storage and then forwarded to a vendor with high cardinality attributes removed so that it can be viewed over a longer time period to show trends. 
+Updating the SDK to include the convention of data classification would mean that users can extend their current telemetry via an opt in process to enable enhanced controls over the telemetry data without impacting the developer experience. Instrumentation authors are not limited by what attributes they can use when developing their telemetry and not a hindrance for existing standards within Open Telemetry. Organisations can define what resource classifications are allowed to be processed by an observability suite, what is subject to additional processing, and understand the types of data being sent. For example, all high cardinality data can be sent to on prem short term storage and then forwarded to a vendor with high cardinality attributes removed so that it can be viewed over a longer time period to show trends. 
 
 Having the ability to set data classification on resources means that:
 
@@ -122,15 +122,15 @@ processors:
 service:
   pipeline:
     metrics:
-      recievers:
+      receivers:
       - otlp/metrics
       processor:
       - classifier/remove-highcardinality
       - classifier/remove-sensitive
       exporter:
       - external-metric-vendor
     traces:
-      recievers:
+      receivers:
       - otlp/traces
       processors:
       - classifier/tracesampler
@@ -157,23 +157,23 @@ message KeyValue {
 
 // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.proto#L160
 message Metric {
-// ... ommitted 
+// ... omitted 
 +  // classification represents a bitwise flag 
 +  // that is used to represent metric classification type
 +  int64    classification  = 12;
 }
 
 // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.proto#L84
 message Span {
-// ... ommitted 
+// ... omitted 
 +  // classification represents a bitwise flag 
 +  // that is used to represent span classification type
 +  int64    classification  = 16;
 }
 
 // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/logs/v1/logs.proto#L113
 message LogRecord {
-// ... ommitted 
+// ... omitted 
 +  // classification represents a bitwise flag 
 +  // that is used to represent LogRecord classification type
 +  int64    classification  = 11;