Opentelemetry-specification: Clarify exported span attribute precedence

[jtescher]

If a span has an attribute set which will generally also be added by an exporter (e.g. span.kind), currently exporters in many languages will end up with both values being reported. We should clarify the expected behavior here, e.g. should some attribute names be reserved and filtered out of the attribute set? Should both values be reported? Should the attribute-defined value be taken and the span value be ignored?

[carlosalberto]

Exporters are expected to get read-only data. Maybe you are referring to SpanProcessors?

[Oberon00]

@carlosalberto I think this is about conventions for translating OTel span data to non-OT protocols that don't have dedicated fields for e.g. the span kind. These exporters would presumably translate the span kind into some attribute. The question now is, what should happen if an attribute with that key already exists?

[jtescher]

@Oberon00 exactly. For example should the Jaeger exporter chose the span kind or the attribute named span.kind if they differ?

[arminru]

Rather than defining a precedence for overwriting values I would avoid this situation beforehand by introducing _reserved_ attribute keys for all first-class citizens (span name, kind, status, ...) to the spec.

[Oberon00]

That makes a lot of sense IMHO.

[bogdandrutu]

Rather than defining a precedence for overwriting values I would avoid this situation beforehand by introducing reserved attribute keys for all first-class citizens (span name, kind, status, ...) to the spec.

It will be hard to reserve all possible values, for any random protocol that exists, for example are we going to reserve all attributes for datadog, dynatrace, jaege, lightstep, splunk, x-ray, zipkin, etc.? Probably not, so a more scalable solution should be implemented for this.

[Oberon00]

We would not be reserving names for protocol-specific fields, but for things that a span conceptually contains according to the OpenTelemetry span API specification.

[bogdandrutu]

@Oberon00 and let's say Span.Kind which is a concept in OpenTelemetry what are you going to reserve? span.kind why? is that not a OpenTracing convention, why not kind?

It will get bad very soon.

[arminru]

@bogdandrutu "span.kind" sounds reasonable as a reserved attribute for protocols/data models that don't support a native Kind of a Span. In this particular case, OpenTracing happens to have their own semantic convention "span.kind" already matching OpenTelemetry's first-class Span.Kind, so that should be fine.
Otherwise, prefixing it with otel like we have for "otel.instrumentation_library.name" and "otel.instrumentation_library.version" in the Zipkin and Jaeger exporter spec would be safer to avoid collisions.