Documentation format

Change-Id: I4feb44fffce727419660c8ac38c77283b52c695d
Signed-off-by: Romain Forlot <romain.forlot@iot.bzh>

4 files changed, 35 insertions, 22 deletions

diff --git a/docs/part-1/1-Architecture.md b/docs/part-1/1-Architecture.md
index a907882..065d2ec 100644
--- a/docs/part-1/1-Architecture.md
+++ b/docs/part-1/1-Architecture.md
@@ -8,19 +8,24 @@ Here is a quick picture about the signaling architecture :
 
 Key here are on both layer, **low** and **high**.
 
-- **Low level** are in charge of handle a data exchange protocol to decode/encode and retransmit
- with an AGL compatible format, most convenient way using **Application Framework** event. These are divised in two parts, which are :
+- **Low level** are in charge of handle a data exchange protocol to
+ decode/encode and retransmit with an AGL compatible format, most convenient
+ way using **Application Framework** event. These are divised in two parts,
+ which are :
   - Transport Layer plug-in that read/write 1 protocol.
   - Decoding/Encoding part that expose signals and a way to access them.
-- **High level signal composer** gathers multiple **low level** signaling sources and creates new
- virtuals signals from the **raw** signals defined (eg. signal made from gps latitude and
- longitude that calcul the heading of vehicle). It is modular and each signal source should be
- handled by specific plugins which take care of get the underlying event from **low level** or
- define signaling composition with simple or complex operation to output value from **raw** signals
+- **High level signal composer** gathers multiple **low level** signaling
+ sources and creates new virtuals signals from the **raw** signals defined (eg.
+ signal made from gps latitude and longitude that calcul the heading of
+ vehicle). It is modular and each signal source should be handled by specific
+ plugins which take care of get the underlying event from **low level** or
+ define signaling composition with simple or complex operation to output value
+ from **raw** signals
 
 There are three main parts with **Signal Composer**:
 
-- Configuration files which could be splitted in differents files. That will define:
+- Configuration files which could be splitted in differents files. That will
+ define:
   - metadata with name of **signal composer** api name
   - additionnals configurations files
   - plugins used if so, **low level** signals sources
diff --git a/docs/part-1/2-Configuration.md b/docs/part-1/2-Configuration.md
index a68fd62..1bee688 100644
--- a/docs/part-1/2-Configuration.md
+++ b/docs/part-1/2-Configuration.md
@@ -51,25 +51,31 @@ A source is defined with following fields:
 
 - **api**: Name of the source API.
 - **info** (optionnal): self-explanatory
-- **init** (optionnal): an **action** to take to initialize a source. May you have  to call a verb from that API, of create a files etc.
+- **init** (optionnal): an **action** to take to initialize a source. May you
+ have  to call a verb from that API, of create a files etc.
 - **getSignals** (optionnal); an **action** to take to get signals from that
  source. These callback will be used for each signals defined later in the **signals** section. Dedicated arguments for each signal could be defined in
  **signals**.
 
 ## Signals
 
-A signal definition could be either a **raw** one or a **virtual** one. A **virtual signal** is a set of existing **raw signals** associated to an **action**
-on reception which will compute the value of the signal.
+A signal definition could be either a **raw** one or a **virtual** one. A
+ **virtual signal** is a set of existing **raw signals** associated to an
+ **action** on reception which will compute the value of the signal.
 
-- **id**: Unique identifier used inside **signal composer**, used to compose virtual signals.
-- **event**: specify a **raw signal** coming from **low level** sources. Couldn't
- be used with **depends** field, only one of them is possible.
+- **id**: Unique identifier used inside **signal composer**, used to compose
+ virtual signals.
+- **event**: specify a **raw signal** coming from **low level** sources.
+ Couldn't be used with **depends** field, only one of them is possible.
 - **depends**: specify others signals **id** that compose it (eg: heading is
- composed with longitude+latitude signals.). Couldn't be used with **event** field
- at same time.
+ composed with longitude+latitude signals.). Couldn't be used with **event**
+ field at same time.
 - **unit** (optionnal): Unit used to exprime the signal
 - **frequency** (optionnal): Frequency maximum at which the signal could be
- requested or sent. This is a thinning made at **high level** so not best suited for performance. Used **low level** native filtering capabilities when possible.
+ requested or sent. This is a thinning made at **high level** so not best
+ suited for performance. Used **low level** native filtering capabilities when
+ possible.
 - **getSignalsArgs**: a JSON object used at subscription time. Meant to enabled
- filtering capabilities at subscription and to be able to customize in general a subcription request by signal if needed.
+ filtering capabilities at subscription and to be able to customize in general
+ a subcription request by signal if needed.
 - **onReceived**: an **action** to take when this signal is received!
diff --git a/docs/part-1/3-Plugins.md b/docs/part-1/3-Plugins.md
index 1cfb580..cbc7284 100644
--- a/docs/part-1/3-Plugins.md
+++ b/docs/part-1/3-Plugins.md
@@ -1,4 +1,6 @@
 # Plugins
 
-Plugins are C/C++ shared library that is loaded by the binding to execute some simple routine. Routine could be on reception of a new signal or at sources
-initialization time or signal subscription with the respective JSON field **onReceived**, **init** and **getSignals**.
+Plugins are C/C++ shared library that is loaded by the binding to execute some
+simple routine. Routine could be on reception of a new signal or at sources
+initialization time or signal subscription with the respective JSON field
+**onReceived**, **init** and **getSignals**.
diff --git a/docs/part-1/4-SignalComposerAPI.md b/docs/part-1/4-SignalComposerAPI.md
index 6e53800..00dbae4 100644
--- a/docs/part-1/4-SignalComposerAPI.md
+++ b/docs/part-1/4-SignalComposerAPI.md
@@ -11,8 +11,8 @@ signal-composer get {"signal": "vehicle_speed", "options": {"maximum": 10}}
 signal-composer get {"signal": "vehicle_speed"}
 ```
 
-You apply apply some simple mathematical function by default present in the binding
-, by default **last** is used:
+You apply apply some simple mathematical function by default present in the
+binding, by default **last** is used:
 
 - **average**: make an average on X latest seconds.
 - **minimum**: return the minimum value found in the X latest seconds.