change generic to other

text/0265-event-vision.md

@@ -18,23 +18,23 @@ Since OpenTelemetry Events are a type of OpenTelemetry Log, they share the same
 
 OpenTelemetry should provide a (user-facing) Log API that includes the capability to emit OpenTelemetry Events.
 
-### Interoperability with Generic Logging Libraries
+### Interoperability with other logging libraries
 
-It should be possible to send OpenTelemetry Logs from the OpenTelemetry Log API to a generic logging library (e.g., Log4j).
+It should be possible to send OpenTelemetry Logs from the OpenTelemetry Log API to other logging libraries (e.g., Log4j).
 This allows users to integrate OpenTelemetry Logs into an existing (non-OpenTelemetry) log stream.
 
 It should also be possible to bypass the OpenTelemetry Log API entirely and emit OpenTelemetry Logs (including Events)
 directly via existing language-specific logging libraries, if that library has the capability to do so.
 
 OpenTelemetry will recommend that
 [instrumentation libraries](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-library)
-use the OpenTelemetry Log API to emit OpenTelemetry Events rather than using a generic logging library. This recommendation aims to provide users with a simple and consistent
+use the OpenTelemetry Log API to emit OpenTelemetry Events rather than using other logging libraries to emit OpenTelemetry Events. This recommendation aims to provide users with a simple and consistent
 onboarding experience that avoids mixing approaches.
 
 OpenTelemetry will also recommend that application developers use the OpenTelemetry Log API to emit OpenTelemetry Events instead of using a generic
 logging library, as this helps prevent accidentally emitting logs that lack an event name or are unstructured.
 
-Recommending the OpenTelemetry Log API for emitting OpenTelemetry Events, rather than using a generic logging library, contributes to a clearer overall
+Recommending the OpenTelemetry Log API for emitting OpenTelemetry Events, rather than using other logging libraries, contributes to a clearer overall
 OpenTelemetry API story. This ensures a unified approach with first-class user-facing APIs for traces, metrics, and events,
 all suitable for direct use in native instrumentation.
 
@@ -53,7 +53,7 @@ This refers to the existing OpenTelemetry Log SDK.
 
 * How to support routing logs from the Log API to a language-specific logging library
   while simultaneously routing logs from the language-specific logging library to an OpenTelemetry Logging Exporter?
-* How do log bodies interoperate with generic logging libraries?
+* How do log bodies interoperate with other logging libraries?
   OpenTelemetry Logs have two places to put structure (attributes and body), while often logging libraries only have one layer of structure,
   which makes it non-obvious how to do a two-way mapping between them in this case.
 * How do event bodies interoperate with Span Events?