Stabilize complex AnyValue types and related attribute limits (#4794)

Fixes #4710

OTEP #4485 (Extending attributes to support complex values)

## What

Stabilize the complex `AnyValue` attribute value types and the
corresponding attribute limits.
Simplifiy the Logs Data Model to rely on `AnyValue` and Attribute
Collections instead of custom `any` / `map<string, any>` types.

## Why

Per the OTEP-implementing PR
[#4485](#4485)
tht was merged on **2025‑07‑15**, so the 6‑month window ends around
**2026‑01‑15**. This PR is intended to be merged around **2026‑01‑15**,
in line with that requirement.

> Stable exporters will be prohibited from emitting complex attributes
by default on signals other than Logs until at least 6 months after this
OTEP is merged.

OpenTelemetry **Go** and **Java** treat the common package as a **stable
cross‑cutting surface**. They need these `AnyValue` types and limits to
be Stable in the spec before they can add corresponding features to
their APIs, SDKs, and exporters.

## Prototypes

We have **three independent prototypes** that exercised the complex
`AnyValue` attribute types and limits:

- Java: open-telemetry/opentelemetry-java#7814 (
- Python:
open-telemetry/opentelemetry-python#4587
- Go: open-telemetry/opentelemetry-go#6809


In summary, they:

1. Validated that complex attributes can be represented and processed
end‑to‑end using `AnyValue`.
2. Confirmed that the specified attribute limits (length and count) are
acceptable.
3. Demonstrated that existing implementations can adopt complex
attributes without breaking current stable behavior.

## Other

I was thinking about adding something to `spec-compliance-matrix.md`,
but I do not see any obvious place where it could be located. I think we
can tackle it in a separate PR if there would be a demand for it.

EDIT: Tracked under
#4808

Author: pellared

CHANGELOG.md

@@ -49,6 +49,9 @@ release.
 
 ### Common
 
+- Stabilize complex `AnyValue` attribute value types and related attribute limits.
+  ([#4794](https://github.com/open-telemetry/opentelemetry-specification/issues/4794))
+
 ### Supplementary Guidelines
 
 ### OTEPs

specification/common/README.md

@@ -35,10 +35,10 @@ path_base_for_github_subdir:
   (IEEE 754-1985), or signed 64 bit integer,
 - a homogeneous array of primitive type values. A homogeneous array MUST NOT
   contain values of different types.
-- **Status**: [Development](../document-status.md) - a byte array.
-- **Status**: [Development](../document-status.md) - an array of `AnyValue`,
-- **Status**: [Development](../document-status.md) - a [`map<string, AnyValue>`](#mapstring-anyvalue),
-- **Status**: [Development](../document-status.md) - an empty value if supported by the language,
+- a byte array.
+- an array of `AnyValue`,
+- a [`map<string, AnyValue>`](#mapstring-anyvalue),
+- an empty value if supported by the language,
   (e.g. `null`, `undefined` in JavaScript/TypeScript, `None` in Python, `nil` in Go/Ruby, not supported in Erlang, etc.)
 
 Arbitrary deep nesting of values for arrays and maps is allowed (essentially
@@ -70,8 +70,6 @@ both containing an array of strings to represent a mapping
 
 ### map<string, AnyValue>
 
-**Status**: [Development](../document-status.md)
-
 `map<string, AnyValue>` is a map of string keys to `AnyValue` values.
 The keys in the map are unique (duplicate keys are not allowed).
 
@@ -181,22 +179,22 @@ If an SDK provides a way to:
   - if it is a string, if it exceeds that limit (counting any character in it as
     1), SDKs MUST truncate that value, so that its length is at most equal
     to the limit,
-  - **Status**: [Development](../document-status.md) - if it is a byte array,
+  - if it is a byte array,
     if its length exceeds that limit (counting each byte as 1),
     SDKs MUST truncate that value, so that its length is at most equal to the limit,
   - if it is an array of strings, then apply the limit to
     each value within the array separately,
-  - **Status**: [Development](../document-status.md) - if it is an array of [AnyValue](#anyvalue),
+  - if it is an array of [AnyValue](#anyvalue),
     then apply the limit to each element of the array separately (and recursively),
-  - **Status**: [Development](../document-status.md) - if it is a [map](#mapstring-anyvalue),
+  - if it is a [map](#mapstring-anyvalue),
     then apply the limit to each value within the map separately (and recursively),
   - otherwise a value MUST NOT be truncated;
 - set an attribute count limit such that:
   - if adding an attribute to an attribute collection would result
     in exceeding the limit (counting each attribute in the collection as 1),
     the SDK MUST discard that attribute, so that the total number of attributes in
     an attribute collection is at most equal to the limit;
-  - **Status**: [Development](../document-status.md) - the count limit applies only to top-level attributes, not to nested key-value
+  - the count limit applies only to top-level attributes, not to nested key-value
     pairs within [maps](#mapstring-anyvalue);
   - otherwise an attribute MUST NOT be discarded.
 

specification/logs/data-model.md

@@ -15,9 +15,6 @@ weight: 2
 - [Design Notes](#design-notes)
   * [Requirements](#requirements)
   * [Events](#events)
-  * [Definitions Used in this Document](#definitions-used-in-this-document)
-    + [Type `any`](#type-any)
-    + [Type `map`](#type-mapstring-any)
   * [Field Kinds](#field-kinds)
 - [Log and Event Record Definition](#log-and-event-record-definition)
   * [Field: `Timestamp`](#field-timestamp)
@@ -112,43 +109,6 @@ conventions defined for logs SHOULD be formatted as Events. Requirements and det
 Events are intended to be used by OpenTelemetry instrumentation. It is not a
 requirement that all LogRecords are formatted as Events.
 
-### Definitions Used in this Document
-
-In this document we refer to types `any` and `map<string, any>`, defined as
-follows.
-
-#### Type `any`
-
-Value of type `any` can be one of the following:
-
-- A scalar value: string, boolean, signed 64 bit integer, or double precision floating point (IEEE 754-1985)
-
-- A byte array,
-
-- An array (a list) of `any` values,
-
-- A `map<string, any>`,
-
-- [since 1.31.0] An empty value (e.g. `null`).
-
-#### Type `map<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).
-
-Arbitrary deep nesting of values for arrays and maps is allowed (essentially
-allows to represent an equivalent of a JSON object).
-
-The representation of the map is language-dependent.
-
-The implementation MUST by default ensure that the exported maps contain only unique keys.
-
-The implementation MAY have an option to allow exporting maps with duplicate keys
-(e.g. for better performance).
-If such option is provided, it MUST be documented that for many receivers,
-handling of maps with duplicate keys is unpredictable and it is the users'
-responsibility to ensure keys are not duplicate.
-
 ### Field Kinds
 
 This Data Model defines a logical model for a log record (irrespective of the
@@ -157,11 +117,12 @@ fields:
 
 - Named top-level fields of specific type and meaning.
 
-- Fields stored as `map<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
-  semantic conventions for `Resource` and `Attributes` fields and examples in
+- Fields stored as [Attribute Collections](../common/README.md#attribute-collections),
+  whose values are [AnyValue](../common/README.md#anyvalue). 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 semantic conventions for
+  `Resource` and `Attributes` fields and examples in
   [Appendix A](./data-model-appendix.md#appendix-a-example-mappings).
 
 The reasons for having these 2 kinds of fields are:
@@ -173,7 +134,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 in Attribute Collections. 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.
 
@@ -430,7 +391,7 @@ when it is used to represent an unspecified severity.
 
 ### Field: `Body`
 
-Type: [`any`](#type-any) or [AnyValue](../common/README.md#anyvalue).
+Type: [AnyValue](../common/README.md#anyvalue).
 
 Description: A value containing the body of the log record. Can be for example
 a human-readable string message (including multi-line) describing the event in
@@ -465,7 +426,7 @@ they all have the same value of `InstrumentationScope`. This field is optional.
 
 ### Field: `Attributes`
 
-Type: [`map<string, any>`](#type-mapstring-any) or [Attribute Collection](../common/README.md#attribute-collections).
+Type: [Attribute Collection](../common/README.md#attribute-collections).
 
 Description: Additional information about the specific event occurrence. Unlike
 the `Resource` field, which is fixed for a particular source, `Attributes` can