From 1b22ca86143fc37b1afe87fc4471e148881f80ad Mon Sep 17 00:00:00 2001
From: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Date: Mon, 15 Nov 2021 12:21:43 -0500
Subject: [PATCH] Allow omitting LogRecord in favor of build pattern in Logging
 SDKs (#183)

The discussion while implementing the Java SDK revealed that the LogRecord
data type may not be necessary. See here https://github.com/open-telemetry/opentelemetry-java/pull/3759#discussion_r738019425

However, in some other languages LogRecord fits nicely (see the comment about
Python implementation in the same comment thread).

This changes allows implementators of the OTEP to choose the most idiomatic
approach for their language.
---
 text/logs/0150-logging-library-sdk.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/text/logs/0150-logging-library-sdk.md b/text/logs/0150-logging-library-sdk.md
index 6a2e6b667..00a67988b 100644
--- a/text/logs/0150-logging-library-sdk.md
+++ b/text/logs/0150-logging-library-sdk.md
@@ -79,6 +79,12 @@ Methods:
   trace context related fields (TraceId,SpanId,TraceFlags) if applicable before
   making the call. Open Question: do we need to also pass the Baggage so that
   log processors and exporters can use it if they see the need?
+
+  Note: some languages may opt to avoid having a LogRecord data type and instead
+  use a more idiomatic builder pattern to prepare and emit a log record (see
+  e.g.
+  [Java discussion](https://github.com/open-telemetry/opentelemetry-java/pull/3759#discussion_r738019425))
+
 - Flush.
 
 ### LogRecord