Minor fixes of typos in trace/{sdk,api}.md (#4216)

specification/trace/api.md

@@ -53,7 +53,7 @@ linkTitle: API
 
 </details>
 
-The Tracing API consist of these main components:
+The Tracing API consists of these main components:
 
 - [`TracerProvider`](#tracerprovider) is the entry point of the API.
   It provides access to `Tracer`s.
@@ -99,7 +99,7 @@ Notwithstanding any global `TracerProvider`, some applications may want to or
 have to use multiple `TracerProvider` instances,
 e.g. to have different configuration (like `SpanProcessor`s) for each
 (and consequently for the `Tracer`s obtained from them),
-or because its easier with dependency injection frameworks.
+or because it's easier with dependency injection frameworks.
 Thus, implementations of `TracerProvider` SHOULD allow creating an arbitrary
 number of `TracerProvider` instances.
 
@@ -753,7 +753,7 @@ This functionality MUST be fully implemented in the API, and SHOULD NOT be overr
 parent/child relationships or span links. `SpanKind` describes two independent
 properties that benefit tracing systems during analysis:
 
-1. Whether span represents an outgoing call to a remote service (`CLIENT` and
+1. Whether a span represents an outgoing call to a remote service (`CLIENT` and
    `PRODUCER` spans) or a processing of an incoming request initiated externally (`SERVER`
    and `CONSUMER` spans).
 2. Whether a Span represents a request/response operation (`CLIENT` and `SERVER`
@@ -775,7 +775,7 @@ specific technologies should document kind for each span they define.
 
 For instance, [Database Client Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-spans.md)
 recommend using `CLIENT` span kind to describes database calls.
-If the database client communicate to the server over HTTP, the HTTP
+If the database client communicates to the server over HTTP, the HTTP
 instrumentation (when enabled) creates nested `CLIENT` spans to track individual
 HTTP calls performed in the scope of logical database `CLIENT` operation.
 

specification/trace/sdk.md

@@ -178,7 +178,7 @@ It consists of the following parameters:
   i.e. `Tracer`s are enabled by default).
 
   If a `Tracer` is disabled, it MUST behave equivalently
-  to [No-op Tracer](./api.md#behavior-of-the-api-in-the-absence-of-an-installed-sdk).
+  to a [No-op Tracer](./api.md#behavior-of-the-api-in-the-absence-of-an-installed-sdk).
 
   The value of `disabled` MUST be used to resolve whether a `Tracer`
   is [Enabled](./api.md#enabled). If `disabled` is `true`, `Enabled`
@@ -211,7 +211,7 @@ Thus, the SDK specification defines sets of possible requirements for
   [deprecated since 1.10.0] having the same name and version values as the
   `InstrumentationScope`.
 
-  A function receiving this as argument MUST must be able to reliably determine
+  A function receiving this as argument MUST be able to reliably determine
   whether the Span has ended
   (some languages might implement this by having an end timestamp of `null`,
   others might have an explicit `hasEnded` boolean).
@@ -253,11 +253,11 @@ the backend.
 
 Sampling may be implemented on different stages of a trace collection. The
 earliest sampling could happen before the trace is actually created, and the
-latest sampling could happen on the Collector which is out of process.
+latest sampling could happen on the Collector, which is out of process.
 
 The OpenTelemetry API has two properties responsible for the data collection:
 
-* `IsRecording` field of a `Span`. If `false` the current `Span` discards all
+* `IsRecording` field of a `Span`. If `false`, the current `Span` discards all
   tracing data (attributes, events, status, etc.). Users can use this property
   to determine if collecting expensive trace data can be avoided. [Span
   Processor](#span-processor) MUST receive only those spans which have this