Upgrading web access statements from SHOULD to MUST in the API specif…

…ication and FDC3 compliance pages.

docs/api/spec.md

@@ -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() {

docs/fdc3-compliance.md

@@ -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.
@@ -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:
 
-* 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
+* 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