Merge event's domain and name (#3749)

Fixes #2994

## Changes

Merging the `domain` and `name` fields for events and modifying language
to refer to the first part of the name as `namespace`

CHANGELOG.md

@@ -23,6 +23,8 @@ release.
 
 - Add definition for standard output log record exporter.
  ([#3741](https:/open-telemetry/opentelemetry-specification/pull/3741))
+- BREAKING: Change `event.name` definition to include `namespace` and removed `event.domain` from log event attributes.
+ ([#3749](https:/open-telemetry/opentelemetry-specification/pull/3749))
 
 ### Resource
 

specification/logs/event-api.md

@@ -30,11 +30,11 @@ From OpenTelemetry's perspective LogRecords and Events are both represented
 using the same [data model](./data-model.md).
 
 However, OpenTelemetry does recognize a subtle semantic difference between
-LogRecords and Events: Events are LogRecords which have a `name` and `domain`.
-Within a particular `domain`, the `name` uniquely defines a particular class or
-type of event. Events with the same `domain` / `name` follow the same schema
-which assists in analysis in observability platforms. Events are described in
-more detail in the [semantic conventions](https:/open-telemetry/semantic-conventions/blob/main/docs/general/events.md).
+LogRecords and Events: Events are LogRecords which have a `name` which uniquely
+defines a particular class or type of event. All events with the same `name`
+follow the same schema which assists in analysis in observability platforms.
+Events are described in more detail in the
+[semantic conventions](https:/open-telemetry/semantic-conventions/blob/main/docs/general/events.md).
 
 While the logging space has a diverse legacy with many existing logging
 libraries in different languages, there is not ubiquitous alignment with
@@ -65,8 +65,6 @@ on `EventLogger`.
 
 * `logger` - the delegate [Logger](./bridge-api.md#logger) used to emit `Events`
  as `LogRecord`s.
-* `event_domain` - the domain of emitted events, used to set the `event.domain`
- attribute.
 
 #### Emit Event
 
@@ -80,15 +78,13 @@ This function MAY be named `logEvent`.
  attribute with the key `event.name`. Care MUST be taken by the implementation
  to not override or delete this attribute while the Event is emitted to
  preserve its identity.
-* `logRecord` - the [LogRecord](./data-model.md#log-and-event-record-definition) representing the Event.
+* `logRecord` - the [LogRecord](./data-model.md#log-and-event-record-definition) representing
+ the Event.
 
 **Implementation Requirements:**
 
 The implementation MUST [emit](./bridge-api.md#emit-a-logrecord) the `logRecord` to
 the `logger` specified when [creating the EventLogger](#create-eventlogger)
 after making the following changes:
 
-* The `event_domain` specified
- when [creating the EventLogger](#create-eventlogger) MUST be set as
- the `event.domain` attribute on the `logRecord`.
 * The `event_name` MUST be set as the `event.name` attribute on the `logRecord`.

specification/versioning-and-stability.md

@@ -212,7 +212,6 @@ Semantic Conventions defines the set of fields in the OTLP data model:
  - For log records that are [Log Events](logs/event-api.md)
  - The following data provided to [emit event](logs/event-api.md#emit-event):
  - The event name (the value of the `event.name` attribute)
- - The event domain (the value of the `event.domain` attribute)
 
 Things not listed in the above are not expected to remain stable via semantic
 convention and are allowed (or expected) to change. A few examples: