Fix typos in docs

Change-Id: I901ff5bb6f22ba7076914c7cbe92f69b4b89cb0e
Signed-off-by: Sebastien Douheret <sebastien.douheret@iot.bzh>

4 files changed, 66 insertions, 65 deletions

diff --git a/README.md b/README.md
index 6054267..49993bf 100644
--- a/README.md
+++ b/README.md
@@ -24,7 +24,7 @@ This package requires the following libraries or modules:
 - ***dbus-1***
 - ***security-manager***
 
-This package also requires either ***libzip*** (version >= 0.11) 
+This package also requires either ***libzip*** (version >= 0.11)
 or the binaries ***zip*** and ***unzip***. By default, it will
 use ***libzip***.
 
@@ -33,9 +33,9 @@ use ***libzip***.
 The main scheme for compiling the project is:
 
 > cmake .
-> 
+>
 > make
-> 
+>
 > sudo make install
 
 By default, the installation is made in ***/usr***.
@@ -44,7 +44,7 @@ CMAKE_INSTALL_PREFIX as in the below example:
 
 > cmake -DCMAKE_INSTALL_PREFIX=/some/where .
 
-You could check the documentation of the standard CMake module 
+You could check the documentation of the standard CMake module
 [GNUInstallDirs](https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html).
 
 To forbid the use of ***libzip*** and replace it with the
@@ -72,7 +72,7 @@ The installed programs are:
   It runs on the user session bus.
 
 - ***wgtpkg-info***: command line tool to display
-  informations about a widget file.
+  information about a widget file.
 
 - ***wgtpkg-installer***: command line tool to
   install a widget file.
@@ -88,7 +88,7 @@ The installed programs are:
 ### Actors
 
 The framework defined by afm-main is defining several actors:
-the platform designer, the application developper, the distributor,
+the platform designer, the application developer, the distributor,
 the user, the hacker.
 
 The platform designer defines the AGL system and its security.
@@ -101,12 +101,12 @@ The hacker is a user that also develops application for
 tuning its system.
 
 The distributor is the mediator between the developer and the
-user. It provides 
+user. It provides
 
 The user is either the driver or a passenger of the car.
 
 The application, libraries, services are available on the
-platform. Somme of it are in direct interaction with users.
+platform. Some of them are in direct interaction with users.
 Some others, like services, are used indirectly.
 
 
@@ -115,24 +115,24 @@ Some others, like services, are used indirectly.
 #### Writing applications
 
 The application will receive an identifier.
-That identifier must be must have the following feature:
+That identifier must have the following feature:
 
-- it must be unic to identify the application and its revisions
+- it must be unique to identify the application and its revisions
 - it should be short enough to be used with efficiency by
   security components of the system
 - it can not be stolen by malicious applications that
-  would like to usurpate the application identity
+  would like to spoof the application identity
 - it can be sold to other company
 
 The framework provide a facility to create an asymetric
 key that will serve all the above purposes (it currently
-doen't).
+doesn't).
 
-Using its favorite environment, the developper
-produce applications for the target.
+Using its favorite environment, the developer
+produces applications for the target.
 
 Depending on its constraints either economic,
-technical or human, the developer choose the language
+technical or human, the developer chooses the language
 and the environment for developing the applications.
 
 This step needs to test and to debug the application on
@@ -146,22 +146,22 @@ The framework will provide facilities for debugging
 
 #### Packaging applications
 
-Currently the frame work expect widgets packaged as
+Currently the framework expects widgets packaged as
 specified by [Packaged Web Apps](http://www.w3.org/TR/widgets).
 
-When the application is ready, the developper
+When the application is ready, the developer
 creates a package for it. The creation of the package
 is made of few steps:
 
-- isolate the strict necessarily files and structure it 
+- isolate the strict necessarily files and structure it
   to be children of only one root directory
-- sign the application with the developper key
+- sign the application with the developer key
 - sign the application with its application key
 - pack the application using zip
 
 The framework will provide facilities to package applications.
 
-Parts of the job can be made with tools provided by afm-main:
+Parts of the job can be done with tools provided by afm-main:
 
 - ***wgtpkg-sign*** is used to add signatures at root of the package
 - ***wgtpkg-pack*** is used to create the package file (with wgt extension).
@@ -180,14 +180,14 @@ applications. For example, a critical application nested
 in the system should have high level permissions allowing
 it to do things that should normally not be done (changing
 system configuration for example).
-To allow such an application, the distributor must sign
+To allow such application, the distributor must sign
 it using its secret private key that will unlock the
 requested level of permissions.
 
-Currently, the frammework allows to make these steps by hand
-the programs ***unzip***, ***wgtpkg-sign*** and ***wgtpkg-pack***.
+Currently, the framework allows to make these steps manually
+using ***unzip***, ***wgtpkg-sign*** and ***wgtpkg-pack*** utilities.
 
-The applications of the store will then be available
+Applications of the store will then be available
 for browsing and searching over HTTP/Internet.
 
 #### Installing applications
@@ -196,7 +196,7 @@ The framework will provide an API for downloading and
 installing an application from stores (it currently doesn't).
 
 The current version of afm allows to install widgets
-from local files (either preinstalled or downloaded).
+from local files (either pre-installed or downloaded).
 
 To install a widget, you can use either the program
 ***wgtpkg-installer*** while being the framework user.
@@ -229,7 +229,7 @@ TO BE CONTINUED
 
 ## Extension to the packaging specifications
 
-The widgets are specified in that W3C recommandation: 
+The widgets are specified in that W3C recommendation:
 [Packaged Web Apps](http://www.w3.org/TR/widgets).
 This model was initially designed for HTML applications.
 But it is well suited for other kind of applications.
@@ -244,7 +244,7 @@ nor suited for managing privileges:
 However, it may become of actuallity in some future.
 
 The main idea is to use the file ***config.xml*** as a switch
-for several contants.
+for several constants.
 The current specifications for ***config.xml*** are allowing
 to describe either HTML5, QML and native applications.
 Using *feature*, it is also possible to define uses of
diff --git a/docs/overview.md b/docs/overview.md
index c3627bc..f0441da 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -43,7 +43,7 @@ of Tizen showed that their dependencies to Tizen are light (and since some
 of our work, there is no more dependency to tizen).
 Those components are **cynara**, **security-manager**, **D-Bus aware of cynara**.
 
-Luckyly, these core security components of Tizen are provided
+Luckily, these core security components of Tizen are provided
 by [meta-intel-iot-security][meta-intel], a set of yocto layers.
 These layers were created by Intel to isolate Tizen specific security
 components from the initial port of Tizen to Yocto.
@@ -57,12 +57,12 @@ The figure below shows the history of these layers.
 
 ![Security_model_history][Security_model_history]
 
-We took the decision to use these security layers that provides the
+We took the decision to use these security layers that provide the
 basis of the Tizen security, the security framework.
 
 For the components of the application framework, built top of
 the security framework, instead of pulling the huge set of packages
-from Tizen, we decided to refit it by developping a tiny set of
+from Tizen, we decided to refit it by developing a tiny set of
 components that would implement the same behaviour but without all
 the dependencies and with minor architectural improvements for AGL.
 
@@ -104,7 +104,7 @@ Let follow the sequence of calls:
    **afm-system-daemon** checks the application to install, its
    signatures and rights and install it.
 
-5. **afm-system-daemon** calls **SECURITY-MANAGER** for fullfilling
+5. **afm-system-daemon** calls **SECURITY-MANAGER** for fulfilling
    security context of the installed application.
 
 6. **SECURITY-MANAGER** calls **CYNARA** to install initial permissions
@@ -124,7 +124,7 @@ Let follow the sequence of calls:
     or not to start the OTHER application **CYNARA**.
 
 12. **afm-user-daemon** uses **SECURITY-MANAGER** features to set
-    the seciruty context for the OTHER application.
+    the security context for the OTHER application.
 
 13. **afm-user-daemon** launches the OTHER application.
 
@@ -161,7 +161,7 @@ Links between the "Security framework" and the "Application framework"
 The security framework refers to the security model used to ensure
 security and to the tools that are provided for implementing that model.
 
-The security model refers to how DAC (Discretionnary Access Control),
+The security model refers to how DAC (Discretionary Access Control),
 MAC (Mandatory Access Control) and Capabilities are used by the system
 to ensure security and privacy. It also includes features of reporting
 using audit features and by managing logs and alerts.
@@ -173,7 +173,7 @@ The application framework uses the security model/framework
 to ensure the security and the privacy of the applications that
 it manages.
 
-The application framework must be compliant with the underlyiong
+The application framework must be compliant with the underlying
 security model/framework. But it should hide it to the applications.
 
 
@@ -188,15 +188,16 @@ the [meta-intel].
 It includes: **Security-Manager**, **Cynara**
 and **D-Bus** compliant to Cynara.
 
-Two patches are applied to the security-manager. These patches are removing
-dependencies to packages specific of Tizen but that are not needed by AGL.
+Two patches are applied to the security-manager. The goal of these patches
+is to remove specific dependencies with Tizen packages that are not needed
+by AGL.
 None of these patches adds or removes any behaviour.
 
-**Theoritically, the security framework/model is an implementation details
+**In theory, the security framework/model is an implementation details
 that should not impact the layers above the application framework**.
 
 The security framework of Tizen provides "nice lad" a valuable component to
-scan log files and analyse auditing. This component is still in developement.
+scan log files and analyse auditing. This component is still in development.
 
 
 The application framework
@@ -221,7 +222,7 @@ This model allows the distribution of HTML, QML and binary applications.
 
 The management of signatures of the widget packages.
 This basis is not meant as being rigid and it can be extended in the
-futur to include for example incremental delivery.
+future to include for example incremental delivery.
 
 
 
diff --git a/docs/permissions.md b/docs/permissions.md
index 434744e..407fdc2 100644
--- a/docs/permissions.md
+++ b/docs/permissions.md
@@ -7,10 +7,10 @@ Permission's names
 
 The proposal here is to specify a naming scheme for permissions
 that allows the system to be as stateless as possible. The current
-current specification includes in the naming of permissions either
+specification includes in the naming of permissions either
 the name of the bound binding when existing and the level of the
 permission itself. Doing this, there is no real need for the
-framework to keep updated a database of installed permissions.
+framework to keep installed permissions in a database.
 
 The permission names are [URN][URN] of the form:
 
@@ -22,23 +22,23 @@ AGL (note: a RFC should be produced to standardize this name space).
 The permission names are made of NSS (the namespace specific string)
 starting with "permission:" and followed by colon separated
 fields. The 2 first fields are <api> and <level> and the remaining
-fields are gouped to form the <hierarchical-name>.
+fields are grouped to form the <hierarchical-name>.
 
 	<api> ::= [ <pname> ]
-	
+
 	<pname> ::= 1*<pchars>
-	
+
 	<pchars> ::= <upper> | <lower> | <number> | <extra>
-	
+
 	<extra> ::= "-" | "." | "_" | "@"
 
 The field <api> can be made of any valid character for NSS except
-the characters colon and star (:*). This field designate the api
+the characters colon and star (:*). This field designates the api
 providing the permission. This scheme is used to deduce binding requirements
 from permission requirements. The field <api> can be the empty
 string when the permission is defined by the AGL system itself.
 The field <api> if starting with the character "@" represents
-a transversal permission not bound to any binding.
+a transversal/cross permission not bound to any binding.
 
 	<level> ::= 1*<lower>
 
diff --git a/docs/quick-tutorial.md b/docs/quick-tutorial.md
index 29e1029..5fc07f1 100644
--- a/docs/quick-tutorial.md
+++ b/docs/quick-tutorial.md
@@ -4,9 +4,9 @@ AGL Application Framework: A Quick Tutorial
 
 Introduction
 ------------
-This document proposes a quick tutorial to demonstrate the major functionnalities of the AGL Application Framework. For more complete information, please refer to the inline documentation available in the main git repository: 
+This document proposes a quick tutorial to demonstrate the major functionalities of the AGL Application Framework. For more complete information, please refer to the inline documentation available in the main git repository:
 
-[https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-main] 
+[https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-main]
 [https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-binder]
 
 
@@ -50,42 +50,42 @@ We can see that there are two daemons running:
 * **afm-system-daemon** runs with a system user 'afm' and is responsible for installing/uninstalling packages
 * **afm-user-daemon** runs as a user daemon (currently as root because it's the only real user on the target board) and is responsible for the whole lifecycle of the applications running inside the user session.
 
-The application framework has a tool running on the Command Line Interface (CLI). Using the **afm-util** command, you can install, uninstall, list, run, pause ... applications. 
+The application framework has a tool running on the Command Line Interface (CLI). Using the **afm-util** command, you can install, uninstall, list, run, pause ... applications.
 
 To begin, run '**afm-util help**' to get a quick help on commands:
 
     root@porter:~# afm-util help
     usage: afm-util command [arg]
-    
+
     The commands are:
-    
+
       list
       runnables      list the runnable widgets installed
-    
+
       add wgt
       install wgt    install the wgt file
-    
+
       remove id
       uninstall id   remove the installed widget of id
-    
+
       info id
       detail id      print detail about the installed widget of id
-    
+
       ps
       runners        list the running instance
-    
+
       run id
       start id       start an instance of the widget of id
-    
+
       kill rid
       terminate rid  terminate the running instance rid
-    
+
       stop rid
       pause rid      pause the running instance rid
-    
+
       resume rid
       continue rid   resume the previously rid
-    
+
       status rid
       state rid      get status of the running instance rid
 
@@ -93,12 +93,12 @@ To begin, run '**afm-util help**' to get a quick help on commands:
 
 You can then install your first application:
 
-    root@porter:~# afm-util install /home/root/annex.wgt 
+    root@porter:~# afm-util install /home/root/annex.wgt
     { "added": "webapps-annex@0.0" }
 
 Let's install a second application:
 
-    root@porter:~# afm-util install /home/root/memory-match.wgt 
+    root@porter:~# afm-util install /home/root/memory-match.wgt
     { "added": "webapps-memory-match@1.1" }
 
 Note that usually, **afm-util** will return a **JSON result**, which is the common format for messages returned by the Application Framework daemons.
@@ -154,7 +154,7 @@ To pause the application that was just started (the one with RUNID 1), just run
 
     root@porter:~# afm-util terminate 1
     true
-    
+
 The application is now paused, as confirmed by a list of running apps:
 
     root@porter:~# afm-util ps
@@ -177,7 +177,7 @@ afm-client: a sample HTML5 'Homescreen'
 
 **afm-client** is a HTML5 UI that allows to install/uninstall applications as well as starting/pausing them as already demonstrated with afm-util.
 
-The HTML5 UI is accessible remotely through this URL: 
+The HTML5 UI is accessible remotely through this URL:
 http://[board_ip]:1234/opa?token=132456789
 
 ### Installing an application