Documentation format

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

1 files changed, 13 insertions, 8 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