Merge pull request #1 from robmoffat/merge-master

Merge master

.github/workflows/docusaurus.yml

@@ -40,9 +40,10 @@ jobs:
     - name: Configure Node
       uses: actions/setup-node@v1
       with:
-        node-version: '12'
+        node-version: '16.17.*'
     - name: Install website dependencies
-      run: yarn --cwd website install
+      working-directory: ./website
+      run: npm install
     - name: Patch forked version
       run: |
         # Extract GitHub org/user and patch siteConfig.js only if not "finos"
@@ -56,7 +57,8 @@ jobs:
       run: |
         curl ${{ env.CONTRIBUTE_SCRIPT_URL }} |  bash -s
     - name: Build website
-      run: yarn --cwd website build
+      working-directory: ./website
+      run: npm run build
     - name: Publish website
       run: |
         # Extract GitHub org/user

.github/workflows/package.yml

@@ -28,7 +28,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        node: [14.x]
+        node: [16.17.x]
         os: [ubuntu-latest, windows-latest]
 
     steps:
@@ -73,7 +73,7 @@ jobs:
     - name: Configure Node
       uses: actions/setup-node@v1
       with:
-        node-version: 14.x
+        node-version: 16.17.x
         registry-url: ${{ matrix.registry }}
 
     - name: Check package version

CHANGELOG.md

@@ -8,6 +8,16 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
 ### Added
 
+### Changed
+
+### Deprecated
+
+### Fixed
+
+## [FDC3 Standard 2.0](https://github.com/finos/FDC3/compare/v1.2..v2.0) - 2022-07-01
+
+### Added
+
 * Definition of the `icons` property of `AppMetadata`, based on PWA icon spec ([#319](https://github.com/finos/FDC3/pull/319))
 * Added support for raiseIntent without a context via the addition of the `fdc3.nothing` context type ([#375](https://github.com/finos/FDC3/pull/375))
 * Added [**FDC3 Workbench**](https://fdc3.finos.org/toolbox/fdc3-workbench/), an FDC3 API developer application ([#457](https://github.com/finos/FDC3/pull/457))
@@ -81,7 +91,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 * Corrected syntax errors in context schema examples ([#424](https://github.com/finos/FDC3/pull/424))
 * Corrected a minor error in the ViewQuote Intent example ([#439](https://github.com/finos/FDC3/pull/439))
 * Clarified behavior of `fdc3.addContextListener` when not joined to a channel ([#449](https://github.com/finos/FDC3/pull/449))
-* Clarified existing behavior of `joinChannel` and `addIntentListener` when joining a channel ([#454](https://github.com/finos/FDC3/pull/454))
+* Clarified existing behavior of `joinChannel` and `addContextListener` when joining a channel ([#454](https://github.com/finos/FDC3/pull/454))
 * Clarified numerous aspects of the existing `raiseIntent` behavior in the spec and documentation ([#461](https://github.com/finos/FDC3/pull/461))
 * Updated Methods.ts to support the updated signature for `addContextListener` introduced in FDC3 1.2 ([#462](https://github.com/finos/FDC3/pull/462))
 * Clarified the description of the addContextListener functions from the Desktop Agent and Channel APIs in spec and docs. ([#492](https://github.com/finos/FDC3/pull/492))

docs/api/ref/DesktopAgent.md

@@ -95,7 +95,7 @@ const contactListener = await fdc3.addContextListener('fdc3.contact', (contact,
 addIntentListener(intent: string, handler: IntentHandler): Promise<Listener>;
 ```
 
-Adds a listener for incoming intents from the Desktop Agent. The handler function may return void or a promise that resolves to a [`IntentResult`](Types#intentresult), which is either a [`Context`](Types#context) object, representing any data that should be returned to the app that raised the intent, or a [`Channel`](Channel) or [`PrivateChannel`](PrivateChannel) over which data responses will be sent. The `IntentResult` will be returned to app that raised the intent via the [`IntentResolution`](Metadata#intentresolution) and retrieved from it using the `getResult()` function.
+Adds a listener for incoming intents from the Desktop Agent. The handler function may return void or a promise that resolves to a [`IntentResult`](Types#intentresult), which is either a [`Context`](Types#context) object, representing any data that should be returned to the app that raised the intent, or a [`Channel`](Channel) or [`PrivateChannel`](PrivateChannel) over which data responses will be sent. The `IntentResult` will be returned to the app that raised the intent via the [`IntentResolution`](Metadata#intentresolution) and retrieved from it using the `getResult()` function.
 
 The Desktop Agent MUST reject the promise returned by the `getResult()` function of `IntentResolution` if: (1) the intent handling function's returned promise rejects, (2) the intent handling function doesn't return a promise, or (3) the returned promise resolves to an invalid type.
 

docs/api/ref/Errors.md

@@ -121,12 +121,12 @@ Contains constants representing the errors that can be encountered when calling
 
 ```typescript
 enum ResultError {
-  /** Returned if the intent handler exited without returning a Promise or that
+  /** Returned if the `IntentHandler` exited without returning a Promise or that
    *  Promise was not resolved with a Context or Channel object. 
    */
   NoResultReturned = 'NoResultReturned',
 
-  /** Returned if the Intent handler function processing the raised intent
+  /** Returned if the `IntentHandler` function processing the raised intent
    *  throws an error or rejects the Promise it returned. 
    */
   IntentHandlerRejected = 'IntentHandlerRejected',

docs/api/ref/Metadata.md

@@ -108,7 +108,7 @@ interface ContextMetadata {
 }
 ```
 
-Metadata relating to a context or intent & context received through the `addContextListener` and `addIntentListener` functions. Currently identifies that originated the context or intent message.
+Metadata relating to a context or intent & context received through the `addContextListener` and `addIntentListener` functions. Currently identifies the app that originated the context or intent message.
 
 [`@experimental`](../../fdc3-compliance#experimental-features) Introduced in FDC3 2.0 and may be refined by further changes outside the normal FDC3 versioning policy.
 
@@ -389,6 +389,7 @@ try {
 
 #### See also
 
+* [`IntentResult`](Types#intentresult)
 * [`DesktopAgent.raiseIntent`](DesktopAgent#raiseintent)
 * [`DesktopAgent.raiseIntentForContext`](DesktopAgent#raiseintentforcontext)
 * [`AppIdentifier`](Types#appidentifier)

docs/api/spec.md

@@ -215,7 +215,7 @@ When raising an intent a specific context is provided as input. The type of the
 
 A context type may also be associated with multiple intents. For example, an `fdc3.instrument` could be associated with `ViewChart`, `ViewNews`, `ViewAnalysis` or other intents.
 
-To raise an Intent without a context, use the [`fdc3.nothing`](../context/ref/Nothing) context type. This type exists so that applications can explicitly declare that they support raising an intent without a context (when registering an Intent listener or in an App Directory).
+To raise an intent without a context, use the [`fdc3.nothing`](../context/ref/Nothing) context type. This type exists so that applications can explicitly declare that they support raising an intent without a context (when registering an `IntentHandler` or in an App Directory).
 
 As an alternative to raising a specific intent, you may also raise an unspecified intent with a known context allowing the Desktop Agent or the user (if the intent is ambiguous) to select the appropriate intent and then to raise it with the specified context for resolution.
 
@@ -348,7 +348,7 @@ try {
 
 Applications need to let the system know the intents they can support.  Typically, this is done via registration with an [App Directory](../app-directory/spec).  It is also possible for intents to be registered at the application level as well to support ad-hoc registration which may be helpful at development time.  Although dynamic registration is not part of this specification, a Desktop Agent agent may choose to support any number of registration paths.
 
-When an instance of an application is launched, it is expected to add an [`IntentHandler`](ref/Types#intenthandler) function to the desktop agent for each intent it has registered by calling the [`fdc3.addIntentListener`](ref/DesktopAgent#addintentlistener) function of the Desktop Agent. Doing so allows the Desktop Agent to pass incoming intents and contexts to that instance of the application. Hence, if the application instance was spawned in response to the raised intent, then the Desktop Agent must wait for the relevant intent listener to be added by that instance before it can deliver the intent and context to it. In order to facilitate accurate error responses, calls to `fdc3.raiseIntent` should not return an `IntentResolution` until the intent handler has been added and the intent delivered to the target app.
+When an instance of an application is launched, it is expected to add an [`IntentHandler`](ref/Types#intenthandler) function to the Desktop Agent for each intent it has registered by calling the [`fdc3.addIntentListener`](ref/DesktopAgent#addintentlistener) function of the Desktop Agent. Doing so allows the Desktop Agent to pass incoming intents and contexts to that instance of the application. Hence, if the application instance was spawned in response to the raised intent, then the Desktop Agent must wait for the relevant intent listener to be added by that instance before it can deliver the intent and context to it. In order to facilitate accurate error responses, calls to `fdc3.raiseIntent` should not return an `IntentResolution` until the intent handler has been added and the intent delivered to the target app.
 
 ### Originating App Metadata
 
@@ -521,7 +521,7 @@ While joining User channels (using fdc3.joinUserChannel) automates a lot of the
 
 ### App Channels
 
-App Channels are topics dynamically created by applications connected via FDC3. For example, an app may` create a channel to broadcast to others data or status specific to that app.
+App Channels are topics dynamically created by applications connected via FDC3. For example, an app may create a named App Channel to broadcast data or status that is specific to that app to other apps that know to connect to the channel with that name.
 
 To get (or create) a channel reference, then interact with it:
 

docs/app-directory/overview.md

@@ -8,7 +8,7 @@ An application directory (appD) is a structured repository of information about
 
 The application metadata stored in appD records may include: the app name, type, details about how to run the application, its icons, publisher, support contact details and so on. It may also include links to or embed manifest formats defined elsewhere, such as proprietary manifests for launching the app in a container product or a Web Application Manifest (as [defined by the W3C](https://www.w3.org/TR/appmanifest/)).
 
-All this information is readily available in one place and can be used both to populate a launcher or app catalog UI for your users, and by the desktop agent managing the apps on your desktop. In fact, if your desktop platform supports the FDC3 standard, appD is the primary way that the FDC3 desktop agent implementation should receive the details about apps available to run on your desktop. Conversely, if an app is not listed in appD, the desktop agent can’t ensure its participation in context sharing or use it to resolve intents.
+All this information is readily available in one place and can be used both to populate a launcher or app catalog UI for your users, and by the Desktop Agent managing the apps on your desktop. In fact, if your desktop platform supports the FDC3 standard, appD is the primary way that the FDC3 Desktop Agent implementation should receive the details about apps available to run on your desktop. Conversely, if an app is not listed in appD, the Desktop Agent can’t ensure its participation in context sharing or use it to resolve intents.
 
 ## Advantages
 
@@ -22,7 +22,7 @@ Your appD is the one place to collect all the information about apps. The more a
 
 #### Human Readable
 
-AppD has two types of users. One is the desktop agent, but the other is humans administrating and using the smart desktop at your organization. Hence, an appD contains information about apps in both machine- and human-readable forms. For example, it includes both unique identifiers for apps that are used to refer to them in code and human-friendly app names, icons, descriptions and tooltips necessary to populate a launcher menu or app catalog user interface for your users.
+AppD has two types of users. One is the Desktop Agent, but the other is humans administrating and using the smart desktop at your organization. Hence, an appD contains information about apps in both machine- and human-readable forms. For example, it includes both unique identifiers for apps that are used to refer to them in code and human-friendly app names, icons, descriptions and tooltips necessary to populate a launcher menu or app catalog user interface for your users.
 
 #### Apps are Discoverable
 
@@ -36,7 +36,7 @@ Typically, software evolves over time. The app versions you are running today wi
 
 #### Agent-agnostic
 
-As a part of the FDC3 standard, appD isn't tied to any specific vendor. This is important, as it allows you more flexibility in that you are not tied to any specific container or desktop agent implementation. If at any point you want to switch to a different desktop agent, the process won’t be prohibitively difficult. The existing appD will work without any additional effort from you, as long as your new desktop agent is also FDC3-compliant. This is in contrast with proprietary solutions, where you would have to produce a new configuration and integration for every application.
+As a part of the FDC3 standard, appD isn't tied to any specific vendor. This is important, as it allows you more flexibility in that you are not tied to any specific container or Desktop Agent implementation. If at any point you want to switch to a different Desktop Agent, the process won’t be prohibitively difficult. The existing appD will work without any additional effort from you, as long as your new Desktop Agent is also FDC3-compliant. This is in contrast with proprietary solutions, where you would have to produce a new configuration and integration for every application.
 
 AppD reduces fragmentation in the market and allows end-users more flexibility in what applications can be included in their desktop.
 
@@ -68,13 +68,13 @@ Wherever possible, FDC3 seeks to draw inspiration from, align itself with and re
 
 ## Use Cases
 
-An application directory provides information about an application's identifiers, publisher details, intents that it supports, and metadata necessary to launch and integrate the application in a desktop agent.
+An application directory provides information about an application's identifiers, publisher details, intents that it supports, and metadata necessary to launch and integrate the application in a Desktop Agent.
 
 The following provides a summary of use cases.
 
 ### Launcher
 
-A desktop agent will usually include a user interface allowing the user to select from a set of launchable applications and then allow them to manually launch an one. It is also responsible for launching applications necessary to resolve a raised intent. However, it must first retrieve the necessary metadata about the available applications. An app directory provides an endpoint to retrieve a list of the available applications along with their metadata, which may include or link to additional information necessary to launch the application in a specific desktop agent.
+A Desktop Agent will usually include a user interface allowing the user to select from a set of launchable applications and then allow them to manually launch one. It is also responsible for launching applications necessary to resolve a raised intent. However, it must first retrieve the necessary metadata about the available applications. An app directory provides an endpoint to retrieve a list of the available applications along with their metadata, which may include or link to additional information necessary to launch the application in a specific Desktop Agent.
 
 A launcher will usually be configured with the locations of one or more AppD servers (which is necessary to implement intent resolution), however, as described in the [Service Discovery](#service-discovery) section, a fully qualified application identifier (app1@host.appd.com) may also be used to both locate the appD service and to retrieve the specific application data.
 
@@ -107,23 +107,23 @@ Although the concept of fully qualified application IDs are useful in resolving
 
 ## Service Discovery
 
-In order to support the discovery of applications that can be used with a desktop agent, it is necessary to access data stored in one or more app directory instances.
+In order to support the discovery of applications that can be used with a Desktop Agent, it is necessary to access data stored in one or more app directory instances.
 
 ![img](assets/appd_service_distribution.png)
 
 However, in order to do so, you must first discover the location of an app directory service, which you may then use to generate URIs  (e.g. "https://appd.foo.com/api/appd/v2/app1@appd.foo.com") to query a given directory instance for data. In order to construct a URI, the host location and port of a given AppD service instance is required.
 
 Three methods for discovering app directory services are defined in this Standard:
 
-  1. **Static configuration:** Statically defined URI records for use within client applications (typically a desktop agent implementation) directly.
+  1. **Static configuration:** Statically defined URI records for use within client applications (typically a Desktop Agent implementation) directly.
   2. **Fully-qualified appID namespace syntax host resolution:** Discovery of the appD location using a fully qualified application ID (appId) domain name.  
   3. **DNS lookup by domain name:** Discovery of the appD location using a domain name to lookup DNS SRV records identifying the host server location and TCP port. ([RFC2782](https://tools.ietf.org/html/rfc2782))
 
 App directory service host discovery implementations SHOULD support each of these methods and MUST support at least static configuration.
 
 ### Static configuration
 
-As the name implies, a static configuration for an appD service location is defined within a desktop agent or launcher application. This is the simplest and most common approach to app directory and application data discovery.
+As the name implies, a static configuration for an appD service location is defined within a Desktop Agent or launcher application. This is the simplest and most common approach to app directory and application data discovery.
 
 ![img](assets/appd_static_config.png)
 

docs/context/ref/TimeRange.md

@@ -43,7 +43,7 @@ https://fdc3.finos.org/schemas/next/timerange.schema.json
 | `startTime` | string *  | No **    | `"2022-03-30T15:44:44Z"`      |
 | `endTime`   | string *  | No **    | `"2022-04-30T23:59:59+00:00"` |
 
-\* Fields representing time SHOULD be string encoded according [ISO 8601-1:2019](https://www.iso.org/standard/70907.html) with a timezone indicator included.
+\* Fields representing time SHOULD be string encoded according to [ISO 8601-1:2019](https://www.iso.org/standard/70907.html) with a timezone indicator included.
 
 \*\* One of `startTime` or `endTime` MUST be specified.
 

docs/fdc3-intro.md

@@ -1,6 +1,6 @@
 ---
 id: fdc3-intro
-title: Welcome to FDC3 2.0 (pre-draft)
+title: Welcome to FDC3 2.1 (pre-draft)
 sidebar_label: Introduction
 ---