Doc fix

docs/Addons.md

@@ -1,19 +1,11 @@
-#3rd Party Addons
+# 3rd Party Addons
 
 Though we try to pack Logger full of features we can't do everything. The community has really grown around the product and have started to develop their own projects related around Logger.
 
 This page will serve as a simple listing for such projects. To add your project to the list just update this page and make a pull request.
 
 
-<table>
-  <tr>
-    <th>Name</th>
-    <th>URL</th>
-    <th>Description</th>
-  </tr>
-  <tr>
-    <td>Template Generator</td>
-    <td><a href="https://github.com/alexnuijten/loggerutil" target="_blank">https://github.com/alexnuijten/loggerutil</a></td>
-    <td>Generates logger code for prebuilt procedures. <a href="http://nuijten.blogspot.nl/2015/04/speed-up-development-with-logger.html" target="_blank">Blog article</a>.</td>
-  </tr>
-</table>
+
+Name | URL | Description
+--- | --- | ---
+Template Generator | [github.com/alexnuijten/loggerutil](https://github.com/alexnuijten/loggerutil) | Generates logger code for prebuilt procedures. [Blog article](http://nuijten.blogspot.nl/2015/04/speed-up-development-with-logger.html).

docs/Best Practices.md

@@ -2,7 +2,7 @@
 - [Logger Levels Guide](#logger-level-guide)
 
 <a name="plsql-example"></a>
-##PL/SQL Procedure / Function Template
+## PL/SQL Procedure / Function Template
 
 For packages the recommended practice is as follows:
 
@@ -53,10 +53,10 @@ end pkg_example;
 ```
 
 <a name="logger-level-guide"></a>
-##Logger Levels Guide
+## Logger Levels Guide
 Logger supports multiple logging levels. This section will provide an outline of recommended situations for calling each level. The procedures are ordered in most frequently used to least frequently used.
 
-###Summary
+### Summary
 
 <table>
   <tr>
@@ -100,13 +100,13 @@ Logger supports multiple logging levels. This section will provide an outline of
 *Actionable* means issues that require follow up by a business unit.
 
 
-###Debug / Log
+### Debug / Log
 
 `logger.log` should be used for all developer related content. This can really be anything and everything except for items that require additional investigation. In those situations use the other logging options.
 
 By default, Logger is configured to delete all `debug` level calls after 7 days. As such, developers are encouraged to log as much as they need to with this option. Using other logging levels may result (depending on the settings) in permanent storage and should not be used as frequently.
 
-###Information
+### Information
 `logger.log_info[rmation]` should be used for messages that need to be retained at a higher level than `debug` but are not actionable issues.
 
 Information logging will vary in each organization but should fall between the rules for `debug` and `warning`. An example is to use it for a long running process to highlight some of the following items:
@@ -116,13 +116,13 @@ Information logging will vary in each organization but should fall between the r
 - Number of rows processed
 - When did the process end
 
-###Warning
+### Warning
 `logger.log_warn[ing]` should be used for non-critical system level / business logic issues that are actionable. If it is a critical issue than an error should be raised and `logger.log_error` should be called. An example would be when a non-critical configuration item is missing. In this case a warning message should be logged stating that the configuration option was not set / mssing and the deafult value that the code is using in place.
 
-###Error
+### Error
 `logger.log_error` should be used when a PL/SQL error has occurred. In most cases this is in an exception block. Regardless of any other configuration, `log_error` will store the callstack. Errors are considered actionalble items as an error has occurred and something (code, configuration, server down, etc) needs attention.
 
-###Permanent
+### Permanent
 `logger.log_permanent` should be used for messages that need to be permanently retained. `logger.purge` and `logger.purge_all` will not delete these messages regardless of the `PURGE_MIN_LEVEL` configuration option. Only an implicit delete to `logger_logs` will delete these messages.
 
 An example would be to use this procedure when updating your application to a new version. At the end of the update you can log that the upgrade was successful and the new version number. This way you can find exactly when all the upgrades occurred on your system.

docs/README.md

@@ -2,15 +2,15 @@ The documents have been broken up into the following pages for easier navigation
 
 - [Installation](Installation.md)
 	- All the information to install and configure Logger.
-- [Logger API](Logger API.md)
+- [Logger API](Logger%20API.md)
 	- Complete Logger API documentation.
 - [Plugins](Plugins.md)
 	- Plugin configuration and examples.
-- [Best Practices](Best Practices.md)
+- [Best Practices](Best%20Practices.md)
 	- Set of best practices and suggested code templates to use when leveraging Logger.
-- [Change Logs](Change Logs.md)
+- [Change Logs](Change%20Logs.md)
 	- Set of best practices and suggested code templates to use when leveraging Logger.
-- [Development Guide](Development Guide.md)
+- [Development Guide](Development%20Guide.md)
     - For people who want to help develop Logger.
 - [3rd Party Addons](Addons.md)
-    - Listing of 3rd party products for Logger.
+    - Listing of 3rd party products for Logger.