Clarify that Scope attributes are not part of its identity

Resolves open-telemetry#2762

This change says that Scope attributes are NOT part of the Tracer/Meter/Logger identity.

The consequence of this change is the following:

- It is no longer possible to obtain a Logger with different sets of
  attributes from the same instrumentation library (using the same name,
  version,schema_url). It may be desirable to make this possible in the
  future, but right now it is impossible since the attributes are not
  part of the Scope's identity.

- Likewise, it is no longer possible to obtain a Tracer and Meter with
  different sets of attributes from the same instrumentation library (using the
  same name, version,schema_url). This is likely the only desirable way
  for Tracer and Meter.

specification/logs/api.md

@@ -100,13 +100,13 @@ SHOULD be true by default.
 associate with emitted telemetry.
 
 Implementations MUST return different `Logger` instances when called repeatedly
-with different values of parameters. Note that always returning a new `Logger`
+with different values of (name,version,schema_url) parameters. Note that always returning a new `Logger`
 instance is a valid implementation. The only exception to this rule is the no-op
 `Logger`: implementations MAY return the same instance regardless of parameter
 values.
 
 Implementations MUST NOT require users to repeatedly obtain a Logger again with
-the same name+version+schema_url+event_domain+include_trace_context+attributes
+the same (name,version,schema_url) parameters
 to pick up configuration changes. This can be achieved either by allowing to
 work with an outdated configuration or by ensuring that new configuration
 applies also to previously returned Loggers.
@@ -115,7 +115,7 @@ Note: This could, for example, be implemented by storing any mutable
 configuration in the `LoggerProvider` and having `Logger` implementation objects
 have a reference to the `LoggerProvider` from which they were obtained.
 If configuration must be stored per-Logger (such as disabling a certain `Logger`),
-the `Logger` could, for example, do a look-up with its name+version+schema_url+event_domain+include_trace_context+attributes
+the `Logger` could, for example, do a look-up with its (name,version,schema_url)
 in a map in the `LoggerProvider`, or the `LoggerProvider` could maintain a registry
 of all returned `Logger`s and actively update their configuration if it changes.
 

specification/metrics/api.md

@@ -150,17 +150,17 @@ This API MUST accept the following parameters:
 Meters are identified by all of these parameters.
 
 Implementations MUST return different `Meter` instances when called repeatedly
-with different values of parameters. Note that always returning a new `Meter` instance
+with different values of (name,version,schema_url) parameters. Note that always returning a new `Meter` instance
 is a valid implementation. The only exception to this rule is the no-op `Meter`:
 implementations MAY return the same instance regardless of parameter values.
 
 It is unspecified whether or under which conditions the same or different
 `Meter` instances are returned from this function when the same
-(name,version,schema_url,attributes) parameters are used.
+(name,version,schema_url) parameters are used.
 
 The term *identical* applied to Meters describes instances where all identifying fields
-are equal. The term *distinct* applied to Meters describes instances where at
-least one identifying field has a different value.
+(name,version,schema_url) are equal. The term *distinct* applied to Meters describes instances where at
+least one of identifying fields (name,version,schema_url) has a different value.
 
 Implementations MUST NOT require users to repeatedly obtain a `Meter` with
 the same identity to pick up configuration changes. This can be

specification/trace/api.md

@@ -132,12 +132,12 @@ This API MUST accept the following parameters:
   to associate with emitted telemetry.
 
 Implementations MUST return different `Tracer` instances when called repeatedly
-with different values of parameters. Note that always returning a new `Tracer` instance
+with different values of (name,version,schema_url) parameters. Note that always returning a new `Tracer` instance
 is a valid implementation. The only exception to this rule is the no-op `Tracer`:
 implementations MAY return the same instance regardless of parameter values.
 
 Implementations MUST NOT require users to repeatedly obtain a `Tracer` again
-with the same name+version+schema_url+attributes to pick up configuration changes.
+with the same (name,version,schema_url) parameters to pick up configuration changes.
 This can be achieved either by allowing to work with an outdated configuration or
 by ensuring that new configuration applies also to previously returned `Tracer`s.