Decide if event.domain separately from event.name is necessary

[tigrannajaryan]

We mentioned the possibility of merging event.domain and event.name into one attribute. Now that even.domain is no longer on the Scope having it is a separate attribute is no longer mandatory.

There are a few things to consider here:

• Whether the combined attribute is good enough for use cases @tedsuo mentioned ("primary index").
• If merged how do we define the formatting of the attribute value, e.g. should the value be prefixed by reverse FQDN? Can we also use plain prefixes like k8s.?
• What other operations need to be performed on the domain and name values which are qualitatively easier/possible when the values are recorded as separate attributes and are harder/impossible with a single combined attribute?

[tigrannajaryan]

@open-telemetry/specs-logs-approvers FYI.

[djaglowski]

Whether the combined attribute is good enough for use cases

I'm only aware of the "primary index" use case, which it seems this combined attribute would be sufficient for. Does anyone know of any other cases we need to account for?

[djaglowski]

If merged how do we define the formatting of the attribute value, e.g. should the value be prefixed by reverse FQDN? Can we also use plain prefixes like k8s.?

I think OTel should be able to define "official" prefixes within the specification repo, and we should encourage reverse FQDN for unofficial attributes (e.g. a 3rd party defining their own)

[tigrannajaryan]

Whether the combined attribute is good enough for use cases

I'm only aware of the "primary index" use case, which it seems this combined attribute would be sufficient for. Does anyone know of any other cases we need to account for?

The "group by domain" query is one such example where having one attribute doesn't work unless it is possible to unambiguously split the one attribute into the domain and name.

[jkwatson]

My personal opinion: event domain is probably not necessary, especially for user-generated "business events" (which I honestly think is probably the #1 use-case for the event API)

[tigrannajaryan]

Here is another standard that uses separate fields: https://schema.ocsf.io/classes/http_activity

They use 3 different fields (class_uid, category_uid, activity_id), where class_uid implies the category_uid.

Interestingly then they further compose these 3 into a single type_uid field.