Add attribute value precedence of scope attribute in the spec

[scheler]

What are you trying to achieve?

The OTEP for Scope attribute has a section on attribute value precedence, I do not see it in the spec so it will be good to add.

What did you expect to see?

The spec currently lacks clarity if an attribute is present both in a Span/LogRecord and the enclosing Scope. It will be good to add the attribute value precedence in

• Obtaining a Tracer, while providing scope attributes
• mapping-to-non-otlp.md (Instrumentation Scope Attributes section)

[scheler]

The section attribute value precedence in the OTEP talks only about mapping to non-OTLP destinations, but it will be good to define for OTLP as well.

Specifically, if an attribute is present in all the spans in a given scope, would it be equivalent to specifying it only in the scope?

@tigrannajaryan

[tigrannajaryan]

The section attribute value precedence in the OTEP talks only about mapping to non-OTLP destinations, but it will be good to define for OTLP as well.

Specifically, if an attribute is present in all the spans in a given scope, would it be equivalent to specifying it only in the scope?

@scheler It will be only equivalent when flattening OTLP to non-OTLP destinations which don't support the concept of Scope.

However, generally speaking in OpenTelemetry world they are not equivalent. The Scope attributes describe the Scope, they don't describe the Spans. It is not intended to be used as a deduplication/compression mechanism where any Span attribute can be recorded on the Scope simply to denote that it applies to all Spans.

[tigrannajaryan]

The spec currently says

If the same attribute is specified both at the Span/Metric/LogRecord and at the Scope then the attribute value at Span/Metric/LogRecord takes precedence.

@scheler isn't this sufficient? Are you looking for something more?

[scheler]

@tigrannajaryan Somehow I couldn't find the quoted text in this repo. Can you please point me to that? I was looking for it here.

I understand that it is applicable only while exporting to non-OTLP destinations currently. Your reasoning that the scope attributes describe the scope and not the spans is also valid, but then it conflicts with the Attribute value precedence statement - if they describe different objects, then one cannot override the other. At least, we could add the scope name as prefix while representing the scope attribute at the span/logRecord level.

I understand deduplication is not an objective of scope attributes, but then it is not atypical when you normalize data taking out redundancy.

Btw, the reason I am bring this up is in open-telemetry/opentelemetry-js#3222 (comment) - we were trying to start with scope attributes for certain RUM attributes and were wondering if we can define a path to moving those attributes one level higher later (think Ephemeral Resource Attributes). It would be a nice property of our data models if the attributes represented out an outer level are a more generalized version of the attributes at inner level. If this property can be achieved through some convention, that would be fine too.

[tigrannajaryan]

Somehow I couldn't find the quoted text in this repo. Can you please point me to that? I was looking for it here.

You are right. It is in the OTEP, but I is not yet added to the spec. The PR that adds it to the spec is still in progress: #2736

I understand that it is applicable only while exporting to non-OTLP destinations currently. Your reasoning that the scope attributes describe the scope and not the spans is also valid, but then it conflicts with the Attribute value precedence statement - if they describe different objects, then one cannot override the other. At least, we could add the scope name as prefix while representing the scope attribute at the span/logRecord level.

This is the other option discussed in the that PR: https://github.com/open-telemetry/opentelemetry-specification/pull/2736/files#r948292814

[tigrannajaryan]

So, looks like this issue is a duplicate of #2535

[scheler]

Closing as a dup of #2535