Merge branch 'siri/sasl/improve-doc/OTP-9294'

* siri/sasl/improve-doc/OTP-9294:
  Add all valid report types in documentation of rb:list
  Fix minor faults in documentation of release handling
  Rename create_target.xml to create_target.xmlsrc to prepare for codeinclude

2 files changed, 15 insertions, 12 deletions

diff --git a/lib/sasl/doc/src/rb.xml b/lib/sasl/doc/src/rb.xml
index f35ceb5777..3da825878e 100644
--- a/lib/sasl/doc/src/rb.xml
+++ b/lib/sasl/doc/src/rb.xml
@@ -4,7 +4,7 @@
 <erlref>
   <header>
     <copyright>
-      <year>1996</year><year>2010</year>
+      <year>1996</year><year>2011</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -123,7 +123,9 @@
       <fsummary>List all reports</fsummary>
       <type>
         <v>Type = type()</v>
-        <v>type() = crash_report | supervisor_report | error | progress</v>
+        <v>type() = error | error_report | info_msg | info_report |
+        warning_msg | warning_report | crash_report |
+        supervisor_report | progress</v>
       </type>
       <desc>
         <p>This function lists all reports loaded in the
diff --git a/lib/sasl/doc/src/release_handler.xml b/lib/sasl/doc/src/release_handler.xml
index bd4a513750..e3438ede41 100644
--- a/lib/sasl/doc/src/release_handler.xml
+++ b/lib/sasl/doc/src/release_handler.xml
@@ -64,10 +64,10 @@
       downgraded to the specified version by evaluating the instructions
       in <c>relup</c>. An installed release can be made
       <em>permanent</em>. There can only be one permanent release in
-      the system, and this is the release that is used if the system is
-      restarted. An installed release, except the permanent one, can be
-      <em>removed</em>. When a release is removed, all files that
-      belong to that release only are deleted.</p>
+      the system, and this is the release that is used if the system
+      is restarted. An installed release, except the permanent one,
+      can be <em>removed</em>. When a release is removed, all files
+      that belong to that release only are deleted.</p>
     <p>Each version of the release has a status. The status can be
       <c>unpacked</c>, <c>current</c>, <c>permanent</c>, or <c>old</c>.
       There is always one latest release which either has status
@@ -107,16 +107,17 @@ old        reboot_old            permanent
       restarted. This is taken care of automatically if Erlang is
       started as an embedded system. Read about this in <em>Embedded System</em>. In this case, the system configuration file
       <c>sys.config</c> is mandatory.</p>
-    <p>A new release may restart the system. Which program to use is
-      specified by the SASL configuration parameter <c>start_prg</c>
-      which defaults to <c>$ROOT/bin/start</c>.</p>
+    <p>The installation of a new release may restart the system. Which
+      program to use is specified by the SASL configuration
+      parameter <c>start_prg</c> which defaults
+      to <c>$ROOT/bin/start</c>.</p>
     <p>The emulator restart on Windows NT expects that the system is
       started using the <c>erlsrv</c> program (as a service).
       Furthermore the release handler expects that the service is named 
       <em>NodeName</em>_<em>Release</em>, where <em>NodeName</em> is
       the first part of the Erlang nodename (up to, but not including
-      the "@") and <em>Release</em> is the current release of
-      the application. The release handler furthermore expects that a
+      the "@") and <em>Release</em> is the current version of
+      the release. The release handler furthermore expects that a
       program like <c>start_erl.exe</c> is specified as "machine" to
       <c>erlsrv</c>. During upgrading with restart, a new service will
       be registered and started. The new service will be set to
@@ -484,7 +485,7 @@ release_handler:set_unpacked(RelFile, [{myapp,"1.0","/home/user"},...]).
         <c>release_handler</c> to end up in an inconsistent state.</p>
       <p>No persistent information is updated, why these functions can
         be used on any Erlang node, embedded or not. Also, using these
-        functions does not effect which code will be loaded in case of
+        functions does not affect which code will be loaded in case of
         a reboot.</p>
       <p>If the upgrade or downgrade fails, the application may end up
         in an inconsistent state.</p>