Change map to key-value pair collection in Logs Data Model

CHANGELOG.md

@@ -30,6 +30,8 @@ release.
   ([#3853](https://github.com/open-telemetry/opentelemetry-specification/pull/3853))
 - Mark standard output log record exporter as stable.
   ([#3922](https://github.com/open-telemetry/opentelemetry-specification/pull/3922))
+- Change map to key-value pair collection in Logs Data Model.
+  ([#3938](https://github.com/open-telemetry/opentelemetry-specification/pull/3938))
 
 ### Resource
 

specification/logs/data-model.md

@@ -11,7 +11,7 @@
   * [Requirements](#requirements)
   * [Definitions Used in this Document](#definitions-used-in-this-document)
     + [Type `any`](#type-any)
-    + [Type `map`](#type-mapstring-any)
+    + [Type `[]keyval`](#type-keyvalstring-any)
   * [Field Kinds](#field-kinds)
 - [Log and Event Record Definition](#log-and-event-record-definition)
   * [Field: `Timestamp`](#field-timestamp)
@@ -99,7 +99,7 @@ The Data Model aims to successfully represent 3 sorts of logs and events:
 
 ### Definitions Used in this Document
 
-In this document we refer to types `any` and `map<string, any>`, defined as
+In this document we refer to types `any` and `[]keyval<string, any>`, defined as
 follows.
 
 #### Type `any`
@@ -112,18 +112,22 @@ Value of type `any` can be one of the following:
 
 - An array (a list) of `any` values,
 
-- A `map<string, any>`,
+- A `[]keyval<string, any>`,
 
 - [since 1.31.0] An empty value (e.g. `null`).
 
-#### Type `map<string, any>`
+#### Type `[]keyval<string, any>`
 
-Value of type `map<string, any>` is a map of string keys to `any` values. The
-keys in the map are unique (duplicate keys are not allowed). The representation
-of the map is language-dependent.
+Value of type `[]keyval<string, any>` is a collection of key-value pairs with
+string keys and [`any`](#type-any) values.
 
-Arbitrary deep nesting of values for arrays and maps is allowed (essentially
-allows to represent an equivalent of a JSON object).
+Arbitrary deep nesting of values for arrays and key-value collections MUST be
+allowed (essentially allows to represent an equivalent of a JSON object).
+
+The type representation is language-dependent.
+It is implementation-specific whether the collection can contain duplicated keys.
+If the implementation allows having duplicates, then some exporters (e.g. OTLP)
+may require deduplication (removing pairs so that none of them have the same key).
 
 ### Field Kinds
 
@@ -133,7 +137,7 @@ fields:
 
 - Named top-level fields of specific type and meaning.
 
-- Fields stored as `map<string, any>`, which can contain arbitrary values of
+- Fields stored as `[]keyval<string, any>`, which can contain arbitrary values of
   different types. The keys and values for well-known fields follow semantic
   conventions for key names and possible values that allow all parties that work
   with the field to have the same interpretation of the data. See references to
@@ -149,7 +153,7 @@ The reasons for having these 2 kinds of fields are:
 - Ability to enforce types of named fields, which is very useful for compiled
   languages with type checks.
 
-- Flexibility to represent less frequent data as `map<string, any>`. This
+- Flexibility to represent less frequent data as `[]keyval<string, any>`. This
   includes well-known data that has standardized semantics as well as arbitrary
   custom data that the application may want to include in the logs.
 
@@ -444,7 +448,7 @@ is optional.
 
 ### Field: `Attributes`
 
-Type: [`map<string, any>`](#type-mapstring-any).
+Type: [`[]keyval<string, any>`](#type-keyvalstring-any).
 
 Description: Additional information about the specific event occurrence. Unlike
 the `Resource` field, which is fixed for a particular source, `Attributes` can