Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixes a few typos in sdk.md #3608

Merged
merged 2 commits into from
Jul 18, 2023
Merged

Fixes a few typos in sdk.md #3608

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1e33a61
Fix a few typos
pirgeo Jul 18, 2023
9b1586a
Merge branch 'main' into patch-1
yurishkuro Jul 18, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 16 additions & 16 deletions specification/metrics/sdk.md
View file
Open in desktop
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
Loading