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.

Sign up for GitHub

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

Jump to bottom

Upgrading web access statements from SHOULD to MUST in the API specification and FDC3 compliance pages #440

Merged
merged 1 commit into from
Oct 7, 2021
Merged

Upgrading web access statements from SHOULD to MUST in the API specification and FDC3 compliance pages #440

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
4 changes: 2 additions & 2 deletions docs/api/spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,9 +36,9 @@ Other interfaces defined in the spec are not critical to define as concrete type


#### API Access
The FDC3 API can be made available to an application through a number of different methods. In the case of web applications, a Desktop Agent SHOULD provide the FDC3 API via a global accessible as _window.fdc3_. Implementors MAY additionally make the API available through modules, imports, or other means.
The FDC3 API can be made available to an application through a number of different methods. In the case of web applications, a Desktop Agent MUST provide the FDC3 API via a global accessible as `window.fdc3`. Implementors MAY additionally make the API available through modules, imports, or other means.

The global `window.fdc3` must only be available after the API is ready to use. To prevent the API from being used before it is ready, implementors SHOULD provide a global `fdc3Ready` event. Here is code demonstrating the use of the FDC3 API and the ready event:
The global `window.fdc3` must only be available after the API is ready to use. To enable applications to avoid using the API before it is ready, implementors MUST provide a global `fdc3Ready` event. Here is code demonstrating the use of the FDC3 API and the ready event:

```js
function fdc3Stuff() {
Expand Down
11 changes: 6 additions & 5 deletions docs/fdc3-compliance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,10 +13,10 @@ In general, the ratified FDC3 specs represent a lowest common denominator interf
> actually required for interoperation or to limit behavior which has
> potential for causing harm (e.g., limiting retransmisssions) For
> example, they must not be used to try to impose a particular method
> on implementors where the method is not required for
> on implementors where the method is not required for
> interoperability.

These rules would apply only to standards work within FDC3. Today, this covers API, App Directory, Context Data, and Intents working groups, it does not apply to the Use Cases working group.
These rules would apply only to standards work within FDC3. Today, this covers the API, App Directory, Context Data, and Intents specifications.

## Personas
FDC3 implementors generally fall into 2 categories: platform providers, and application providers. A platform provider supplies an implementation of the FDC3 API for applications to use. Implicitly, it connects to one or more App Directories.
Expand All @@ -26,12 +26,13 @@ An application provider is largely a downstream consumer of FDC3 standards. It M
Depending on persona, implementation compliance with FDC3 will mean different things.

### Platform Provider
To meet the requirements of FDC3, a platform provider would need to support the following:
For platform providers FDC3 compliance requires:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Standardized wording


* Connection to 1 or more App Directories meeting the FDC3 App Directory standards
* Provide an API to all applications running in the context of the platform that meets the FDC3 API standards, including:
* Support for connections to 1 or more App Directories meeting the FDC3 App Directory standards SHOULD be provided
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section was missing imperatives (bar one on workflows). Matched style with Application provider section as one was needed in the window.fdc3 addition

* An API implementation that meets the FDC3 API standards MUST be provided to all applications running in the context of the platform, including:
* Support for FDC3 Context Data and Intents standards
* Support for Intent and Context resolution using a resolver UI
* In the case of web applications, a Desktop Agent MUST provide the FDC3 API via a global accessible as `window.fdc3`.
* At least one workflow of one of the use cases marked as Accepted by the Use Cases working group SHOULD be satisfied by the implementation.

### Application Provider
Expand Down