Update Design Principles

Language cleaned up by the technical writers xsipewe and tmanevik
from Combitech. Proofreading and corrections by Björn Gustavsson.

1 files changed, 98 insertions, 92 deletions

diff --git a/system/doc/design_principles/release_structure.xml b/system/doc/design_principles/release_structure.xml
index cec33f42e3..aa04f5e6a3 100644
--- a/system/doc/design_principles/release_structure.xml
+++ b/system/doc/design_principles/release_structure.xml
@@ -28,21 +28,23 @@
     <rev></rev>
     <file>release_structure.xml</file>
   </header>
-  <p>This chapter should be read in conjuction with <c>rel(4)</c>,
-    <c>systools(3)</c> and <c>script(4)</c>.</p>
+  <marker id="releases section"></marker>
+  <p>This section is to be read with the <c>rel(4)</c>, <c>systools(3)</c>,
+  and <c>script(4)</c> manual pages in SASL.</p>
 
   <section>
     <title>Release Concept</title>
-    <p>When we have written one or more applications, we might want to
-      create a complete system consisting of these applications and a
+    <p>When you have written one or more applications, you might want
+      to create a complete system with these applications and a
       subset of the Erlang/OTP applications. This is called a
       <em>release</em>.</p>
-    <p>To do this, we create a <seealso marker="#res_file">release resource file</seealso> which defines which applications
-      are included in the release.</p>
+    <p>To do this, create a
+    <seealso marker="#res_file">release resource file</seealso> that
+      defines which applications are included in the release.</p>
     <p>The release resource file is used to generate
       <seealso marker="#boot">boot scripts</seealso> and
       <seealso marker="#pack">release packages</seealso>. A system
-      which is transfered to and installed at another site is called a
+      that is transferred to and installed at another site is called a
       <em>target system</em>. How to use a release package to create a
       target system is described in System Principles.</p>
   </section>
@@ -50,29 +52,30 @@
   <section>
     <marker id="res_file"></marker>
     <title>Release Resource File</title>
-    <p>To define a release, we create a <em>release resource file</em>,
-      or in short <c>.rel</c> file, where we specify the name and
-      version of the release, which ERTS version it is based on, and
-      which applications it consists of:</p>
+    <p>To define a release, create a <em>release resource file</em>,
+      or in short a <c>.rel</c> file. In the file, specify the name and
+      version of the release, which ERTS version it is based on,
+      and which applications it consists of:</p>
     <code type="none">
 {release, {Name,Vsn}, {erts, EVsn},
  [{Application1, AppVsn1},
    ...
   {ApplicationN, AppVsnN}]}.</code>
+    <p><c>Name</c>, <c>Vsn</c>, <c>EVsn</c>, and <c>AppVsn</c> are
+    strings.</p>
     <p>The file must be named <c>Rel.rel</c>, where <c>Rel</c> is a
       unique name.</p>
-    <p><c>Name</c>, <c>Vsn</c> and <c>EVsn</c> are strings.</p>
-    <p>Each <c>Application</c> (atom) and <c>AppVsn</c> (string) is
+    <p>Each <c>Application</c> (atom) and <c>AppVsn</c> is
       the name and version of an application included in the release.
-      Note that the minimal release based on Erlang/OTP consists of
-      the <c>kernel</c> and <c>stdlib</c> applications, so these
+      The minimal release based on Erlang/OTP consists of
+      the Kernel and STDLIB applications, so these
       applications must be included in the list.</p>
     <p>If the release is to be upgraded, it must also include
-      the <c>sasl</c> application.</p>
+      the SASL application.</p>
     <marker id="ch_rel"></marker>
-    <p>Example: We want to make a release of <c>ch_app</c> from
-      the <seealso marker="applications#ch_app">Applications</seealso>
-      chapter. It has the following <c>.app</c> file:</p>
+    <p><em>Example: </em> A release of <c>ch_app</c> from
+      <seealso marker="applications#ch_app">Applications</seealso>
+      has the following <c>.app</c> file:</p>
     <code type="none">
 {application, ch_app,
  [{description, "Channel allocator"},
@@ -83,8 +86,8 @@
   {mod, {ch_app,[]}}
  ]}.</code>
     <p>The <c>.rel</c> file must also contain <c>kernel</c>,
-      <c>stdlib</c> and <c>sasl</c>, since these applications are
-      required by <c>ch_app</c>. We call the file <c>ch_rel-1.rel</c>:</p>
+      <c>stdlib</c>, and <c>sasl</c>, as these applications are required
+      by <c>ch_app</c>. The file is called <c>ch_rel-1.rel</c>:</p>
     <code type="none">
 {release,
  {"ch_rel", "A"},
@@ -99,24 +102,28 @@
   <section>
     <marker id="boot"></marker>
     <title>Generating Boot Scripts</title>
-    <p>There are tools in the SASL module <c>systools</c> available to
-      build and check releases. The functions read the <c>.rel</c> and
+    <p><c>systools</c> in the SASL application includes tools to
+      build and check releases. The functions read the <c>rel</c> and
       <c>.app</c> files and performs syntax and dependency checks.
-      The function <c>systools:make_script/1,2</c> is used to generate
-      a boot script (see System Principles).</p>
+      The <c>systools:make_script/1,2</c> function is used to generate
+      a boot script (see System Principles):</p>
     <pre>
 1> <input>systools:make_script("ch_rel-1", [local]).</input>
 ok</pre>
-    <p>This creates a boot script, both the readable version
-      <c>ch_rel-1.script</c> and the binary version used by the runtime
-      system, <c>ch_rel-1.boot</c>. <c>"ch_rel-1"</c> is the name of
-      the <c>.rel</c> file, minus the extension. <c>local</c> is an
-      option that means that the directories where the applications are
-      found are used in the boot script, instead of <c>$ROOT/lib</c>.
-      (<c>$ROOT</c> is the root directory of the installed release.)
-      This is a useful way to test a generated boot script locally.</p>
+    <p>This creates a boot script, both the readable version,
+    <c>ch_rel-1.script</c>, and the binary version, <c>ch_rel-1.boot</c>,
+    used by the runtime system.</p>
+    <list type="bulleted">
+      <item><c>"ch_rel-1"</c> is the name of the <c>.rel</c> file,
+      minus the extension.</item>
+      <item><c>local</c> is an option that means that the directories
+      where the applications are found are used in the boot script,
+      instead of <c>$ROOT/lib</c> (<c>$ROOT</c> is the root directory
+      of the installed release).</item>
+    </list>
+    <p> This is a useful way to test a generated boot script locally.</p>
     <p>When starting Erlang/OTP using the boot script, all applications
-      from the <c>.rel</c> file are automatically loaded and started:</p>
+    from the <c>.rel</c> file are automatically loaded and started:</p>
     <pre>
 % <input>erl -boot ch_rel-1</input>
 Erlang (BEAM) emulator version 5.3
@@ -147,18 +154,24 @@ Eshell V5.3  (abort with ^G)
   <section>
     <marker id="pack"></marker>
     <title>Creating a Release Package</title>
-    <p>There is a function <c>systools:make_tar/1,2</c> which takes
-      a <c>.rel</c> file as input and creates a zipped tar-file with
-      the code for the specified applications, a <em>release package</em>.</p>
+    <p>The <c>systools:make_tar/1,2</c> function takes a <c>.rel</c> file
+    as input and creates a zipped tar file with the code for the specified
+    applications, a <em>release package</em>:</p>
     <pre>
 1> <input>systools:make_script("ch_rel-1").</input>
 ok
 2> <input>systools:make_tar("ch_rel-1").</input>
 ok</pre>
-    <p>The release package by default contains the <c>.app</c> files and
-      object code for all applications, structured according to
-      the <seealso marker="applications#app_dir">application directory structure</seealso>, the binary boot script renamed to
-      <c>start.boot</c>, and the <c>.rel</c> file.</p>
+   <p>The release package by default contains:</p>
+   <list type="bulleted">
+     <item>The <c>.app</c> files</item>
+     <item>The <c>.rel</c> file</item>
+     <item>The object code for all applications, structured according
+     to the
+     <seealso marker="applications#app_dir">application directory
+     structure</seealso></item>
+     <item>The binary boot script renamed to <c>start.boot</c></item>
+   </list>
     <pre>
 % <input>tar tf ch_rel-1.tar</input>
 lib/kernel-2.9/ebin/kernel.app
@@ -177,40 +190,39 @@ lib/ch_app-1/ebin/ch3.beam
 releases/A/start.boot
 releases/A/ch_rel-1.rel
 releases/ch_rel-1.rel</pre>
-    <p>Note that a new boot script was generated, without
+    <p>A new boot script was generated, without
       the <c>local</c> option set, before the release package was made.
       In the release package, all application directories are placed
-      under <c>lib</c>. Also, we do not know where the release package
-      will be installed, so we do not want any hardcoded absolute paths
-      in the boot script here.</p>
+      under <c>lib</c>. You do not know where the release package
+      will be installed, so no hard-coded absolute paths are allowed.</p>
     <p>The release resource file <c>mysystem.rel</c> is duplicated in
       the tar file. Originally, this file was only stored in
-      the <c>releases</c> directory in order to make it possible for
+      the <c>releases</c> directory to make it possible for
       the <c>release_handler</c> to extract this file
       separately. After unpacking the tar file, <c>release_handler</c>
       would automatically copy the file
       to <c>releases/FIRST</c>. However, sometimes the tar file is
-      unpacked without involving the <c>release_handler</c> (e.g. when
-      unpacking the first target system) and therefore the file is now
-      instead duplicated in the tar file so no manual copying is
-      necessary.</p>
+      unpacked without involving the <c>release_handler</c> (for
+      example, when unpacking the first target system) and the file
+      is therefore now instead duplicated in the tar file so no manual
+      copying is necessary.</p>
     <p>If a <c>relup</c> file and/or a system configuration file called
-      <c>sys.config</c> is found, these files are included in
-      the release package as well. See
+      <c>sys.config</c> is found, these files are also included in
+      the release package. See
       <seealso marker="release_handling#req">Release Handling</seealso>.</p>
     <p>Options can be set to make the release package include source
       code and the ERTS binary as well.</p>
-    <p>Refer to System Principles for how to install the first target
-      system, using a release package, and to
-      <seealso marker="release_handling">Release Handling</seealso> for
-      how to install a new release package in an existing system.</p>
+    <p>For information on how to install the first target system, using
+      a release package, see System Principles. For information
+      on how to install a new release package in an existing system, see
+      <seealso marker="release_handling">Release Handling</seealso>.</p>
   </section>
 
   <section>
     <marker id="reldir"></marker>
     <title>Directory Structure</title>
-    <p>Directory structure for the code installed by the release handler
-      from a release package:</p>
+    <p>The directory structure for the code installed by the release handler
+      from a release package is as follows:</p>
     <code type="none">
 $ROOT/lib/App1-AVsn1/ebin
                     /priv
@@ -222,24 +234,18 @@ $ROOT/lib/App1-AVsn1/ebin
      /erts-EVsn/bin
      /releases/Vsn
      /bin</code>
-    <taglist>
-      <tag><c>lib</c></tag>
-      <item>Application directories.</item>
-      <tag><c>erts-EVsn/bin</c></tag>
-      <item>Erlang runtime system executables.</item>
-      <tag><c>releases/Vsn</c></tag>
-      <item><c>.rel</c> file and boot script <c>start.boot</c>.      <br></br>
-
-       If present in the release package,      <br></br>
-<c>relup</c> and/or <c>sys.config</c>.</item>
-      <tag><c>bin</c></tag>
-      <item>Top level Erlang runtime system executables.</item>
-    </taglist>
-    <p>Applications are not required to be located under the
-      <c>$ROOT/lib</c> directory. Accordingly, several installation
-      directories may exist which contain different parts of a
-      system. For example, the previous example could be extended as
-      follows:</p>
+     <list type="bulleted">
+       <item><c>lib</c> - Application directories</item>
+       <item><c>erts-EVsn/bin</c> - Erlang runtime system executables</item>
+       <item><c>releases/Vsn</c> - <c>.rel</c> file and boot script
+       <c>start.boot</c>; if present in the release package, <c>relup</c>
+       and/or <c>sys.config</c></item>
+       <item><c>bin</c> - Top-level Erlang runtime system executables</item>
+     </list>
+    <p>Applications are not required to be located under directory
+      <c>$ROOT/lib</c>. Several installation directories, which contain
+      different parts of a system, can thus exist.
+      For example, the previous example can be extended as follows:</p>
     <pre>
 $SECOND_ROOT/.../SApp1-SAVsn1/ebin
                              /priv
@@ -256,24 +262,24 @@ $THIRD_ROOT/TApp1-TAVsn1/ebin
            ...
            /TAppN-TAVsnN/ebin
                         /priv</pre>
-    <p>The <c>$SECOND_ROOT</c> and <c>$THIRD_ROOT</c> are introduced as
+    <p><c>$SECOND_ROOT</c> and <c>$THIRD_ROOT</c> are introduced as
       <c>variables</c> in the call to the <c>systools:make_script/2</c>
       function.</p>
 
     <section>
       <title>Disk-Less and/or Read-Only Clients</title>
-      <p>If a complete system consists of some disk-less and/or
-        read-only client nodes, a <c>clients</c> directory should be
-        added to the <c>$ROOT</c> directory. By a read-only node we
-        mean a node with a read-only file system.</p>
-      <p>The <c>clients</c> directory should have one sub-directory
+      <p>If a complete system consists of disk-less and/or
+        read-only client nodes, a <c>clients</c> directory is to be
+        added to the <c>$ROOT</c> directory. A read-only node is
+        a node with a read-only file system.</p>
+      <p>The <c>clients</c> directory is to have one subdirectory
         per supported client node. The name of each client directory
-        should be the name of the corresponding client node. As a
-        minimum, each client directory should contain the <c>bin</c> and
-        <c>releases</c> sub-directories. These directories are used to
+        is to be the name of the corresponding client node. As a
+        minimum, each client directory is to contain the <c>bin</c> and
+        <c>releases</c> subdirectories. These directories are used to
         store information about installed releases and to appoint the
-        current release to the client. Accordingly, the <c>$ROOT</c>
-        directory contains the following:</p>
+        current release to the client. The <c>$ROOT</c>
+        directory thus contains the following:</p>
       <code type="none">
 $ROOT/...
     /clients/ClientName1/bin
@@ -283,14 +289,14 @@ $ROOT/...
             ...
             /ClientNameN/bin
                         /releases/Vsn</code>
-      <p>This structure should be used if all clients are running
+      <p>This structure is to be used if all clients are running
         the same type of Erlang machine. If there are clients running
         different types of Erlang machines, or on different operating
-        systems, the <c>clients</c> directory could be divided into one
-        sub-directory per type of Erlang machine. Alternatively, you
-        can set up one <c>$ROOT</c> per type of machine. For each
+        systems, the <c>clients</c> directory can be divided into one
+        subdirectory per type of Erlang machine. Alternatively, one
+	<c>$ROOT</c> can be set up per type of machine. For each
         type, some of the directories specified for the <c>$ROOT</c>
-        directory should be included:</p>
+        directory are to be included:</p>
       <code type="none">
 $ROOT/...
     /clients/Type1/lib