standardise on indexes

Author: thompson-tomo

.textlintrc.yml

@@ -28,6 +28,7 @@ rules:
       - 'bug[- ]fix(es)?'
       - 'readme(s)?'
       - 'to-?do(s)?(?=[ ,.])'
+      - 'indexes\\b'
     terms:
       - Actix
       - Ajax
@@ -140,6 +141,7 @@ rules:
       - ['http[ /]?2(?:\.0)?', HTTP/2]
       - [he(/| or )she, they]
       - [\(s\)he, they]
+      - ["indices\\b", "indexes"]
       - ["id['’]?s", IDs]
       - # Capitalize Java, but NOT for strings like:
         # - File names: file.java
@@ -183,3 +185,4 @@ rules:
       # - ["(auto(matic)?[- ])?instrumentation (module|package)", "instrumentation library"]
       # - ["(auto(matic)?[- ])?instrumentation (modules|packages)", "instrumentation libraries"]
       - snake_case
+      - location_indices

oteps/0066-separate-context-propagation.md

@@ -102,7 +102,7 @@ from the current span.
 ### Correlations API
 
 In addition to trace propagation, OpenTelemetry provides a simple mechanism for
-propagating indices, called the Correlations API. Correlations are
+propagating indexes, called the Correlations API. Correlations are
 intended for indexing observability events in one service with attributes
 provided by a prior service in the same transaction. This helps to establish a
 causal relationship between these events. For example, determining that a

oteps/profiles/0239-profiles-data-model.md

@@ -409,7 +409,7 @@ message Profile {
   // should not be used to store any machine-readable information, it is only
   // for human-friendly content. The profile must stay functional if this field
   // is cleaned.
-  repeated int64 comment = 13; // Indices into string table.
+  repeated int64 comment = 13; // Indexes into string table.
   // Index into the string table of the type of the preferred sample
   // value. If unset, clients should default to the last sample value.
   int64 default_sample_type = 14;
@@ -515,7 +515,7 @@ message ValueType {
 // augmented with auxiliary information like the thread-id, some
 // indicator of a higher level request being handled etc.
 message Sample {
-  // The indices recorded here correspond to locations in Profile.location.
+  // The indexes recorded here correspond to locations in Profile.location.
   // The leaf is at location_index[0]. [deprecated, superseded by locations_start_index / locations_length]
   repeated uint64 location_index = 1;
   // locations_start_index along with locations_length refers to to a slice of locations in Profile.location.
@@ -911,7 +911,7 @@ is cleaned.
 
 ##### Field `default_sample_type`
 
-Indices into string table.
+Indexes into string table.
 Index into the string table of the type of the preferred sample
 value. If unset, clients should default to the last sample value.
 </details>
@@ -944,7 +944,7 @@ indicator of a higher level request being handled etc.
 
 ##### Field `location_index`
 
-The indices recorded here correspond to locations in Profile.location.
+The indexes recorded here correspond to locations in Profile.location.
 The leaf is at location_index[0]. [deprecated, superseded by locations_start_index / locations_length]
 
 ##### Field `locations_start_index`
@@ -1431,7 +1431,7 @@ In the process of refining the data model, multiple alternative representations
 
 * `pprof` representation is data in original pprof format.
 * `denormalized` representation, where all messages are embedded and no references by index are used. This is the simplest representation, but it is also the least efficient (by a huge margin) in terms of CPU utilization, memory consumption and size of the resulting protobuf payload.
-* `normalized` representation, where messages that repeat often are stored in separate tables and are referenced by indices. See [this chapter](#relationships-between-messages) for more details. This technique reduces the size of the resulting protobuf payload and the number of objects that need to be allocated to parse such payload.
+* `normalized` representation, where messages that repeat often are stored in separate tables and are referenced by indexes. See [this chapter](#relationships-between-messages) for more details. This technique reduces the size of the resulting protobuf payload and the number of objects that need to be allocated to parse such payload.
 * `arrays` representation, which is based on `normalized` representation, but uses arrays of integers instead of arrays of structures to represent messages. It further reduces the number of allocations, and the size of the resulting protobuf payload.
 * `pprofextended` is a modified `pprof` representation. It is the one presented in this OTEP.
 

oteps/trace/4673-experimental-probability-sampling.md

@@ -932,7 +932,7 @@ predetermined list of seeds.
     } {
 ```
 
-Note that seed indices in the example above have what appears to be
+Note that seed indexes in the example above have what appears to be
 the correct distribution.  The five 0s, two 1s, five 2s, one 3s, and
 one 4 demonstrate that it is relatively easy to find examples where
 there is exactly one failure.  Probability 0.001, with seed index 6 in

specification/common/README.md

@@ -68,7 +68,7 @@ However, if it is impossible to make sure that no `null` values are accepted
 processors / exporters as `null`). If exporters do not support exporting `null`
 values, they MAY replace those values by 0, `false`, or empty strings.
 This is required for map/dictionary structures represented as two arrays with
-indices that are kept in sync (e.g., two attributes `header_keys` and `header_values`,
+indexes that are kept in sync (e.g., two attributes `header_keys` and `header_values`,
 both containing an array of strings to represent a mapping
 `header_keys[i] -> header_values[i]`).
 

specification/metrics/data-model.md

@@ -611,8 +611,8 @@ index `offset+i`.
 For a given range, positive or negative:
 
 - Bucket index `0` counts measurements in the range `(1, base]`
-- Positive indices correspond with absolute values greater than `base`
-- Negative indices correspond with absolute values less than or equal to 1
+- Positive indexes correspond with absolute values greater than `base`
+- Negative indexes correspond with absolute values less than or equal to 1
 - There are `2**scale` buckets between successive powers of 2.
 
 For example, with `scale=3` there are `2**3` buckets between 1 and 2.
@@ -675,9 +675,9 @@ SHOULD ensure that the index of any encoded bucket falls within the
 range of a signed 32-bit integer.  This recommendation is applied to
 limit the width of integers used in standard processing pipelines such
 as the OpenTelemetry Collector.  The wire-level protocol could be
-extended for 64-bit bucket indices in a future release.
+extended for 64-bit bucket indexes in a future release.
 
-Producers use a mapping function to compute bucket indices.  Producers
+Producers use a mapping function to compute bucket indexes.  Producers
 are presumed to support IEEE double-width floating-point numbers with
 11-bit exponent and 52-bit significand.  The pseudo-code below for
 mapping values to exponents refers to the following constants:
@@ -713,8 +713,8 @@ reference implementations.
 For scale zero, the index of a value equals its normalized base-2
 exponent, meaning the value of *exponent* in the base-2 fractional
 representation `1._significand_ * 2**_exponent_`.  Normal IEEE 754
-double-width floating point values have indices in the range
-`[-1022, +1023]` and subnormal values have indices in the range
+double-width floating point values have indexes in the range
+`[-1022, +1023]` and subnormal values have indexes in the range
 `[-1074, -1023]`.  This may be written as:
 
 ```golang
@@ -787,7 +787,7 @@ func MapToIndexScale0(value float64) int {
 For negative scales, the index of a value equals the normalized
 base-2 exponent (as by `MapToIndexScale0()` above) shifted to the right
 by `-scale`.  Note that because of sign extension, this shift performs
-correct rounding for the negative indices.  This may be written as:
+correct rounding for the negative indexes.  This may be written as:
 
 ```golang
 // MapToIndexNegativeScale computes a bucket index for scales <= 0.
@@ -932,14 +932,14 @@ such values counted in the adjacent buckets.
 
 #### ExponentialHistogram: Consumer Recommendations
 
-ExponentialHistogram bucket indices are expected to map into buckets
+ExponentialHistogram bucket indexes are expected to map into buckets
 where both the upper and lower boundaries can be represented
 using IEEE 754 double-width floating point values.  Consumers MAY
 round the unrepresentable boundary of a partially representable bucket
 index to the nearest representable value.
 
 Consumers SHOULD reject ExponentialHistogram data with `scale` and
-bucket indices that overflow or underflow this representation.
+bucket indexes that overflow or underflow this representation.
 Consumers that reject such data SHOULD warn the user through error
 logging that out-of-range data was received.