Clarify preferred aggregation temporality; give Views a selection strategy

CHANGELOG.md

@@ -20,6 +20,8 @@ release.
 - Introduce the concept of Instrumentation Scope to replace/extend Instrumentation
   Library. The Meter is now associated with Instrumentation Scope
   ([#2276](https://github.com/open-telemetry/opentelemetry-specification/pull/2276)).
+- Clarify what is meant by "preferred" aggregation temporality.
+  ([#2314](https://github.com/open-telemetry/opentelemetry-specification/pull/2314))
 
 ### Logs
 

specification/metrics/api.md

@@ -406,7 +406,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
-callback function reports the absolute value of the counter. To determine the
+callback function reports the current value of the counter. To determine the
 reported rate the counter is changing, the difference between successive
 measurements is used.
 
@@ -895,7 +895,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [UpDownCounter.Add()](#add-1) which takes the increment/delta value,
-the callback function reports the absolute value of the Asynchronous
+the callback function reports the current value of the Asynchronous
 UpDownCounter. To determine the reported rate the Asynchronous UpDownCounter is
 changing, the difference between successive measurements is used.
 

specification/metrics/sdk.md

@@ -181,7 +181,8 @@ are the inputs:
     apply a [default aggregation](#default-aggregation). If the aggregation
     outputs metric points that use aggregation temporality (e.g. Histogram,
     Sum), the SDK SHOULD handle the aggregation temporality based on the
-    temporality of each [MetricReader](#metricreader) instance.
+    [preferred aggregation temporality](#preferred-aggregation-temporality) 
+	of each [MetricReader](#metricreader) instance.
   * The `exemplar_reservoir` (optional) to use for storing exemplars.
     This should be a factory or callback similar to aggregation which allows
     different reservoirs to be chosen by the aggregation.
@@ -624,25 +625,55 @@ The SDK SHOULD provide a way to allow `MetricReader` to respond to
 idiomatic approach, for example, as `OnForceFlush` and `OnShutdown` callback
 functions.
 
+### Preferred aggregation temporality
+
 The SDK SHOULD provide a way to allow the preferred [Aggregation
-Temporality](./datamodel.md#temporality) to be specified for a `MetricReader`
-instance during the setup (e.g. initialization, registration, etc.) time. If the
-preferred temporality is explicitly specified then the SDK SHOULD respect that,
-otherwise use Cumulative.
-
-[OpenTelemetry SDK](../overview.md#sdk)
-authors MAY choose the best idiomatic design for their language:
-
-* Whether to treat the temporality settings as recommendation or enforcement.
-  For example, if the temporality is set to Delta, would the SDK want to perform
-  Cumulative->Delta conversion for an [Asynchronous
-  Counter](./api.md#asynchronous-counter), or downgrade it to a
-  [Gauge](./datamodel.md#gauge), or keep consuming it as Cumulative due to the
-  consideration of [memory
-  efficiency](./supplementary-guidelines.md#memory-management)?
-* Refer to the [supplementary
-  guidelines](./supplementary-guidelines.md#aggregation-temporality), which have
-  more context and suggestions.
+Temporality](./datamodel.md#temporality) to be specified for a
+`MetricReader` instance during setup (e.g. initialization,
+registration, etc.). This preference gives the SDK user control over the
+amount of long-term memory dedicated to reading metrics.
+
+The synchronous instruments generally define data points having
+aggregation temporality (e.g., `Sum`, `Histogram`).  For these points,
+a `MetricReader` configured with Cumulative aggregation temporality
+implies conversion from Delta into Cumulative aggregation temporality.
+
+The asynchronous `Counter` and `UpDownCounter` instruments are defined
+by observations that are cumulative values to begin with.  For these
+points, a change of aggregation temporality implies conversion from
+Cumulative into Delta aggregation temporality.
+
+Because of these differences, synchronous and asynchronous instruments
+are given separate treatment.  When configuring the preferred
+aggregation temporality for a `MetricReaderExporter`, the
+implementation MUST provide a mechanism that supports configuring the
+exporter's preferred temporality on the basis of instrument kind for
+the five instruments `Counter`, `Asynchronous Counter`,
+`UpDownCounter`, `Asynchronous UpDownCounter`, and `Histogram`.
+
+A configured `MetricReader` instance MUST expose data in the preferred
+aggregation temporality for points deriving from the five instruments
+that define aggregation temporality.
+
+Two well-known preferences are named, offering a simple way to express
+exporter preferences through environment variables and in
+configuration files.  The following named preferences SHOULD be
+supported:
+
+- **AllCumulative**: All data points with aggregation temporality are
+  exported using Cumulative aggregation temporality. 
+- **DeltaPreferred**: Data points from `Counter`, `Asynchronous
+  Counter`, and `Histogram` instruments use Delta aggregation
+  temporality, whereas whereas data points from `UpDownCounter` and
+  `Asynchronous UpDownCounter` are exported with Cumualtive
+  aggregation temporality.
+
+If the preferred temporality is not explicitly specified, the SDK
+SHOULD use the AllCumulative aggregation temporality preference.
+
+Refer to the [data model section on Stream
+Manipulations](datamodel.md#stream-manipulations) for more detail on
+changing aggregation temporality.
 
 ### MetricReader operations