Merging events domain and name

CHANGELOG.md

@@ -18,6 +18,10 @@ release.
 - Rename metrics `jvm.memory.usage` to `jvm.memory.used` and `jvm.memory.usage_after_last_gc`
   to `jvm.memory.used_after_last_gc`
   ([#536](https://github.com/open-telemetry/semantic-conventions/pull/536))
+- BREAKING: Remove `event.domain` from log event attributes.
+  ([#473](https://github.com/open-telemetry/semantic-conventions/pull/473))
+- BREAKING: Change `event.name` definition to include `namespace`.
+  ([#473](https://github.com/open-telemetry/semantic-conventions/pull/473))
 
 ### Features
 

docs/general/events.md

@@ -17,20 +17,10 @@ The following semantic conventions for events are defined:
 
 ## General event attributes
 
-Events are recorded as LogRecords that are shaped
-in a special way: Event LogRecords have the attributes `event.domain`
-and `event.name` (and possibly other LogRecord attributes).
-
-The `event.domain` attribute is used to logically separate events from different
-systems. For example, to record Events from browser apps, mobile apps and
-Kubernetes, we could use `browser`, `device` and `k8s` as the domain for their
-Events. This provides a clean separation of semantics for events in each of the
-domains.
-
-Within a particular domain, the `event.name` attribute identifies the event.
-Events with same domain and name are structurally similar to one another. For
-example, some domains could have well-defined schema for their events based on
-event names.
+Events are recorded as LogRecords that are shaped in a special way: Event
+LogRecords have the attribute `event.name` that uniquely identifies the event.
+Events with same `event.name` are structurally similar to one another. Events
+may also have other LogRecord attributes.
 
 When recording events from an existing system as OpenTelemetry Events, it is
 possible that the existing system does not have the equivalent of a name or
@@ -43,18 +33,12 @@ that identify the class of Events but not the instance of the Event.
 <!-- semconv event -->
 | Attribute  | Type | Description  | Examples  | Requirement Level |
 |---|---|---|---|---|
-| `event.domain` | string | The domain identifies the business context for the events. [1] | `browser` | Required |
-| `event.name` | string | The name identifies the event. | `click`; `exception` | Required |
-
-**[1]:** Events across different domains may have same `event.name`, yet be unrelated events.
-
-`event.domain` has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.
+| `event.name` | string | Identifies the class / type of event. | `browser.mouse.click`; `device.app.lifecycle` | Required |
 
-| Value  | Description |
-|---|---|
-| `browser` | Events from browser apps |
-| `device` | Events from mobile apps |
-| `k8s` | Events from Kubernetes |
+Event names are subject to the same rules as [attribute names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.26.0/specification/common/attribute-naming.md).
+Notably, event names are namespaced to avoid collisions and provide a clean
+separation of semantics for events in separate domains like browser, mobile, and
+kubernetes.
 <!-- endsemconv -->
 
 [DocumentStatus]: https://github.com/open-telemetry/opentelemetry-specification/tree/v1.26.0/specification/document-status.md

docs/mobile/events.md

@@ -2,8 +2,9 @@
 
 **Status**: [Experimental][DocumentStatus]
 
-This document defines semantic conventions for instrumentations that emit events on mobile platforms.
-All mobile events MUST set `event.domain` as `device`.
+This document defines semantic conventions for instrumentations that emit
+events on mobile platforms. All mobile events MUST use a namespace of
+`device` in the `event.name` property.
 
 <!-- toc -->
 
@@ -15,19 +16,23 @@ All mobile events MUST set `event.domain` as `device`.
 
 ## Lifecycle instrumentation
 
-This section defines how to apply semantic conventions when instrumenting application lifecycle.
-This event is meant to be used in conjunction with `os.name` [resource semantic convention](/docs/resource/os.md) to identify the mobile operating system (e.g. Android, iOS).
+This section defines how to apply semantic conventions when instrumenting
+application lifecycle. This event is meant to be used in conjunction with
+`os.name` [resource semantic convention](/docs/resource/os.md) to identify the
+mobile operating system (e.g. Android, iOS).
 
 ### iOS
 
 <!-- semconv ios.lifecycle.events -->
-The event name MUST be `app.lifecycle`.
+The `event.name` MUST be `device.app.lifecycle`.
 
 | Attribute  | Type | Description  | Examples  | Requirement Level |
 |---|---|---|---|---|
 | `ios.state` | string | This attribute represents the state the application has transitioned into at the occurrence of the event. [1] | `active` | Required |
 
-**[1]:** The iOS lifecycle states are defined in the [UIApplicationDelegate documentation](https://developer.apple.com/documentation/uikit/uiapplicationdelegate#1656902), and from which the `OS terminology` column values are derived.
+**[1]:** The iOS lifecycle states are defined in the
+[UIApplicationDelegate documentation](https://developer.apple.com/documentation/uikit/uiapplicationdelegate#1656902),
+and from which the `OS terminology` column values are derived.
 
 `ios.state` MUST be one of the following:
 
@@ -43,13 +48,15 @@ The event name MUST be `app.lifecycle`.
 ### Android
 
 <!-- semconv android.lifecycle.events -->
-The event name MUST be `app.lifecycle`.
+The `event.name` MUST be `device.app.lifecycle`.
 
 | Attribute  | Type | Description  | Examples  | Requirement Level |
 |---|---|---|---|---|
 | `android.state` | string | This attribute represents the state the application has transitioned into at the occurrence of the event. [1] | `created` | Required |
 
-**[1]:** The Android lifecycle states are defined in [Activity lifecycle callbacks](https://developer.android.com/guide/components/activities/activity-lifecycle#lc), and from which the `OS identifiers` are derived.
+**[1]:** The Android lifecycle states are defined in
+[Activity lifecycle callbacks](https://developer.android.com/guide/components/activities/activity-lifecycle#lc),
+and from which the `OS identifiers` are derived.
 
 `android.state` MUST be one of the following:
 

model/logs/events.yaml

@@ -9,24 +9,7 @@ groups:
         type: string
         requirement_level: required
         brief: >
-          The name identifies the event.
-        examples: ['click', 'exception']
-      - id: domain
-        brief: >
-          The domain identifies the business context for the events.
-        type:
-          allow_custom_values: true
-          members:
-            - id: browser
-              value: 'browser'
-              brief: 'Events from browser apps'
-            - id: device
-              value: 'device'
-              brief: 'Events from mobile apps'
-            - id: k8s
-              value: 'k8s'
-              brief: 'Events from Kubernetes'
-        requirement_level: required
-        note: >
-          Events across different domains may have same `event.name`, yet be
-          unrelated events.
+          The name identifies the event and includes a prefixed namespace. The namespace
+          and name are separated by a period. Events across different namespaces may have
+          the same name, yet be unrelated events.
+        examples: ['browser.pointer.click', 'device.exception']