Various doucmentation fixes.

Change-Id: I705dadabfdefaf9ce86bb1413e20daa3d8a84785
Reviewed-on: http://fulliautomatix.ics.uci.edu:8443/198
Tested-by: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Reviewed-by: Till Westmann <westmann@gmail.com>
Reviewed-by: Taewoo Kim <wangsaeu@gmail.com>
diff --git a/asterix-doc/src/site/markdown/aql/filters.md b/asterix-doc/src/site/markdown/aql/filters.md
index 6c29b62..67746ef 100644
--- a/asterix-doc/src/site/markdown/aql/filters.md
+++ b/asterix-doc/src/site/markdown/aql/filters.md
@@ -1,13 +1,13 @@
-# Filter-Based LSM Index Acceleration #
+# Filter-Based LSM Index Acceleration
 
-## <a id="toc">Table of Contents</a> ##
+## <a id="toc">Table of Contents</a>
 
 * [Motivation](#Motivation)
 * [Filters in AsterixDB](#FiltersInAsterixDB)
 * [Filters and Merge Policies](#FiltersAndMergePolicies)
 
 ## <a id="Motivation">Motivation</a> <font size="4"><a
-   href="#toc">[Back to TOC]</a></font> ##
+   href="#toc">[Back to TOC]</a></font>
 
 Traditional relational databases usually employ conventional index
 structures such as B+ trees due to their low read latency.  However,
@@ -19,15 +19,14 @@
 LevelDB, BigTable, etc. have adopted Log-Structured Merge (LSM) Trees
 as their storage structure. LSM-trees avoids the cost of random writes
 by batching updates into a component of the index that resides in main
-memory -- an \textit{in-memory component}. When the space occupancy of
+memory -- an *in-memory component*. When the space occupancy of
 the in-memory component exceeds a specified threshold, its entries are
-\textit{flushed} to disk forming a new component -- a \textit{disk
-component}. As disk components accumulate on disk, they are
-periodically merged together subject to a \textit{merge policy} that
-decides when and what to merge. The benefit of the LSM-trees comes at
-the cost of possibly sacrificing read efficiency, but, it has been
-shown in previous studies that these inefficiencies can be mostly
-mitigated.
+*flushed* to disk forming a new component -- a *disk component*. As
+disk components accumulate on disk, they are periodically merged
+together subject to a *merge policy* that decides when and what to
+merge. The benefit of the LSM-trees comes at the cost of possibly
+sacrificing read efficiency, but, it has been shown in previous
+studies that these inefficiencies can be mostly mitigated.
 
 AsterixDB has also embraced LSM-trees, not just by using them as
 primary indexes, but also by using the same LSM-ification technique
@@ -37,7 +36,7 @@
 LSM-based secondary indexes, allowing higher data ingestion rates. In
 fact, for certain index structures, our results have shown that using
 an LSM-based version of an index can be made to significantly
-outperform its conventional counterpart for \textit{both} ingestion
+outperform its conventional counterpart for *both* ingestion
 and query speed (an example of such an index being the R-tree for
 spatial data).
 
@@ -69,7 +68,7 @@
 power.
 
 ## <a id="FiltersInAsterixDB">Filters in AsterixDB</a> <font
-   size="4"><a href="#toc">[Back to TOC]</a></font> ##
+   size="4"><a href="#toc">[Back to TOC]</a></font>
 
 
 We have added support for LSM-based filters to all of AsterixDB's
@@ -87,7 +86,7 @@
 
 
 When a dataset with a filter is created, the name of the filter's key
-field is persisted in the ``dataset'' dataset (which is the metadata
+field is persisted in the `Metadata.Dataset` dataset (which is the metadata
 dataset that stores the details of each dataset in an AsterixDB
 instance) so that DML operations against the dataset can recognize the
 existence of filters and can update them or utilize them
@@ -100,8 +99,8 @@
 when a query has predicates on the filter's key).
 
 
-## <a id="FiltersAndMergePolicies">Filters and Merge Policies</a>
-   <font size="4"><a href="#toc">[Back to TOC]</a></font> ##
+## <a id="FiltersAndMergePolicies">Filters and Merge Policies</a> <font
+size="4"><a href="#toc">[Back to TOC]</a></font>
 
 
 The AsterixDB default merge policy, the prefix merge policy, relies on
diff --git a/asterix-doc/src/site/markdown/install.md b/asterix-doc/src/site/markdown/install.md
index d2199c4..5947710 100644
--- a/asterix-doc/src/site/markdown/install.md
+++ b/asterix-doc/src/site/markdown/install.md
@@ -187,29 +187,10 @@
 ### Configuring Managix ###
 You will need the AsterixDB installer (a.k.a. Managix). Download Managix from [here](http://asterixdb.ics.uci.edu/download.html); this includes the bits for Managix as well as AsterixDB.
 
-Unzip the Managix zip bundle to an appropriate location. You may create a sub-directory called "asterix-mgmt" (short for asterix-management) under your home directory. We shall refer to this location as MANAGIX_HOME.
-
-
-          $ cd ~
-          /home/joe> $ mkdir asterix-mgmt
-          /home/joe> $ cd asterix-mgmt
-          /home/joe/asterix-mgmt> $ unzip  <path to the Managix zip bundle>
-          /home/joe/asterix-mgmt> $ export MANAGIX_HOME=`pwd`
-          /home/joe/asterix-mgmt> $ export PATH=$PATH:$MANAGIX_HOME/bin
-
-It is recommended that you add $MANAGIX_HOME/bin to your PATH variable in your bash profile . This step can be done by executing the following.
-
-
-        currentDir=`pwd`
-        echo "export MANAGIX_HOME=$currentDir" >> ~/.bash_profile
-        echo "export PATH=$PATH:$MANAGIX_HOME/bin" >> ~/.bash_profile
-
-Above, use ~/.bashrc instead of ~/.bash_profile if you are using ~/.bashrc .
-
 To be able to create an AsterixDB instance and manage its lifecycle, the Managix requires you to configure a set of configuration files namely:
 
  * `conf/managix-conf.xml`:  A configuration XML file that contains configuration settings for Managix.
- * A configuration XML file that describes the nodes in the cluster, e.g., `$MANAGIX_HOME/clusters/local/local.xml`.
+ * A configuration XML file that describes the nodes in the cluster, e.g., `clusters/local/local.xml`.
 
 Since we intend to run AsterixDB on a single node, Managix can auto-configure itself and populate the above configuration files.  To auto-configure Managix, execute the following in the MANAGIX_HOME directory:
 
@@ -224,7 +205,7 @@
           INFO: Managix Configuration [OK]
 
 
-        /home/joe/asterix-mgmt> $ managix validate -c $MANAGIX_HOME/clusters/local/local.xml
+        /home/joe/asterix-mgmt> $ managix validate -c clusters/local/local.xml
           INFO: Environment [OK]
           INFO: Cluster configuration [OK]
 
@@ -242,7 +223,7 @@
 We shall now use the `create` command to create an AsterixDB instance by the name "my_asterix". In doing so, we shall use the cluster configuration file that was auto-generated by Managix.
 
 
-         $ managix create -n my_asterix -c $MANAGIX_HOME/clusters/local/local.xml
+         $ managix create -n my_asterix -c clusters/local/local.xml
 
 A sample output of the above command is shown below:
 
@@ -481,8 +462,6 @@
         machineA> mkdir asterix-mgmt
         machineA> cd asterix-mgmt
         machineA> unzip  <path to the Managix zip bundle>
-        machineA> export MANAGIX_HOME=`pwd`
-        machineA> export PATH=$PATH:$MANAGIX_HOME/bin
 
 Note that it is recommended that MANAGIX_HOME is not located on a network file system (NFS). Managix creates artifacts/logs that are not required to be shared. Any overhead
 associated with creating artifacts/logs on the NFS should be avoided.
@@ -490,7 +469,7 @@
 We also need an AsterixDB configuration XML file for the cluster.  We give the name to the cluster, say, "rainbow".  We create a folder for the configuration of this cluster:
 
 
-        machineA> mkdir $MANAGIX_HOME/rainbow_cluster
+        machineA> mkdir asterix-mgmt/rainbow_cluster
 
 
 For this cluster we create a configuration file `$MANAGIX_HOME/rainbow_cluster/rainbow.xml`.  The following is a sample file with explanation of the properties:
@@ -563,7 +542,7 @@
 
 Once we have formed the cluster XML file, we can validate the configuration by doing the following:
 
-        managix validate -c $MANAGIX_HOME/rainbow_cluster/rainbow.xml
+        managix validate -c rainbow_cluster/rainbow.xml
 
 This will verify the contents of the file, and also attempt to ssh to each node in the cluster to ensure that password-less SSH is configured correctly. You may see output like
 
@@ -614,7 +593,7 @@
 We shall now use the `create` command to create an AsterixDB instance called "rainbow_asterix". In doing so, we shall use the cluster configuration file that was auto-generated by Managix.
 
 
-        machineA> managix create -n rainbow_asterix -c $MANAGIX_HOME/clusters/rainbow.xml
+        machineA> managix create -n rainbow_asterix -c clusters/rainbow.xml
 
 
 If the response message does not have warning, then Congratulations! You have successfully installed AsterixDB on this cluster of machines!
@@ -925,14 +904,14 @@
 
 1) Get rid of the Asterix processes running on the nodes in the cluster:-
 
-        $MANAGIX_HOME/bin/managix stop -n my_asterix
+        managix stop -n my_asterix
 
 
 The processes associated with the instance are terminated and the instance moves to the INACTIVE state.
 
 2) Start the AsterixDB instance using the start command.
 
-        $MANAGIX_HOME/bin/managix start -n <name of your AsterixDB instance>
+        managix start -n <name of your AsterixDB instance>
 
 
 ##### Question #####
@@ -967,7 +946,7 @@
 
 step 2) managix shutdown
 
-step 3) copy asterix-server zip (version v2) to $MANAGIX_HOME/asterix/
+step 3) copy asterix-server zip (version v2) to asterix/
 
 step 4) managix start -n a1