Fixes a few typos in sdk.md (#3608)

## Changes

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

Co-authored-by: Yuri Shkuro <[email protected]>

specification/metrics/sdk.md

@@ -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
@@ -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
@@ -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:
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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.
@@ -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.