Apply suggestions from code review

Co-authored-by: Hugh Troeger <htroeger@factset.com>

docs/api/spec.md

@@ -98,7 +98,7 @@ An FDC3 Standard compliant Desktop Agent implementation **MUST**:
 
 - Provide the FDC3 API to web applications via a global accessible as [`window.fdc3`](#api-access).
 - Provide a global [`fdc3Ready`](#api-access) event that is fired when the API is ready for use.
-- Provide a method of resolving ambiguous intents (i.e. those that might be resolved by multiple applications) or unspecified intents (calls to raiseIntentForCOntext that return multiple options), usch as a resolver UI.
+- Provide a method of resolving ambiguous intents (i.e. those that might be resolved by multiple applications) or unspecified intents (calls to `raiseIntentForContext` that return multiple options), such as a resolver UI.
   - Intent resolution MUST take into account any specified input or return context types
   - Requests for resolution to apps returning a channel MUST include any apps that are registered as returning a channel with a specific type.
 - Return Errors from the [`ChannelError`](ref/Errors#channelerror), [`OpenError`](ref/Errors#openerror), [`ResolveError`](ref/Errors#resolveerror) and [`ResultError`](ref/Errors#resulterror) enumerations as appropriate.

docs/app-directory/spec.md

@@ -27,7 +27,7 @@ An FDC3 Standard compliant App Directory implementation **MUST**:
   * `/v2/apps/{appId}` (GET)
 * Ensure that `appId` field values assigned to applications are unique within the directory.
 * Ensure that app directory records served meet the minimum requirements specified in the [app directory OpenAPI specification](/schemas/next/app-directory#tag/Application/paths/~1v2~1apps~1{appId}/get)
-* Support retrieval of app directory records via either the raw appId (e.g. `myAppId`) or fully-qualified appId (e.g. `myAppId@host.domain.com`) as defined in the [app directory overview](overview#shrinking-the-uri).
+* Support retrieval of app directory records via either the raw `appId` (e.g. `myAppId`) or fully-qualified appId (e.g. `myAppId@host.domain.com`) as defined in the [app directory overview](overview#shrinking-the-uri).
 
 An FDC3 Standard compliant App Directory implementation **SHOULD**:
 

docs/context/spec.md

@@ -144,8 +144,8 @@ An FDC3 Standard compliant application that supports the use of context data **M
 
 An FDC3 Standard compliant application that supports the use of context data **SHOULD**:
 
-* Prefer FDC3-defined standard context types over proprietary contexts, where a suitable FDC3-defined stanrd context type is available.
-* Ensure that any proprietary context data types fefined follow any the recommended [namespacing](#namespacing) and [field type conventions](#field-type-conventions) in the specification.
+* Prefer FDC3-defined standard context types over proprietary contexts, where a suitable FDC3-defined standard context type is available.
+* Ensure that any proprietary context data types defined follow any the recommended [namespacing](#namespacing) and [field type conventions](#field-type-conventions) in the specification.
 
 An FDC3 Standard compliant application that supports the use of context data **MAY**:
 

docs/fdc3-compliance.md

@@ -21,7 +21,7 @@ These rules would apply only to standards work within FDC3. Today, this covers t
 
 ## Personas
 
-FDC3 implementors generally fall into 2 categories: platform providers, and application providers. A platform provider supplies an implementation(s) of the FDC3 APIs (The Desktop Agent API and Applkication Directory) for applications to use.
+FDC3 implementors generally fall into 2 categories: platform providers, and application providers. A platform provider supplies an implementation(s) of the FDC3 APIs (The Desktop Agent API and Application Directory) for applications to use.
 
 An application provider is largely a downstream consumer of FDC3 standards. It MAY use the API, it MAY use Context Data, it MAY use Intents. Application providers are only required to comply with the standards they make use of.