In #459 we declared that empty-string values are meaningful. I agree with this position and recommend the same treatment for the metrics API. However, the same change introduces language about null-valued span attributes, stating that they are effectively skipped and/or indicate deletion of an attribute.

Attribute values of `null` are considered to be not set and get discarded as if that `SetAttribute` call had never been made.
As an exception to this, if overwriting of values is supported, this results in clearing the previous value and dropping the attribute key from the set of attributes.

This topic came up in the metrics API because many exporters will treat an unspecified value as an empty string in the exposition format. The default Metrics SDK specification will have to say something about this particular point. See the related discussion in #345.

As for null, this is something of a language-specific term. For example, there is no way to construct a null-valued attribute in the current Go API, because there simply is not a method to create a null-valued KeyValue. The Go API uses an "INVALID" type to indicate when a variable has not been initialized, and we could possibly treat the uninitialized state as null. However, I would call the uninitialized state an error, and would prefer the API tell me that I have made an error rather than delete an attribute because I "set" the uninitialized value.

As for the value of null, it is a value. It is a value in the language and it is a value in JSON, and I would argue that we should have an explicit null-valued attribute, metric label, and resource. In export formats that preserve value type, this would have its own distinct type in the protocol (i.e., in JSON "null" vs null). In export formats that require a string representation, the representation is "null", not the empty string, because these are meaningfully different values.

My request is that we declare a meaningful null value. The call to SetAttribute is not skipped, but a null-value is recorded.

If we intend to support a Span API for deleting a current annotation (as discussed when setting null-valued attributes in #459)--and I do not think we should--then we should have an explicit API for deleting span attributes (e.g., DeleteAttribute). However, I'll note that this topic was briefly discussed because OpenCensus and OpenTracing have a notion of "overwrite" but not of "delete" for attributes: open-telemetry/opentelemetry-go#53 (comment)