Skip to content

Commit

Permalink
Fixes a few typos in sdk.md (open-telemetry#3608)
Browse files Browse the repository at this point in the history
## Changes

Looking at open-telemetry#3585, I found a typo. While looking through the page I found
a few more.

Co-authored-by: Yuri Shkuro <[email protected]>
  • Loading branch information
pirgeo and yurishkuro authored Jul 18, 2023
1 parent 2a15977 commit b539be7
Showing 1 changed file with 16 additions and 16 deletions.
32 changes: 16 additions & 16 deletions specification/metrics/sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -245,46 +245,46 @@ The SDK MUST accept the following criteria:
If the SDK does not support wildcards in general, it MUST still recognize the
special single asterisk (`*`) character as matching all Instruments.

Users can provide a `name`, but it is up to their descretion. Therefore, the
Users can provide a `name`, but it is up to their discretion. Therefore, the
instrument selection criteria parameter needs to be structured to accept a
`name`, but MUST NOT obligate a user to provide one.
* `type`: The type of Instruments to match. If the value of `type` is the same
as an Instrument's type, then the criterion matches that Instrument.

Users can provide a `type`, but it is up to their descretion. Therefore, the
Users can provide a `type`, but it is up to their discretion. Therefore, the
instrument selection criteria parameter needs to be structured to accept a
`type`, but MUST NOT obligate a user to provide one.
* `unit`: If the value of `unit` is the same as an Instrument's unit, then the
criterion matches that Instrument.

Users can provide a `unit`, but it is up to their descretion. Therefore, the
Users can provide a `unit`, but it is up to their discretion. Therefore, the
instrument selection criteria parameter needs to be structured to accept a
`unit`, but MUST NOT obligate a user to provide one.
* `meter_name`: If the value of `meter_name` is the same as the Meter that
created an Instrument, then the criterion matches that Instrument.

Users can provide a `meter_name`, but it is up to their descretion.
Users can provide a `meter_name`, but it is up to their discretion.
Therefore, the instrument selection criteria parameter needs to be structured
to accept a `meter_name`, but MUST NOT obligate a user to provide one.
* `meter_version`: If the value of `meter_version` is the same version as the
Meter that created an Instrument, then the criterion matches that Instrument.

Users can provide a `meter_version`, but it is up to their descretion.
Users can provide a `meter_version`, but it is up to their discretion.
Therefore, the instrument selection criteria parameter needs to be structured
to accept a `meter_version`, but MUST NOT obligate a user to provide one.
* `meter_schema_url`: If the value of `meter_schema_url` is the same schema URL
as the Meter that created an Instrument, then the criterion matches that
Instrument.

Users can provide a `meter_schema_url`, but it is up to their descretion.
Users can provide a `meter_schema_url`, but it is up to their discretion.
Therefore, the instrument selection criteria parameter needs to be structured
to accept a `meter_schema_url`, but MUST NOT obligate a user to provide one.

The SDK MAY accept additional criteria. For example, a strongly typed language
may support point type criterion (e.g. allow the users to select Instruments
based on whether the underlying number is integral or rational). Users can
provide these additional criteria the SDK accepts, but it is up to their
descretion. Therefore, the instrument selection criteria can be structured to
discretion. Therefore, the instrument selection criteria can be structured to
accept the criteria, but MUST NOT obligate a user to provide them.

#### Stream configuration
Expand All @@ -304,14 +304,14 @@ The SDK MUST accept the following stream configuration parameters:
accordance with initialization [error handling
principles](../error-handling.md#basic-error-handling-principles).

Users can provide a `name`, but it is up to their descretion. Therefore, the
Users can provide a `name`, but it is up to their discretion. Therefore, the
stream configuration parameter needs to be structured to accept a `name`, but
MUST NOT obligate a user to provide one. If the user does not provide a
`name` value, name from the Instrument the View matches MUST be used by
default.
* `description`: The metric stream description that SHOULD be used.

Users can provide a `description`, but it is up to their descretion.
Users can provide a `description`, but it is up to their discretion.
Therefore, the stream configuration parameter needs to be structured to
accept a `description`, but MUST NOT obligate a user to provide one. If the
user does not provide a `description` value, the description from the
Expand All @@ -320,7 +320,7 @@ The SDK MUST accept the following stream configuration parameters:
the user during the measurement, for the metric stream. All attributes with
keys other than those in the list MUST be ignored.

Users can provide `attribute_keys`, but it is up to their descretion.
Users can provide `attribute_keys`, but it is up to their discretion.
Therefore, the stream configuration parameter needs to be structured to
accept `attribute_keys`, but MUST NOT obligate a user to provide them. If the
user does not provide any values, all of the attributes MUST be kept (TODO:
Expand All @@ -329,7 +329,7 @@ The SDK MUST accept the following stream configuration parameters:
* `aggregation`: The name of an [aggregation](#aggregation) function to use in
aggregating the metric stream data.

Users can provide an `aggregation`, but it is up to their descretion.
Users can provide an `aggregation`, but it is up to their discretion.
Therefore, the stream configuration parameter needs to be structured to
accept an `aggregation`, but MUST NOT obligate a user to provide one. If the
user does not provide an `aggregation` value, the `MeterProvider` MUST apply
Expand All @@ -341,7 +341,7 @@ The SDK MUST accept the following stream configuration parameters:
callback similar to aggregation selection functionality which allows
different reservoirs to be chosen by the aggregation.

Users can provide an `exemplar_reservoir`, but it is up to their descretion.
Users can provide an `exemplar_reservoir`, but it is up to their discretion.
Therefore, the stream configuration parameter needs to be structured to
accept an `exemplar_reservoir`, but MUST NOT obligate a user to provide one.
If the user does not provide an `exemplar_reservoir` value, the
Expand All @@ -353,7 +353,7 @@ The SDK MUST accept the following stream configuration parameters:
a single instrument. See [cardinality limits](#cardinality-limits), below.

Users can provide an `aggregation_cardinality_limit`, but it is up to their
descretion. Therefore, the stream configuration parameter needs to be
discretion. Therefore, the stream configuration parameter needs to be
structured to accept an `aggregation_cardinality_limit`, but MUST NOT
obligate a user to provide one. If the user does not provide an
`aggregation_cardinality_limit` value, the `MeterProvider` MUST apply the
Expand Down Expand Up @@ -711,7 +711,7 @@ limit is the hard limit on the number of metric streams that can be collected.

#### Configuration

The cardinality limit for an aggregation is defined one of three ways:
The cardinality limit for an aggregation is defined in one of three ways:

1. A [view](#view) with criteria matching the instrument an aggregation is
created for has an `aggregation_cardinality_limit` value defined for the
Expand Down Expand Up @@ -783,7 +783,7 @@ fields](./api.md#instrument) are equal. The term _distinct_ applied
to Instruments describes instances where at least one field value is
different.

To accomidate [the recommendations from the data
To accommodate [the recommendations from the data
model](data-model.md#opentelemetry-protocol-data-model-producer-recommendations),
the SDK MUST aggregate data from [identical Instruments](api.md#instrument)
together in its export pipeline.
Expand Down Expand Up @@ -1192,7 +1192,7 @@ Exporters through their associated MetricReader. OpenTelemetry
language implementations MAY support automatically configuring the
[MetricReader](#metricreader) to use for an Exporter.

The goal of the interface is to minimize burden of implementation for
The goal of the interface is to minimize the burden of implementation for
protocol-dependent telemetry exporters. The protocol exporter is expected to be
primarily a simple telemetry data encoder and transmitter.

Expand Down

0 comments on commit b539be7

Please sign in to comment.