Named meter namespace clarification

specification/api-metrics-user.md

@@ -9,9 +9,21 @@ TODO: Add a table of contents.
 
 ## Overview
 
-Metric instruments are the entry point for application and framework
-developers to instrument their code using counters, gauges, and
-measures.
+Metric instruments are the entry point for application and framework developers to instrument their code using counters, gauges, and measures.
+Metrics are created by calling methods on a `Meter` which is in turn created by a global `MeterFactory`.
+
+### Obtaining a Meter
+
+New `Meter` instances can be created via a `MeterFactory` and its `getMeter` method.
+`MeterFactory`s are generally expected to be used as singletons.
+Implementations SHOULD provide a single global default `MeterFactory`. The `getMeter` method expects two string arguments:
+
+- `name` (required): This name must identify the instrumentation library (also referred to as integration, e.g. `io.opentelemetry.contrib.mongodb`)
+  and *not* the instrumented library.
+  In case an invalid name (null or empty string) is specified, a working default `Meter` implementation as a fallback is returned
+  rather than returning null or throwing an exception.
+  A `MeterFactory` could also return a no-op `Meter` here if application owners configure the SDK to suppress telemetry produced by this library.
+- `version` (optional): Specifies the version of the instrumentation library (e.g. `semver:1.0.0`).
 
 ### Metric names
 
@@ -23,23 +35,18 @@ external systems.  Metric names conform to the following syntax:
 3. The first character must be non-numeric, non-space, non-punctuation
 4. Subsequent characters must be belong to the alphanumeric characters, '_', '.', and '-'.
 
-Metrics names belong to a namespace by virtue of a "Named" `Meter`
-instance.  A "Named" `Meter` refers to the requirement that every
-`Meter` instance must have an associated `component` label, determined
-statically in the code.  The `component` label value of the associated
-`Meter` serves as its namespace, allowing the same metric name to be
-used in multiple libraries of code, unambiguously, within the same
-application.
-
-Metric instruments are defined using a `Meter` instance, using a
-variety of `New` methods specific to the kind of metric and type of
-input (integer or floating point).  The Meter will return an error
-when a metric name is already registered with a different kind for the
-same component name.  Metric systems are expected to automatically
-prefix exported metrics by the `component` namespace in a manner
-consistent with the target system.  For example, a Prometheus exporter
-SHOULD use the component followed by `_` as the [application
-prefix](https://prometheus.io/docs/practices/naming/#metric-names).
+Metric names belong to a namespace. The `name` of the associated `Meter`
+serves as its namespace, allowing the same metric name to be used in
+multiple libraries of code, unambiguously, within the same application.
+
+Metric instruments are defined using a `Meter` instance, using a variety
+of `New` methods specific to the kind of metric and type of input(integer
+or floating point).  The Meter will return an error when a metric name is
+already registered with a different kind for the same name.  Metric systems
+are expected to automatically prefix exported metrics by the namespace in a
+manner consistent with the target system.  For example, a Prometheus exporter
+SHOULD use the namespace followed by `_` as the
+[application prefix](https://prometheus.io/docs/practices/naming/#metric-names).
 
 ### Format of a metric event
 
@@ -71,7 +78,7 @@ either floating point or integer inputs, see the detailed design below.
 Binding instruments to a single `Meter` instance has two benefits:
 
 1. Instruments can be exported from the zero state, prior to first use, with no explicit `Register` call
-2. The component name provided by the named `Meter` satisfies a namespace requirement
+2. The name provided by the `Meter` satisfies a namespace requirement
 
 The recommended practice is to define structures to contain the
 instruments in use and keep references only to the instruments that
@@ -82,7 +89,7 @@ metric instruments statically and providing the `Meter` interface at
 the time of use.  In this example, typical of statsd clients, existing
 code may not be structured with a convenient place to store new metric
 instruments.  Where this becomes a burden, it is recommended to use
-the global meter factory to construct a static named `Meter`, to
+the global meter factory to construct a static `Meter`, to
 construct metric instruments.
 
 The situation is similar for users of Prometheus clients, where