docs: fix typos (#310)

Signed-off-by: Sahid Velji <[email protected]>

Author: sahidvelji

specification.json

@@ -59,7 +59,7 @@
         {
             "id": "Requirement 1.1.6",
             "machine_id": "requirement_1_1_6",
-            "content": "The `API` MUST provide a function for creating a `client` which accepts the following options:  - domain (optional): A logical string identifier for binding clients to provider.",
+            "content": "The `API` MUST provide a function for creating a `client` which accepts the following options:  - domain (optional): A logical string identifier for binding a client to a provider.",
             "RFC 2119 keyword": "MUST",
             "children": []
         },
@@ -539,7 +539,7 @@
         {
             "id": "Requirement 3.1.4",
             "machine_id": "requirement_3_1_4",
-            "content": "The evaluation context fields MUST have an unique key.",
+            "content": "The evaluation context fields MUST have a unique key.",
             "RFC 2119 keyword": "MUST",
             "children": []
         },
@@ -991,7 +991,7 @@
         {
             "id": "Requirement 5.2.4",
             "machine_id": "requirement_5_2_4",
-            "content": "The `handler function` MUST accept a `event details` parameter.",
+            "content": "The `handler function` MUST accept an `event details` parameter.",
             "RFC 2119 keyword": "MUST",
             "children": []
         },

specification/glossary.md

@@ -123,7 +123,7 @@ The possible states and transitions of a provider over the course of its usage,
 
 ### Domain
 
-An identifier which logically binds clients with providers, allowing for multiple providers to be used simultaneously within a single application. Domain binding is dynamic; it may change over the course of an application's lifetime (ie: a client associated to the default provider via an unbound domain will be bound to a new provider if a provider is subsequently assigned to that domain).
+An identifier which logically binds clients with providers, allowing for multiple providers to be used simultaneously within a single application. Domain binding is dynamic; it may change over the course of an application's lifetime (i.e.: a client associated with the default provider via an unbound domain will be bound to a new provider if a provider is subsequently assigned to that domain).
 
 ### Integration
 
@@ -139,15 +139,15 @@ An SDK-compliant implementation that stores and returns transaction-specific eva
 
 ### Evaluating Flag Values
 
-The process of retrieving a feature flag value in it's entirety, including:
+The process of retrieving a feature flag value in its entirety, including:
 
 - any effects resulting from hooks
 - resolving a flag value from a configured provider
 - falling back to a supplied default, in the case of abnormal execution
 
 ### Resolving Flag Values
 
-The process of a provider retrieving a feature flag value from it's particular source-of-truth.
+The process of a provider retrieving a feature flag value from its particular source-of-truth.
 
 ### Tracking Event
 

specification/sections/01-flag-evaluation.md

@@ -42,7 +42,7 @@ See [provider](./02-providers.md), [creating clients](#creating-clients) for det
 
 Application authors can await the newly set `provider's` readiness using the `PROVIDER_READY` event.
 Provider instances which are already active (because they have been bound to another `domain` or otherwise) need not be initialized again.
-The `provider's` readiness can state can be determined from its `status` member/accessor.
+The `provider's` readiness state can be determined from its `status` member/accessor.
 
 See [event handlers and initialization](./05-events.md#event-handlers-and-initialization), [provider initialization](./02-providers.md#24-initialization), [domain](../glossary.md#domain) for details.
 
@@ -109,7 +109,7 @@ OpenFeature.getProviderMetadata();
 ```
 
 It's possible to access provider metadata using a `domain`.
-If a provider has not be registered under the requested domain, the default provider metadata is returned.
+If a provider has not been registered under the requested domain, the default provider metadata is returned.
 
 ```typescript
 // example provider accessor
@@ -124,15 +124,15 @@ See [provider](./02-providers.md), [domain](../glossary.md#domain) for details.
 
 > The `API` **MUST** provide a function for creating a `client` which accepts the following options:
 >
-> - domain (optional): A logical string identifier for binding clients to provider.
+> - domain (optional): A logical string identifier for binding a client to a provider.
 
 ```java
 // example client creation and retrieval
 OpenFeature.getClient();
 ```
 
 It's possible to create a client that is associated with a `domain`.
-The client will use a provider in the same `domain` if one exists, otherwise, the default provide is used.
+The client will use a provider in the same `domain` if one exists, otherwise, the default provider is used.
 
 ```java
 // example client creation and retrieval using a domain

specification/sections/03-evaluation-context.md

@@ -39,7 +39,7 @@ see: [structure](../types.md#structure), [datetime](../types.md#datetime)
 
 #### Requirement 3.1.4
 
-> The evaluation context fields **MUST** have an unique key.
+> The evaluation context fields **MUST** have a unique key.
 
 The key uniquely identifies a field in the `evaluation context` and it should be unique across all types to avoid any collision when marshalling the `evaluation context` by the provider.
 
@@ -126,7 +126,7 @@ see: [static-context paradigm](../glossary.md#static-context-paradigm)
 
 > When the global `evaluation context` is set, the `on context changed` function **MUST** run.
 
-The SDK implementation must run the `on context changed` function on all registered provider that use the global `evaluation context` whenever it is mutated.
+The SDK implementation must run the `on context changed` function on all registered providers that use the global `evaluation context` whenever it is mutated.
 
 ##### Conditional Requirement 3.2.4.2
 

specification/sections/05-events.md

@@ -23,7 +23,7 @@ graph
 ```
 
 The `domain` of a provider constitutes a logical scope for events.
-Clients associated to a particular provider through a `domain`, run event handlers only when that provider emits events, or one of its lifecycle functions terminates.
+Clients associated with a particular provider through a `domain` run event handlers only when that provider emits events, or one of its lifecycle functions terminates.
 
 see: [domain](../glossary.md#domain)
 
@@ -33,7 +33,7 @@ see: [domain](../glossary.md#domain)
 
 > The `provider` **MAY** define a mechanism for signaling the occurrence of one of a set of events, including `PROVIDER_READY`, `PROVIDER_ERROR`, `PROVIDER_CONFIGURATION_CHANGED` and `PROVIDER_STALE`, with a `provider event details` payload. 
 
-Providers cannot emit `PROVIDER_CONTEXT_CHANGED` or `PROVIDER_RECONCILING` event.
+Providers cannot emit `PROVIDER_CONTEXT_CHANGED` or `PROVIDER_RECONCILING` events.
 These are emitted only by the SDK during context reconciliation.
 
 If available, native event-emitter or observable/observer language constructs can be used.
@@ -112,7 +112,7 @@ See [setting a provider](./01-flag-evaluation.md#setting-a-provider), [creating
 
 #### Requirement 5.2.4
 
-> The `handler function` **MUST** accept a `event details` parameter.
+> The `handler function` **MUST** accept an `event details` parameter.
 
 see: [`event details`](../types.md#event-details)
 
@@ -164,7 +164,7 @@ See [provider initialization](./02-providers.md#24-initialization) and [setting
 
 Handlers may be attached at any point in the application lifecycle.
 Handlers should run immediately if the provider is already in the associated state.
-For instance, _application authors_ may attach readiness handlers to be confident that system is ready to evaluate flags.
+For instance, _application authors_ may attach readiness handlers to be confident that the system is ready to evaluate flags.
 If such handlers are attached after the provider underlying the client has already been initialized, they should run immediately.
 
 See [provider initialization](./02-providers.md#24-initialization), [setting a provider](./01-flag-evaluation.md#setting-a-provider).
@@ -233,7 +233,7 @@ see: [provider event types](../types.md#provider-events), [provider events](#51-
 > If the provider emits an event, the value of the client's `provider status` **MUST** be updated accordingly.
 
 Some providers may emit events spontaneously, based on changes in their internal state (connections, caches, etc).
-The SDK must update it's internal representation of the provider's state accordingly:
+The SDK must update its internal representation of the provider's state accordingly:
 
 | Event                            | Associated Status                                       |
 | -------------------------------- | ------------------------------------------------------- |
@@ -246,4 +246,4 @@ The SDK must update it's internal representation of the provider's state accordi
 
 \* If the `error code` associated with the error indicates `PROVIDER_FATAL`, the state is set to `FATAL`
 
-see: [provider lifecycle management](01-flag-evaluation.md#17-provider-lifecycle-management), [provider status](../types.md#provider-status) [error codes](../types.md#error-code)
+see: [provider lifecycle management](01-flag-evaluation.md#17-provider-lifecycle-management), [provider status](../types.md#provider-status) [error codes](../types.md#error-code)

specification/types.md

@@ -44,7 +44,7 @@ A structure representing the result of the [flag evaluation process](./glossary.
 
 > [!NOTE]  
 > Some type systems feature useful constraints that can enhance the ergonomics of the `evaluation details` structure.
-> For example, in the case of an unsuccessful evaluation, `error code`, `reason`, and `error message` will be set, and variant will not.
+> For example, in the case of an unsuccessful evaluation, `error code`, `reason`, and `error message` will be set, and `variant` will not.
 > If the type system of the implementation supports the expression of such constraints, consider defining them.
 
 ### Resolution Details
@@ -68,7 +68,7 @@ A set of pre-defined reasons is enumerated below:
 | DEFAULT         | The resolved value fell back to a pre-configured value (no dynamic evaluation occurred or dynamic evaluation yielded no result). |
 | TARGETING_MATCH | The resolved value was the result of a dynamic evaluation, such as a rule or specific user-targeting.                            |
 | SPLIT           | The resolved value was the result of pseudorandom assignment.                                                                    |
-| CACHED          | The resolved value was retrieved from cache.                                                                                     |
+| CACHED          | The resolved value was retrieved from a cache.                                                                                     |
 | DISABLED        | The resolved value was the result of the flag being disabled in the management system.                                           |
 | UNKNOWN         | The reason for the resolved value could not be determined.                                                                       |
 | STALE           | The resolved value is non-authoritative or possibly out of date                                                                  |