Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: fix site deploy #220

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions specification/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,11 @@ sidebar_position: 0

- [Glossary](./glossary.md)
- [Types](./types.md)
- [Evaluation API](./sections/01-flag-evaluation.md)
- [Providers](./sections//02-providers.md)
- [Evaluation Context](./sections/03-evaluation-context.md)
- [Hooks](./sections/04-hooks.md)
- [Events](./sections/05-events.md)
- [Evaluation API](./sections/flag-evaluation.md)
- [Providers](./sections//providers.md)
- [Evaluation Context](./sections/evaluation-context.md)
- [Hooks](./sections/hooks.md)
- [Events](./sections/events.md)
- [Appendix A: Included Utilities](./appendix-a-included-utilities.md)
- [Appendix B: Gherkin Suites](./appendix-b-gherkin-suites.md)

Expand Down
2 changes: 1 addition & 1 deletion specification/appendix-b-gherkin-suites.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,4 @@ These tests can be used to validate the behavior of an OpenFeature implementatio

## Evaluation Feature

The [evaluation feature](./assets/gherkin/evaluation.feature) contains tests for the basic functionality of the [Evaluation API](./sections/01-flag-evaluation.md).
The [evaluation feature](./assets/gherkin/evaluation.feature) contains tests for the basic functionality of the [Evaluation API](./sections/flag-evaluation.md).
4 changes: 2 additions & 2 deletions specification/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ A developer who is setting up or configuring an application or service to use th

### Provider Author

The maintainer of an API-compliant [provider](./sections/02-providers.md) which implements the necessary interfaces required for flag evaluation.
The maintainer of an API-compliant [provider](./sections/providers.md) which implements the necessary interfaces required for flag evaluation.

### Integration Author

Expand Down Expand Up @@ -105,7 +105,7 @@ A source-of-truth for flag values and rules. Flag management systems may include

### Provider

An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the [Evaluation API](./sections/01-flag-evaluation.md#13-flag-evaluation) as an abstraction for the system in question.
An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the [Evaluation API](./sections/flag-evaluation.md#13-flag-evaluation) as an abstraction for the system in question.

Providers can be used in two ways. Client-specific providers are active for specific clients, based on their name. The default provider is used if there are no client-specific mappings setup.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ toc_max_heading_level: 4

The `evaluation context` provides ambient information for the purposes of flag evaluation. Contextual data may be used as the basis for targeting, including rule-based evaluation, overrides for specific subjects, or fractional flag evaluation.

The context might contain information about the end-user, the application, the host, or any other ambient data that might be useful in flag evaluation. For example, a flag system might define rules that return a specific value based on the user's email address, locale, or the time of day. The context provides this information. The context can be optionally provided at evaluation, and mutated in [before hooks](./04-hooks.md).
The context might contain information about the end-user, the application, the host, or any other ambient data that might be useful in flag evaluation. For example, a flag system might define rules that return a specific value based on the user's email address, locale, or the time of day. The context provides this information. The context can be optionally provided at evaluation, and mutated in [before hooks](./hooks.md).

### 3.1 Fields

Expand Down Expand Up @@ -81,7 +81,7 @@ In the static-context paradigm, context is global. The client and invocation can

> Evaluation context **MUST** be merged in the order: API (global; lowest precedence) -> client -> invocation -> before hooks (highest precedence), with duplicate values being overwritten.

Any fields defined in the client `evaluation context` will overwrite duplicate fields defined globally, and fields defined in the invocation `evaluation context` will overwrite duplicate fields defined globally or on the client. Any resulting `evaluation context` from a [before hook](./04-hooks.md#requirement-434) will overwrite duplicate fields defined globally, on the client, or in the invocation.
Any fields defined in the client `evaluation context` will overwrite duplicate fields defined globally, and fields defined in the invocation `evaluation context` will overwrite duplicate fields defined globally or on the client. Any resulting `evaluation context` from a [before hook](./hooks.md#requirement-434) will overwrite duplicate fields defined globally, on the client, or in the invocation.

```mermaid
flowchart LR
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ see: [provider event types](./../types.md#provider-events) and [event handlers](

Providers bound to a named client constitute their own "events scope".

see: [setting a provider](./01-flag-evaluation.md#setting-a-provider)
see: [setting a provider](./flag-evaluation.md#setting-a-provider)

#### Requirement 5.1.4

Expand Down Expand Up @@ -85,7 +85,7 @@ see: [provider events](#51-provider-events), [`provider event types`](../types.m
The `provider name` indicates the provider from which the event originated.
This is especially relevant for global event handlers used for general monitoring, such as alerting on provider errors.

See [setting a provider](./01-flag-evaluation.md#setting-a-provider), [creating clients](./01-flag-evaluation.md#creating-clients).
See [setting a provider](./flag-evaluation.md#setting-a-provider), [creating clients](./flag-evaluation.md#creating-clients).

#### Requirement 5.2.4

Expand Down Expand Up @@ -122,7 +122,7 @@ _Application authors_ and _application integrators_ use these events to wait for

> If the provider's `initialize` function terminates normally, `PROVIDER_READY` handlers **MUST** run.

See [provider initialization](./02-providers.md#24-initialization) and [setting a provider](./01-flag-evaluation.md#setting-a-provider).
See [provider initialization](./providers.md#24-initialization) and [setting a provider](./flag-evaluation.md#setting-a-provider).

#### Requirement 5.3.2

Expand All @@ -132,7 +132,7 @@ A failed initialization could represent an unrecoverable error, such as bad cred
If a failed initialization could also represent a transient error.
A provider which maintains a persistent connection to a remote `flag management system` may attempt to reconnect, and emit `PROVIDER_READY` after a failed initialization.

See [provider initialization](./02-providers.md#24-initialization) and [setting a provider](./01-flag-evaluation.md#setting-a-provider).
See [provider initialization](./providers.md#24-initialization) and [setting a provider](./flag-evaluation.md#setting-a-provider).

#### Requirement 5.3.3

Expand All @@ -143,4 +143,4 @@ Handlers should run immediately if the provider is already in the associated sta
For instance, _application authors_ may attach readiness handlers to be confident that 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).
See [provider initialization](./providers.md#24-initialization), [setting a provider](./flag-evaluation.md#setting-a-provider).
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ toc_max_heading_level: 4

## Overview

The `evaluation API` allows for the evaluation of feature flag values, independent of any flag control plane or vendor. In the absence of a [provider](./02-providers.md) the `evaluation API` uses the "No-op provider", which simply returns the supplied default flag value.
The `evaluation API` allows for the evaluation of feature flag values, independent of any flag control plane or vendor. In the absence of a [provider](./providers.md) the `evaluation API` uses the "No-op provider", which simply returns the supplied default flag value.

### 1.1. API Initialization and Configuration

Expand All @@ -33,7 +33,7 @@ OpenFeature.setProvider(new MyProvider());

This provider is used if a client is not bound to a specific provider through its name.

See [provider](./02-providers.md), [creating clients](#creating-clients).
See [provider](./providers.md), [creating clients](#creating-clients).

#### Requirement 1.1.2.2

Expand All @@ -43,7 +43,7 @@ Application authors can await the newly set `provider's` readiness using the `PR
Provider instances which are already active (because they have been bound to other `names` or otherwise) need not be initialized again.
The `provider's` readiness can 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).
See [event handlers and initialization](./events.md#event-handlers-and-initialization), [provider initialization](./providers.md#24-initialization).

#### Requirement 1.1.2.3

Expand All @@ -52,7 +52,7 @@ See [event handlers and initialization](./05-events.md#event-handlers-and-initia
When a provider is no longer in use, it should be disposed of using its `shutdown` mechanism.
Provider instances which are bound to multiple names won't be shut down until the last binding is removed.

see: [shutdown](./02-providers.md#25-shutdown), [setting a provider](#setting-a-provider)
see: [shutdown](./providers.md#25-shutdown), [setting a provider](#setting-a-provider)

#### Requirement 1.1.3

Expand All @@ -75,7 +75,7 @@ See [creating clients](#creating-clients).
OpenFeature.addHooks([new MyHook()]);
```

See [hooks](./04-hooks.md) for details.
See [hooks](./hooks.md) for details.

#### Requirement 1.1.5

Expand All @@ -86,7 +86,7 @@ See [hooks](./04-hooks.md) for details.
OpenFeature.getProviderMetadata();
```

See [provider](./02-providers.md) for details.
See [provider](./providers.md) for details.

### Creating clients

Expand Down Expand Up @@ -128,7 +128,7 @@ OpenFeatureAPI.getInstance().setProviderAndWait('client-name', myprovider); // t
Client client = OpenFeatureAPI.getInstance().getClient('client-name');
```

Though it's possible to use [events](./05-events.md) to await provider readiness, such functions can make things simpler for `application authors` and `integrators`.
Though it's possible to use [events](./events.md) to await provider readiness, such functions can make things simpler for `application authors` and `integrators`.

### 1.2. Client Usage

Expand All @@ -141,7 +141,7 @@ Though it's possible to use [events](./05-events.md) to await provider readiness
client.addHooks([new MyHook()]);
```

See [hooks](./04-hooks.md) for details.
See [hooks](./hooks.md) for details.

#### Requirement 1.2.2

Expand Down Expand Up @@ -179,7 +179,7 @@ number myNumber = client.getNumberValue('number-flag', 75);
MyStruct myStruct = client.getObjectValue<MyStruct>('structured-flag', { text: 'N/A', percentage: 75 }, evaluationContext, options);
```

See [evaluation context](./03-evaluation-context.md) for details.
See [evaluation context](./evaluation-context.md) for details.

#### Condition 1.3.2

Expand Down Expand Up @@ -367,7 +367,7 @@ This `flag metadata` field is intended as a mechanism for providers to surface a

> The `evaluation options` structure's `hooks` field denotes an ordered collection of hooks that the client **MUST** execute for the respective flag evaluation, in addition to those already configured.

See [hooks](./04-hooks.md) for details.
See [hooks](./hooks.md) for details.

### 1.6. Shutdown

Expand All @@ -380,4 +380,4 @@ See [hooks](./04-hooks.md) for details.
The global API object might expose a `shutdown` function, which will call the respective `shutdown` function on the registered providers.
Alternatively, implementations might leverage language idioms such as auto-disposable interfaces or some means of cancellation signal propagation to allow for graceful shutdown.

see: [`shutdown`](./02-providers.md#25-shutdown)
see: [`shutdown`](./providers.md#25-shutdown)
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ Hooks add their logic at any of four specific stages of flag evaluation:

![Flag evaluation life cycle](../assets/images/life-cycle.png)

Hooks can be configured to run globally (impacting all flag evaluations), per client, or per flag evaluation invocation. Some example use-cases for hook include adding additional data to the [evaluation context](./03-evaluation-context.md), performing validation on the received flag value, providing data to telemetric tools, and logging errors.
Hooks can be configured to run globally (impacting all flag evaluations), per client, or per flag evaluation invocation. Some example use-cases for hook include adding additional data to the [evaluation context](./evaluation-context.md), performing validation on the received flag value, providing data to telemetric tools, and logging errors.

### Definitions

Expand Down Expand Up @@ -111,7 +111,7 @@ void before(HookContext hookContext, HookHints hints);

> When `before` hooks have finished executing, any resulting `evaluation context` **MUST** be merged with the existing `evaluation context`.

Evaluation context merge order is defined in [Context levels and merging](./03-evaluation-context.md#32-context-levels-and-merging).
Evaluation context merge order is defined in [Context levels and merging](./evaluation-context.md#32-context-levels-and-merging).

#### Requirement 4.3.6

Expand Down Expand Up @@ -198,7 +198,7 @@ val = client.get_boolean_value('my-key', False, evaluation_options={
})
```

see: [Flag evaluation options](./01-flag-evaluation.md#)
see: [Flag evaluation options](./flag-evaluation.md)

#### Requirement 4.5.1

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ toc_max_heading_level: 4

The `provider` API defines interfaces that Provider Authors can use to abstract a particular flag management system, thus enabling the use of the `evaluation API` by Application Authors.

Providers are the "translator" between the flag evaluation calls made in application code, and the flag management system that stores flags and in some cases evaluates flags. At a minimum, providers should implement some basic evaluation methods which return flag values of the expected type. In addition, providers may transform the [evaluation context](./03-evaluation-context.md) appropriately in order to be used in dynamic evaluation of their associated flag management system, provide insight into why evaluation proceeded the way it did, and expose configuration options for their associated flag management system. Hypothetical provider implementations might wrap a vendor SDK, embed an REST client, or read flags from a local file.
Providers are the "translator" between the flag evaluation calls made in application code, and the flag management system that stores flags and in some cases evaluates flags. At a minimum, providers should implement some basic evaluation methods which return flag values of the expected type. In addition, providers may transform the [evaluation context](./evaluation-context.md) appropriately in order to be used in dynamic evaluation of their associated flag management system, provide insight into why evaluation proceeded the way it did, and expose configuration options for their associated flag management system. Hypothetical provider implementations might wrap a vendor SDK, embed an REST client, or read flags from a local file.

![Provider](../assets/images/provider.png)

Expand Down Expand Up @@ -129,7 +129,7 @@ ResolutionDetails<MyStruct> resolveStructureValue(string flagKey, MyStruct defau

### 2.3. Provider hooks

A `provider hook` exposes a mechanism for `provider authors` to register [`hooks`](./04-hooks.md) to tap into various stages of the flag evaluation lifecycle. These hooks can be used to perform side effects and mutate the context for purposes of the provider. Provider hooks are not configured or controlled by the `application author`.
A `provider hook` exposes a mechanism for `provider authors` to register [`hooks`](./hooks.md) to tap into various stages of the flag evaluation lifecycle. These hooks can be used to perform side effects and mutate the context for purposes of the provider. Provider hooks are not configured or controlled by the `application author`.

#### Requirement 2.3.1

Expand Down
6 changes: 3 additions & 3 deletions specification/types.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ A language primitive for representing a date and time, optionally including time

### Evaluation Details

A structure representing the result of the [flag evaluation process](./glossary.md#evaluating-flag-values), and made available in the [detailed flag resolution functions](./sections/01-flag-evaluation.md#14-detailed-flag-evaluation), containing the following fields:
A structure representing the result of the [flag evaluation process](./glossary.md#evaluating-flag-values), and made available in the [detailed flag resolution functions](./sections/flag-evaluation.md#14-detailed-flag-evaluation), containing the following fields:

- flag key (string, required)
- value (boolean | string | number | structure, required)
Expand Down Expand Up @@ -94,13 +94,13 @@ An enumerated error code represented idiomatically in the implementation languag

A structure containing the following fields:

- hooks (one or more [hooks](./sections/04-hooks.md), optional)
- hooks (one or more [hooks](./sections/hooks.md), optional)

### Flag Metadata

A structure which supports definition of arbitrary properties, with keys of type `string`, and values of type `boolean`, `string`, or `number`.

This structure is populated by a provider for use by an [Application Author](./glossary.md#application-author) (via the [Evaluation API](./glossary.md#evaluation-api)) or an [Application Integrator](./glossary.md#application-integrator) (via [hooks](./sections/04-hooks.md)).
This structure is populated by a provider for use by an [Application Author](./glossary.md#application-author) (via the [Evaluation API](./glossary.md#evaluation-api)) or an [Application Integrator](./glossary.md#application-integrator) (via [hooks](./sections/hooks.md)).

### Provider Status

Expand Down