From 7aa17936048a167239936fe8ef62e2767d2ccf5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Robert=20Paj=C4=85k?= Date: Tue, 6 Feb 2024 20:28:37 +0100 Subject: [PATCH] Remove confusing description from Body field in Logs Data Model (#3827) Related to https://github.com/open-telemetry/opentelemetry-specification/pull/3814 ## Changes Remove confusing description from Body field in Logs Data Model. The description makes the specification not clear as the language authors may understand that the Bridge API must only accept Body as `string`. Additionally, I do not think that the following recommendation is actually a good one: > First-party Applications SHOULD use a string message --------- Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com> Co-authored-by: Trask Stalnaker Co-authored-by: Cijo Thomas --- CHANGELOG.md | 2 ++ specification/logs/data-model.md | 18 ++++++++---------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index e15e1a3c8d5..76527c73380 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -22,6 +22,8 @@ release. - Fix `Resource` field type in Logs Data Model. ([#3826](https://github.com/open-telemetry/opentelemetry-specification/pull/3826)) +- Remove confusing description from `Body` field in Logs Data Model to make it clear the Bridge API must support a structured body. + ([#3827](https://github.com/open-telemetry/opentelemetry-specification/pull/3827)) - Deconstruct number scalar type to double and signed integer. ([#3854](https://github.com/open-telemetry/opentelemetry-specification/pull/3854)) diff --git a/specification/logs/data-model.md b/specification/logs/data-model.md index 1173b51039b..4da9becbddc 100644 --- a/specification/logs/data-model.md +++ b/specification/logs/data-model.md @@ -402,16 +402,14 @@ corresponding short names). ### Field: `Body` -Type: any. - -Description: A value containing the body of the log record (see the description -of `any` type above). Can be for example a human-readable string message -(including multi-line) describing the event in a free form or it can be a -structured data composed of arrays and maps of other values. First-party -Applications SHOULD use a string message. However, a structured body SHOULD be -used to preserve the semantics of structured logs emitted by Third-party -Applications. Can vary for each occurrence of the event coming from the same -source. This field is optional. +Type: [`any`](#type-any). + +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 +a free form or it can be a structured data composed of arrays and maps of other +values. Body MUST support [`any` type](#type-any) to preserve the semantics of +structured logs emitted by the applications. Can vary for each occurrence of the +event coming from the same source. This field is optional. ### Field: `Resource`