Formatting and other corrections from review meeting 20240919

docs/api/ref/GetAgent.md

@@ -42,7 +42,7 @@ try {
 
 The  `getAgent()` function allows web applications to retrieve an FDC3 Desktop Agent API interface to work with, whether they are running in an environment that supports a Desktop Agent Preload (a container-injected API implementation) or a Desktop Agent Proxy (a Browser-based Desktop Agent running in another window or frame). The behavior of `getAgent()` is defined by the [FDC3 Web Connection Protocol (WCP)](../specs/webConnectionProtocol) and communication with a Desktop Agent Proxy in a web-browser is defined by the [Desktop Agent Communication Protocol (DACP)](../specs/desktopAgentCommunicationProtocol). Hence, it allows applications to be written that will work in either scenario without modification or the inclusion of vendor-specific libraries.
 
-If no Desktop Agent is found, a failover function may be supplied by app allowing it to start or otherwise connect to a Desktop Agent (e.g. by loading a proprietary adaptor that returns a `DesktopAgent` implementation or by creating a window or iframe of its own that will provide a Desktop Agent Proxy.
+If no Desktop Agent is found, a failover function may be supplied by app allowing it to start or otherwise connect to a Desktop Agent (e.g. by loading a proprietary adaptor that returns a `DesktopAgent` implementation or by creating a window or iframe of its own that will provide a Desktop Agent Proxy).
 
 The definition of the `getAgent()` function is as follows:
 

docs/api/specs/browserResidentDesktopAgents.md

@@ -50,9 +50,9 @@ When an app runs `getAgent()`, it checks for the existence of `window.parent`, `
 
 Hence, apps may be launched:
 
-1) By creating iframes in a DA Window
-2) By calling `window.open` from a DA Window
-3) By creating iframes in a window that was opened from a DA Window
+1. By creating iframes in a DA Window
+2. By calling `window.open` from a DA Window
+3. By creating iframes in a window that was opened from a DA Window
 
 and the Desktop Agent application will be found in a 'parent' of the application frame.
 
@@ -62,9 +62,9 @@ Browser Resident DAs MUST call `window.addEventListener("message",...)` to recei
 
 Upon receiving an incoming [`"WCP1Hello"`](https://fdc3.finos.org/schemas/next/api/WCP1Hello.schema.json) the Desktop Agent MUST either:
 
-1) Respond with a [`WCP2LoadUrl`](https://fdc3.finos.org/schemas/next/api/WCP2LoadUrl.schema.json) message (as defined in the [Web Connection Protocol](./webConnectionProtocol)).
+1. Respond with a [`WCP2LoadUrl`](https://fdc3.finos.org/schemas/next/api/WCP2LoadUrl.schema.json) message (as defined in the [Web Connection Protocol](./webConnectionProtocol)).
     - This message indicates that `getAgent()` should create an iframe, load the provided URL (for an adaptor to the Desktop Agent) into it and then restart the connection process by sending [`"WCP1Hello"`](https://fdc3.finos.org/schemas/next/api/WCP1Hello.schema.json) to the iframe.
-2) Create a [`MessageChannel`](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API) with two entangled `MessagePort` instances that will be used for further communication with the application.
+2. Create a [`MessageChannel`](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API) with two entangled `MessagePort` instances that will be used for further communication with the application.
     - Before returning one of `MessagePort` instances, the DA MUST set up event listeners to to receive and process a [`"WCP4ValidateAppIdentity"`](https://fdc3.finos.org/schemas/next/api/WCP4ValidateAppIdentity.schema.json) message from the application.
     - To deliver the `MessagePort`, the DA MUST respond to the event's `source` window by responding with a [`WCP3Handshake`](https://fdc3.finos.org/schemas/next/api/WCP3Handshake.schema.json) message (as defined in the [Web Connection Protocol](./webConnectionProtocol)) and append `port2` from the `MessageChannel` to the message.
 
@@ -221,9 +221,8 @@ As described above, DA providers can leverage hidden iframes to establish a comm
 
 The hidden iframe url can be provided in two ways:
 
-1) By a Parent window - This allows DAs to redirect communications to via a hidden iframe that loads a known URL. The main benefit of this approach is that it can allow a system to continue to operate even if the parent window is closed.
-
-2) By a `failover` function - When no parent DA can be found (such as when a tab is opened directly by an end user) then a failover function can create a hidden iframe and return a reference to it (a `WindowProxy`) to initiate communication with via the WCP and DACP in the same way as we do with a parent window. Alternatively, a `DesktopAgent` implementation maybe loaded directly and returned from the failover function, which `getAgent()` will pass-through.
+1. By a Parent window - This allows DAs to redirect communications to via a hidden iframe that loads a known URL. The main benefit of this approach is that it can allow a system to continue to operate even if the parent window is closed.
+2. By a `failover` function - When no parent DA can be found (such as when a tab is opened directly by an end user) then a failover function can create a hidden iframe and return a reference to it (a `WindowProxy`) to initiate communication with via the WCP and DACP in the same way as we do with a parent window. Alternatively, a `DesktopAgent` implementation maybe loaded directly and returned from the failover function, which `getAgent()` will pass-through.
 
 ## Channel Selector and Intent Resolver User Interfaces
 

docs/api/specs/desktopAgentCommunicationProtocol.md

@@ -316,7 +316,6 @@ title: Intent resolution with injected Intent Resolver iframe
 ---
 sequenceDiagram
     AppA ->> DesktopAgent: raiseIntentRequest
-    DesktopAgent ->> AppB: intentEvent
     DesktopAgent ->> AppA: raiseIntentResponse
     Note left of DesktopAgent: raiseIntentResponse includes a<br/> RaiseIntentNeedsResolutionResponsePayload<br/>containing an AppIntent
     break when AppIntent return with multiple options
@@ -340,11 +339,11 @@ title: Intent resolution with Desktop Agent provided Intent Resolver
 ---
 sequenceDiagram
     AppA ->> DesktopAgent: raiseIntentRequest
-    DesktopAgent ->> AppB: intentEvent
     break DA determines there are multiple options
         DesktopAgent-->AppA: Desktop Agent displays an<br/>IntentResolver UI
         AppA-->DesktopAgent: User picks an option
     end
+    DesktopAgent ->> AppB: intentEvent
     DesktopAgent ->> AppA: raiseIntentResponse
     Note left of DesktopAgent: DesktopAgent responds<br/>to the original<br/>raiseIntentRequest message with<br/>a RaiseIntentSuccessResponsePayload
     AppB ->> DesktopAgent: intentResultRequest

docs/api/specs/webConnectionProtocol.md

@@ -46,7 +46,7 @@ There are a number of messages defined as part of the Web Connection Protocol. D
 TypeScript types representing all DACP and WCP messages are generated from the JSON Schema source and can be imported from the [`@finos/fdc3` npm module](https://www.npmjs.com/package/@finos/fdc3):
 
 ```ts
-import {BrowserTypes} from '@finos.fdc3';
+import {BrowserTypes} from '@finos/fdc3';
 ```
 
 :::
@@ -188,7 +188,7 @@ Setup a timer for specified timeout, and then for each `candidate` found, attemp
           timestamp: "2024-09-09T11:44:39+00:00"
       }
   };
-  candidate.postMessage(hello, { targetOrigin: * };)
+  candidate.postMessage(hello, { targetOrigin: "*" });
   ```
 
   Note that the `targetOrigin` is set to `*` as the origin of the Desktop Agent is not known at this point.