Merge branch 'doc' into master

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>

1 files changed, 15 insertions, 16 deletions

diff --git a/doc/src/02000-store.md b/doc/src/02000-store.md
index 07334cea..cd22d688 100644
--- a/doc/src/02000-store.md
+++ b/doc/src/02000-store.md
@@ -42,33 +42,34 @@ The following section describe their purpose.
 The header format is where imag stores its data. The header is an area at the
 top of every file which is seperated from the content part by three dashes
 (`---`). Between these three dashes there is structured data. imag uses `TOML`
-as data format for this structured data, because it fits best and the available
-`TOML` parser for the rust programming language is really good.
+as data format for this structured data.
 
 The header can contain any amount of data, but modules (see @sec:modules) are
-restricted in their way of altering the data.
+restricted (by convention) in their way of altering the data.
 
-So normally there are several sections in the header. One section (`[imag]`) is
-always present. It contains a `version` field, which tells imag which version
-this file was created with.
+Normally there are several sections in the header. One section (`[imag]`) is
+always present, it is automatically created by the store and contains a
+`version` field, which tells imag which version this file was created with.
+The store automatically verifies that it is compatible (satisfying semver) with
+the version of imag an entry was created with, and if it is not, it fails
+loading the entry.
 
 Other sections are named like the modules which created them. Every module is
 allowed to store arbitrary data under its own section and a module may never
-read other sections than its own.
+read or write other sections than its own.
 
-These conventions are not enforced by imag itself, though.
 
 ### Content Format {#sec:thestore:fileformat:content}
 
 The content is the part of the file where the user is free to enter any textual
 content. The content may be rendered as Markdown or other markup format for the
-users convenience. The store does never expect and specific markup and actually
-the markup implementation is not inside the very core of imag.
+users convenience. The store does never expect any specific markup.
 
 Technically it would be possible that the content part of a file is used to
 store binary data.
 We don't want this, though, as it is contrary to the goals of imag.
 
+
 ### Example {#sec:thestore:fileformat:example}
 
 An example for a file in the store follows.
@@ -96,15 +97,13 @@ The "Entries" are stored as files in the "Store", which is a directory the
 user has access to.  The store may exist in the users Home-directory or any
 other directory the user has read-write-access to.
 
-Each module stores its data in an own subdirectory in the store. This is because
-we like to keep things ordered and clean, not because it is technically
-necessary.
+Each module stores its data in an own subdirectory in the store, by convention.
 
-We name the path to a file in the store "Store id" or "Storepath" and we often
+The path to a file in the store is named "Store id" (or short "ID") and we
 refer to it by using the store location as root.
-So if the store exists in `/home/user/store/`, a file with the storepath
+So if the store exists in `/home/user/.imag/store/`, a file with the storepath
 `example.file` is (on the filesystem) located at
-`/home/user/store/example.file`.
+`/home/user/.imag/store/example.file`.
 
 By convention, each `libimagentry<name>` and `libimag<name>` module stores its
 entries in in `<name>/`.