Minor changes to existing docs.

docs/appd-discovery.md

@@ -109,7 +109,7 @@ The resulting URI to retrieve application data for "app1" would be "[https://app
 
 ###  Application identifiers, Shrinking the URI and AppdD defaults
 
-Although the concept of fully qualified application IDs are useful in resolving the actual host of the application directory, there is no requirement for an application directory to use this fully qualified application ID as the resolver for a record. An application ID is unique to given application directory, but there is no requirement to use the fully qualified representation when querying an interface. Taking the prior example, the fully qualified application ID "app1@appd.foo.com" is represented as "app1" within the application directory. As a result a launcher can use a shortened URI construct "<https://appd.foo.com/api/appd/v1/app1>" to resolve the application data vs "https://appd.foo.com/api/appd/app1@appd.foo.com".
+Although the concept of fully qualified application IDs are useful in resolving the actual host of the application directory, there is no requirement for an application directory to use this fully qualified application ID as the resolver for a record.  An application ID is unique to given application directory, but there is no requirement to use the fully qualified representation when querying an interface.  Taking the prior example, the fully qualified application ID "app1@appd.foo.com" is represented as "app1" within the application directory.  As a result a launcher can use a shortened URI construct "<https://appd.foo.com/api/appd/v1/app1>" to resolve the application data vs "https://appd.foo.com/api/appd/v1/app1@appd.foo.com".
 
 ### DNS/SRV Records
 
@@ -121,9 +121,9 @@ More specifically, resolution of an AppD service instance (host location) can be
 zone name { _service._proto.name. TTL  class  SRV priority weight port target.}
 ```
 
-- *service*: the symbolic name of the desired service. For AppD service, this mus be identified as "**_appd**"
-- *proto*: the transport protocol of the desired service; this is usually either [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) or [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol). For AppD service **_tcp** must be used.
-- *name*: the domain name for which this record is valid, ending in a dot. For AppD service,  the name should directly map to the application identifier domain. 
+- *service*: the symbolic name of the desired service.  For AppD service, this must be identified as "**_appd**"
+- *proto*: the transport protocol of the desired service; this is usually either [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) or [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol).  For AppD service **_tcp** must be used.
+- *name*: the domain name for which this record is valid, ending in a dot.  For AppD service,  the name should directly map to the application identifier domain. 
 - *TTL*: standard DNS [time to live](https://en.wikipedia.org/wiki/Time_to_live) field.
 - *class*: standard DNS class field (this is always *IN*).
 - *priority*: the priority of the target host, lower value means more preferred.

docs/appd-use.md

@@ -63,8 +63,7 @@ knowledge of the AppD instance location (FQDN).
 ## Enhancing controls
 
 The AppD API specification defines the optional use of an access token to
-identify the requesting user/launcher and implement authorizations around
-AppD actions can be performed. Actions are considered standard CRUD operations.
+identify the requesting user/launcher and implement authorizations around which AppD actions can be performed.  Actions are considered standard CRUD operations.
 Again the specification does not define or make mandatory any authorizations
 or roles that a provider or enterprise can define.
 

docs/context-intro.md

@@ -15,7 +15,7 @@ Context objects are used when raising [Intents](intents-intro) and when broadcas
 ## Context Object
 
 Context can be summarised as:
-* Having a unique <type_ identifier, used for routing.
+* Having a unique _type_ identifier, used for routing.
 * Optionally providing a name.
 * Optionally providing a map of equivalent identifiers.
 * Any other properties or metadata.
@@ -60,4 +60,4 @@ e.g. as a JSON payload:
     "country": "US"
 }
 ```
- It is important to note that the context data specification allows extra identifiers and properties to be added as needed for each interop use case. In the example above, `country` could represent extra metadata in addition to the agreed instrument representation.
+ It is important to note that the context data specification allows extra identifiers and properties to be added as needed for each interop use case. In the example above, `country` could represent extra data in addition to the agreed instrument representation.

docs/context-spec.md

@@ -104,7 +104,7 @@ __Note:__ The below examples show how the base context data interface can be use
             }
         },
         {
-            "type" : "$fdc3.contact",
+            "type" : "fdc3.contact",
             "name":"Espen Overbye",
             "id":{
                 "email": "espen@openfin.co"
@@ -137,7 +137,7 @@ All well-known types at FDC3 level should be prefixed with `fdc3`. For private t
 
 The specification recognises that evolving context data definitions over time, and helping applications to deal with changes to types, are very important.
 
-It may be as simple as adding an optional `$version` property to types, but it could also be a set of guidelines for adding new properties, without removing or changing existing ones. For example, web technologies like REST or GraphQL does not take a particular opinion about versioning.
+It may be as simple as adding an optional `$version` property to types, but it could also be a set of guidelines for adding new properties, without removing or changing existing ones. For example, web technologies like REST or GraphQL do not take a particular opinion about versioning.
 
 ### Identifiers