Merge branch 'main' into codeboten/fix-4215

.gitignore

@@ -30,4 +30,7 @@ node_modules/
 package-lock.json
 
 # Visual Studio Code
-.vscode
+.vscode
+
+# Visual Studio
+.vs

CHANGELOG.md

@@ -38,6 +38,9 @@ release.
   ([#4221](https://github.com/open-telemetry/opentelemetry-specification/pull/4221))
 - Make all fields as identifying for Logger. Previously attributes were omitted from being identifying.
   ([#4161](https://github.com/open-telemetry/opentelemetry-specification/pull/4161))
+- Introduce initial placeholder for the new user-facing Logs API, adding references
+  to existing API's informing of the coming changes while the definition is defined.
+  ([#4236](https://github.com/open-telemetry/opentelemetry-specification/pull/4236))
 
 ### Events
 
@@ -55,6 +58,8 @@ release.
 
 - Define equality for attributes and collection of attributes.
   ([#4161](https://github.com/open-telemetry/opentelemetry-specification/pull/4161))
+- Update Instrumentation Scope glossary entry with correct identifying fields
+  ([#4244](https://github.com/open-telemetry/opentelemetry-specification/pull/4244))
 
 ### Supplementary Guidelines
 

specification/glossary.md

@@ -172,16 +172,20 @@ reasonable instrumentation scope. The most common approach is to use the
 scopes are also common, e.g. a module, a package, or a class can be chosen as
 the instrumentation scope.
 
-If the unit of code has a version then the instrumentation scope is defined by
-the (name,version) pair otherwise the version is omitted and only the name is
-used. The name or (name,version) pair uniquely identify the logical unit of the
-code that emits the telemetry. A typical approach to ensure uniqueness is to use
-fully qualified name of the emitting code (e.g. fully qualified library name or
-fully qualified class name).
+The instrumentation scope is defined by the
+(name,version,schema_url,attributes) tuple where version, schema_url, and
+attributes are optional. This tuple uniquely identifies the logical unit of the
+code that emits the telemetry. A typical approach to ensure uniqueness is to
+use the fully qualified name of the emitting code (e.g. fully qualified library
+name or fully qualified class name).
 
 The instrumentation scope is used to obtain a
 [Tracer, Meter, or Logger](#tracer-name--meter-name--logger-name).
 
+The instrumentation scope's optional Schema URL identifies the [Telemetry
+Schema](schemas/README.md) that the instrumentation's emitted
+telemetry conforms to.
+
 The instrumentation scope may have zero or more additional attributes that provide
 additional information about the scope. For example for a scope that specifies an
 instrumentation library an additional attribute may be recorded to denote the URL of the

specification/logs/bridge-api.md

@@ -16,6 +16,7 @@
   * [Logger operations](#logger-operations)
     + [Emit a LogRecord](#emit-a-logrecord)
     + [Enabled](#enabled)
+- [Logs Instrumentation API](#logs-instrumentation-api)
 - [Optional and required parameters](#optional-and-required-parameters)
 - [Concurrency requirements](#concurrency-requirements)
 - [Artifact Naming](#artifact-naming)
@@ -145,6 +146,13 @@ SHOULD be documented that instrumentation authors needs to call this API each
 time they [emit a LogRecord](#emit-a-logrecord) to ensure they have the most
 up-to-date response.
 
+## Logs Instrumentation API
+
+**Status**: [Development](../document-status.md)
+
+This set of API functions will provide the capabilities needed to emit a
+`LogRecord` as is currently provided by [Events API](./event-api.md).
+
 ## Optional and required parameters
 
 The operations defined include various parameters, some of which are marked

specification/logs/event-api.md

@@ -9,6 +9,7 @@
 
 <!-- toc -->
 
+- [Logs Instrumentation API Development](#logs-instrumentation-api-development)
 - [Event Data model](#event-data-model)
 - [Event API use cases](#event-api-use-cases)
 - [EventLoggerProvider](#eventloggerprovider)
@@ -30,6 +31,15 @@ The Event API consists of these main components:
   provides access to `EventLogger`s.
 * [EventLogger](#eventlogger) is the component responsible for emitting events.
 
+## Logs Instrumentation API Development
+
+> [!NOTE]
+> We are currently in the process of defining a new [Logs Instrumentation API](./bridge-api.md#logs-instrumentation-api).
+
+The intent is that this Logs Instrumentation API will incorporate the current functionality of this existing Events API and once it is defined and implemented, the Events API usage will be migrated, deprecated, renamed and eventually removed.
+
+No further work is scheduled for the current Events API definition at this time.
+
 ## Event Data model
 
 Wikipedia’s [definition of log file](https://en.wikipedia.org/wiki/Log_file):

specification/logs/event-sdk.md

@@ -9,6 +9,7 @@
 
 <!-- toc -->
 
+- [Logs Instrumentation API Development](#logs-instrumentation-api-development)
 - [Overview](#overview)
 - [EventLoggerProvider](#eventloggerprovider)
   * [EventLoggerProvider Creation](#eventloggerprovider-creation)
@@ -29,6 +30,15 @@ API that provides users with this functionally.
 
 All implementations of the OpenTelemetry API MUST provide an SDK.
 
+## Logs Instrumentation API Development
+
+> [!NOTE]
+> We are currently in the process of defining a new [Logs Instrumentation API](./bridge-api.md#logs-instrumentation-api).
+
+The intent is that Logs SDK will incorporate the current functionality of this existing Events SDK and once it is defined and implemented, the Events SDK usage will be migrated, deprecated, renamed and eventually removed.
+
+No further work is scheduled for the current Event SDK at this time.
+
 ## Overview
 
 From OpenTelemetry's perspective LogRecords and Events are both represented

specification/logs/sdk.md

@@ -34,6 +34,7 @@
     + [Export](#export)
     + [ForceFlush](#forceflush-2)
     + [Shutdown](#shutdown-1)
+- [Logs Instrumentation API](#logs-instrumentation-api)
 
 <!-- tocstop -->
 
@@ -538,4 +539,9 @@ return a Failure result.
 and the destination is unavailable). [OpenTelemetry SDK](../overview.md#sdk)
 authors MAY decide if they want to make the shutdown timeout configurable.
 
+## Logs Instrumentation API
+
+> [!NOTE]
+> We are currently in the process of defining a new [Logs Instrumentation API](./bridge-api.md#logs-instrumentation-api).
+
 - [OTEP0150 Logging Library SDK Prototype Specification](https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md)