diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md
index 6dd81bf..f8e999b 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md
@@ -23,74 +23,74 @@
 
 * [1. Introduction](#Introduction)
 * [2. Expressions](#Expressions)
-      * [Operator expressions](#Operator_expressions)
-           * [Arithmetic operators](#Arithmetic_operators)
-           * [Collection operators](#Collection_operators)
-           * [Comparison operators](#Comparison_operators)
-           * [Logical operators](#Logical_operators)
-      * [Case expressions](#Case_expressions)
-      * [Quantified expressions](#Quantified_expressions)
-      * [Path expressions](#Path_expressions)
-      * [Primary expressions](#Primary_expressions)
+      * [Operator Expressions](#Operator_expressions)
+           * [Arithmetic Operators](#Arithmetic_operators)
+           * [Collection Operators](#Collection_operators)
+           * [Comparison Operators](#Comparison_operators)
+           * [Logical Operators](#Logical_operators)
+      * [Case Expressions](#Case_expressions)
+      * [Quantified Expressions](#Quantified_expressions)
+      * [Path Expressions](#Path_expressions)
+      * [Primary Expressions](#Primary_expressions)
            * [Literals](#Literals)
-           * [Variable references](#Variable_references)
-           * [Parenthesized expressions](#Parenthesized_expressions)
-           * [Function call expressions](#Function_call_expressions)
+           * [Variable References](#Variable_references)
+           * [Parenthesized Expressions](#Parenthesized_expressions)
+           * [Function call Expressions](#Function_call_expressions)
            * [Constructors](#Constructors)
 * [3. Queries](#Queries)
-      * [SELECT statements](#SELECT_statements)
-      * [SELECT clauses](#Select_clauses)
-           * [Select element/value/raw](#Select_element)
-           * [SQL-style select](#SQL_select)
+      * [SELECT Statements](#SELECT_statements)
+      * [SELECT Clauses](#Select_clauses)
+           * [Select Element/Value/Raw](#Select_element)
+           * [SQL-style Select](#SQL_select)
            * [Select *](#Select_star)
-           * [Select distinct](#Select_distinct)
-           * [Unnamed projections](#Unnamed_projections)
-           * [Abbreviatory field access expressions](#Abbreviatory_field_access_expressions)
-      * [UNNEST clauses](#Unnest_clauses)
-           * [Inner unnests](#Inner_unnests)
-           * [Left outer unnests](#Left_outer_unnests)
-           * [Expressing joins using unnests](#Expressing_joins_using_unnests)
+           * [Select Distinct](#Select_distinct)
+           * [Unnamed Projections](#Unnamed_projections)
+           * [Abbreviatory Field Access Expressions](#Abbreviatory_field_access_expressions)
+      * [UNNEST Clauses](#Unnest_clauses)
+           * [Inner Unnests](#Inner_unnests)
+           * [Left Outer Unnests](#Left_outer_unnests)
+           * [Expressing Joins Using Unnests](#Expressing_joins_using_unnests)
       * [FROM clauses](#From_clauses)
-           * [Binding expressions](#Binding_expressions)
-           * [Multiple from terms](#Multiple_from_terms)
-           * [Expressing joins using from terms](#Expressing_joins_using_from_terms)
-           * [Implicit binding variables](#Implicit_binding_variables)
-      * [JOIN clauses](#Join_clauses)
-           * [Inner joins](#Inner_joins)
-           * [Left outer joins](#Left_outer_joins)
-      * [GROUP BY clauses](#Group_By_clauses)
-           * [Group variables](#Group_variables)
-           * [Implicit group key variables](#Implicit_group_key_variables)
-           * [Implicit group variables](#Implicit_group_variables)
-           * [Aggregation functions](#Aggregation_functions)
-           * [SQL-92 aggregation functions](#SQL-92_aggregation_functions)
-           * [SQL-92 compliant GROUP BY aggregations](#SQL-92_compliant_gby)
-           * [Column aliases](#Column_aliases)
-      * [WHERE clauases and HAVING clauses](#Where_having_clauses)
-      * [ORDER BY clauses](#Order_By_clauses)
-      * [LIMIT clauses](#Limit_clauses)
-      * [WITH clauses](#With_clauses)
-      * [LET clauses](#Let_clauses)
+           * [Binding Expressions](#Binding_expressions)
+           * [Multiple From Terms](#Multiple_from_terms)
+           * [Expressing Joins Using From Terms](#Expressing_joins_using_from_terms)
+           * [Implicit Binding Variables](#Implicit_binding_variables)
+      * [JOIN Clauses](#Join_clauses)
+           * [Inner Joins](#Inner_joins)
+           * [Left Outer Joins](#Left_outer_joins)
+      * [GROUP BY Clauses](#Group_By_clauses)
+           * [Group Variables](#Group_variables)
+           * [Implicit Group Key Variables](#Implicit_group_key_variables)
+           * [Implicit Group Variables](#Implicit_group_variables)
+           * [Aggregation Functions](#Aggregation_functions)
+           * [SQL-92 Aggregation Functions](#SQL-92_aggregation_functions)
+           * [SQL-92 Compliant GROUP BY Aggregations](#SQL-92_compliant_gby)
+           * [Column Aliases](#Column_aliases)
+      * [WHERE Clauses and HAVING Clauses](#Where_having_clauses)
+      * [ORDER BY Clauses](#Order_By_clauses)
+      * [LIMIT Clauses](#Limit_clauses)
+      * [WITH Clauses](#With_clauses)
+      * [LET Clauses](#Let_clauses)
       * [UNION ALL](#Union_all)
       * [SQL++ Vs. SQL-92](#Vs_SQL-92)
 * [4. Errors](#Errors)
-      * [Syntax errors](#Syntax_errors)
-      * [Identifier resolution errors](#Parsing_errors)
-      * [Type errors](#Type_errors)
-      * [Resource errors](#Resource_errors)
-* [5. DDL and DML statements](#DDL_and_DML_statements)
+      * [Syntax Errors](#Syntax_errors)
+      * [Identifier Resolution Errors](#Parsing_errors)
+      * [Type Errors](#Type_errors)
+      * [Resource Errors](#Resource_errors)
+* [5. DDL and DML Statements](#DDL_and_DML_statements)
       * [Declarations](#Declarations)
-      * [Lifecycle management statements](#Lifecycle_management_statements)
+      * [Lifecycle Management Statements](#Lifecycle_management_statements)
            * [Dataverses](#Dataverses)
            * [Datasets](#Datasets)
            * [Types](#Types)
            * [Functions](#Functions)
-      * [Modification statements](#Modification_statements)
+      * [Modification Statements](#Modification_statements)
            * [Inserts](#Inserts)
            * [Upserts](#Upserts)
            * [Deletes](#Deletes)
-* [Appendix 1. Reserved keywords](#Reserved_keywords)
-* [Appendix 2. Performance tuning](#Performance_tuning)
-      * [Parallelism parameter](#Parallelism_parameter)
-      * [Memory parameters](#Memory_parameters)
+* [Appendix 1. Reserved Keywords](#Reserved_keywords)
+* [Appendix 2. Performance Tuning](#Performance_tuning)
+      * [Parallelism Parameter](#Parallelism_parameter)
+      * [Memory Parameters](#Memory_parameters)
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
index 3fb3121..792ea08 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
@@ -19,18 +19,18 @@
 
 # <a id="Expressions">2. Expressions</a>
 
-    Expression ::= OperatorExpression | CaseExpression | QuantifiedExpression
-
 SQL++ is a highly composable expression language. Each SQL++ expression returns zero or more data model instances.
 There are three major kinds of expressions in SQL++. At the topmost level, a SQL++ expression can be an
 OperatorExpression (similar to a mathematical expression), an ConditionalExpression (to choose between
 alternative values), or a QuantifiedExpression (which yields a boolean value). Each will be detailed as we
 explore the full SQL++ grammar.
 
+    Expression ::= OperatorExpression | CaseExpression | QuantifiedExpression
+
 Note that in the following text, words enclosed in angle brackets denote keywords that are not case-sensitive.
 
 
-## <a id="Operator_expressions">Operator expressions</a>
+## <a id="Operator_expressions">Operator Expressions</a>
 
 Operators perform a specific operation on the input values or expressions. The syntax of an operator expression is as follows:
 
@@ -41,34 +41,34 @@
 
 SQL++ provides a full set of operators that you can use within its statements. Here are the categories of operators:
 
-* [Arithmetic operators](#Arithmetic_operators), to perform basic mathematical operations;
-* [Collection operators](#Collection_operators), to evaluate expressions on collections or objects;
-* [Comparison operators](#Comparison_operators), to compare two expressions;
+* [Arithmetic Operators](#Arithmetic_operators), to perform basic mathematical operations;
+* [Collection Operators](#Collection_operators), to evaluate expressions on collections or objects;
+* [Comparison Operators](#Comparison_operators), to compare two expressions;
 * [Logical Operators](#Logical_operators), to combine operators using Boolean logic.
 
 The following table summarizes the precedence order (from higher to lower) of the major unary and binary operators:
 
 | Operator                                                                    | Operation |
 |-----------------------------------------------------------------------------|-----------|
-| EXISTS, NOT EXISTS                                                          |  collection emptiness testing |
-| ^                                                                           |  exponentiation  |
-| *, /, %                                                                     |  multiplication, division, modulo |
-| +, -                                                                        |  addition, subtraction  |
-| &#124;&#124;                                                                          |  string concatenation |
-| IS NULL, IS NOT NULL, IS MISSING, IS NOT MISSING, <br/>IS UNKNOWN, IS NOT UNKNOWN| unknown value comparison |
-| BETWEEN, NOT BETWEEN                                                        | range comparison (inclusive on both sides) |
-| =, !=, <, >, <=, >=, LIKE, NOT LIKE, IN, NOT IN                             | comparison  |
-| NOT                                                                         | logical negation |
-| AND                                                                         | conjunction |
-| OR                                                                          | disjunction |
+| EXISTS, NOT EXISTS                                                          |  Collection emptiness testing |
+| ^                                                                           |  Exponentiation  |
+| *, /, %                                                                     |  Multiplication, division, modulo |
+| +, -                                                                        |  Addition, subtraction  |
+| &#124;&#124;                                                                          |  String concatenation |
+| IS NULL, IS NOT NULL, IS MISSING, IS NOT MISSING, <br/>IS UNKNOWN, IS NOT UNKNOWN| Unknown value comparison |
+| BETWEEN, NOT BETWEEN                                                        | Range comparison (inclusive on both sides) |
+| =, !=, <, >, <=, >=, LIKE, NOT LIKE, IN, NOT IN                             | Comparison  |
+| NOT                                                                         | Logical negation |
+| AND                                                                         | Conjunction |
+| OR                                                                          | Disjunction |
 
 In general, if any operand evaluates to a `MISSING` value, the enclosing operator will return `MISSING`;
 if none of operands evaluates to a `MISSING` value but there is an operand evaluates to a `NULL` value,
 the encolosing operator will return `NULL`. However, there are a few exceptions listed in
 [comparison operators](#Comparison_operators) and [logical operators](#Logical_operators).
 
-### <a id="Arithmetic_operators">Arithmetic operators</a>
-Arithemtic operators are used to exponentiate, add, subtract, multiply, and divide numeric values, or concatenate string values.
+### <a id="Arithmetic_operators">Arithmetic Operators</a>
+Arithmetic operators are used to exponentiate, add, subtract, multiply, and divide numeric values, or concatenate string values.
 
 | Operator     |  Purpose                                                                | Example    |
 |--------------|-------------------------------------------------------------------------|------------|
@@ -78,7 +78,7 @@
 | ^            |  Exponentiation                                                         | SELECT VALUE 2^3;       |
 | &#124;&#124; |  String concatenation                                                   | SELECT VALUE "ab"&#124;&#124;"c"&#124;&#124;"d";       |
 
-### <a id="Collection_operators">Collection operators</a>
+### <a id="Collection_operators">Collection Operators</a>
 Collection operators are used for membership tests (IN, NOT IN) or empty collection tests (EXISTS, NOT EXISTS).
 
 | Operator   |  Purpose                                     | Example    |
@@ -88,7 +88,7 @@
 | EXISTS     |  Check whether a collection is not empty     | SELECT * FROM ChirpMessages cm <br/>WHERE EXISTS cm.referredTopics; |
 | NOT EXISTS |  Check whether a collection is empty         | SELECT * FROM ChirpMessages cm <br/>WHERE NOT EXISTS cm.referredTopics; |
 
-### <a id="Comparison_operators">Comparison operators</a>
+### <a id="Comparison_operators">Comparison Operators</a>
 Comparison operators are used to compare values. The comparison operators fall into one of two sub-categories: missing value comparisons and regular value comparisons. SQL++ (and JSON) has two ways of representing missing information in a object - the presence of the field with a NULL for its value (as in SQL), and the absence of the field (which JSON permits). For example, the first of the following objects represents Jack, whose friend is Jill. In the other examples, Jake is friendless a la SQL, with a friend field that is NULL, while Joe is friendless in a more natural (for JSON) way, i.e., by not having a friend field.
 
 ##### Examples
@@ -129,7 +129,7 @@
 | IS UNKNOWN | FALSE | TRUE | TRUE |
 | IS NOT UNKNOWN | TRUE | FALSE | FALSE|
 
-### <a id="Logical_operators">Logical operators</a>
+### <a id="Logical_operators">Logical Operators</a>
 Logical operators perform logical `NOT`, `AND`, and `OR` operations over Boolean values (`TRUE` and `FALSE`) plus `NULL` and `MISSING`.
 
 | Operator |  Purpose                                   | Example    |
@@ -162,7 +162,7 @@
 | NULL | NULL |
 | MISSING | MISSING |
 
-## <a id="Case_expressions">Case expressions</a>
+## <a id="Case_expressions">Case Expressions</a>
 
     CaseExpression ::= SimpleCaseExpression | SearchedCaseExpression
     SimpleCaseExpression ::= <CASE> Expression ( <WHEN> Expression <THEN> Expression )+ ( <ELSE> Expression )? <END>
@@ -177,7 +177,7 @@
 
     CASE (2 < 3) WHEN true THEN "yes" ELSE "no" END
 
-## <a id="Quantified_expressions">Quantified expressions</a>
+## <a id="Quantified_expressions">Quantified Expressions</a>
 
     QuantifiedExpression ::= ( (<ANY>|<SOME>) | <EVERY> ) Variable <IN> Expression ( "," Variable "in" Expression )*
                              <SATISFIES> Expression (<END>)?
@@ -201,14 +201,14 @@
     SOME x IN [ 1, 2, 3 ] SATISFIES x < 3
 
 
-## <a id="Path_expressions">Path expressions</a>
+## <a id="Path_expressions">Path Expressions</a>
 
     PathExpression  ::= PrimaryExpression ( Field | Index )*
     Field           ::= "." Identifier
     Index           ::= "[" ( Expression | "?" ) "]"
 
 Components of complex types in the data model are accessed via path expressions. Path access can be applied to the result
-of a SQL++ expression that yields an instance of  a complex type, e.g., a object or array instance. For objects,
+of a SQL++ expression that yields an instance of  a complex type, for example, a object or array instance. For objects,
 path access is based on field names. For arrays, path access is based on (zero-based) array-style indexing.
 SQL++ also supports an "I'm feeling lucky" style index accessor, [?], for selecting an arbitrary element from an array.
 Attempts to access non-existent fields or out-of-bound array elements produce the special value `MISSING`.
@@ -239,7 +239,7 @@
 value, a reference to a query variable that is in scope, a parenthesized expression, a function call, or a newly
 constructed instance of the data model (such as a newly constructed object, array, or multiset of data model instances).
 
-### <a id="Literals">Literals</a>
+## <a id="Literals">Literals</a>
 
     Literal        ::= StringLiteral
                        | IntegerLiteral
@@ -319,7 +319,7 @@
 
 A variable in SQL++ can be bound to any legal data model value. A variable reference refers to the value to which an in-scope variable is
 bound. (E.g., a variable binding may originate from one of the `FROM`, `WITH` or `LET` clauses of a `SELECT` statement or from an
-input parameter in the context of a function body.) Backticks, e.g., \`id\`, are used for delimited identifiers. Delimiting is needed when
+input parameter in the context of a function body.) Backticks, for example, \`id\`, are used for delimited identifiers. Delimiting is needed when
 a variable's desired name clashes with a SQL++ keyword or includes characters not allowed in regular identifiers.
 
 ##### Examples
@@ -329,7 +329,7 @@
     `SELECT`
     `my-function`
 
-### <a id="Parenthesized_expressions">Parenthesized expressions</a>
+### <a id="Parenthesized_expressions">Parenthesized Expressions</a>
 
     ParenthesizedExpression ::= "(" Expression ")" | Subquery
 
@@ -341,7 +341,7 @@
 
     ( 1 + 1 )
 
-### <a id="Function_call_expressions">Function call expressions</a>
+### <a id="Function_call_expressions">Function Call Expressions</a>
 
     FunctionCallExpression ::= FunctionName "(" ( Expression ( "," Expression )* )? ")"
 
@@ -386,4 +386,3 @@
       'project members': [ 'vinayakb', 'dtabass', 'chenli', 'tsotras', 'tillw' ]
     }
 
-    {{ 42, "forty-two!", { "rank": "Captain", "name": "America" }, 3.14159, 42 }}
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
index b90eb06..cd22f17 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
@@ -23,7 +23,7 @@
 
     Query ::= (Expression | SelectStatement) ";"
 
-##  <a id="SELECT_statements">SELECT statements</a>
+##  <a id="SELECT_statements">SELECT Statements</a>
 
 The following shows the (rich) grammar for the `SELECT` statement in SQL++.
 
@@ -76,24 +76,105 @@
 
 `GleambookUsers` collection (or, dataset):
 
-    {"id":1,"alias":"Margarita","name":"MargaritaStoddard","nickname":"Mags","userSince":"2012-08-20T10:10:00","friendIds":[2,3,6,10],"employment":[{"organizationName":"Codetechno","start-date":"2006-08-06"},{"organizationName":"geomedia","start-date":"2010-06-17","end-date":"2010-01-26"}],"gender":"F"}
-    {"id":2,"alias":"Isbel","name":"IsbelDull","nickname":"Izzy","userSince":"2011-01-22T10:10:00","friendIds":[1,4],"employment":[{"organizationName":"Hexviafind","startDate":"2010-04-27"}]}
-    {"id":3,"alias":"Emory","name":"EmoryUnk","userSince":"2012-07-10T10:10:00","friendIds":[1,5,8,9],"employment":[{"organizationName":"geomedia","startDate":"2010-06-17","endDate":"2010-01-26"}]}
+    [ {
+      "id":1,
+      "alias":"Margarita",
+      "name":"MargaritaStoddard",
+      "nickname":"Mags",
+      "userSince":"2012-08-20T10:10:00",
+      "friendIds":[2,3,6,10],
+      "employment":[{
+                      "organizationName":"Codetechno",
+                      "start-date":"2006-08-06"
+                    },
+                    {
+                      "organizationName":"geomedia",
+                      "start-date":"2010-06-17",
+                      "end-date":"2010-01-26"
+                    }],
+      "gender":"F"
+    },
+    {
+      "id":2,
+      "alias":"Isbel",
+      "name":"IsbelDull",
+      "nickname":"Izzy",
+      "userSince":"2011-01-22T10:10:00",
+      "friendIds":[1,4],
+      "employment":[{
+                      "organizationName":"Hexviafind",
+                      "startDate":"2010-04-27"
+                   }]
+    },
+    {
+      "id":3,
+      "alias":"Emory",
+      "name":"EmoryUnk",
+      "userSince":"2012-07-10T10:10:00",
+      "friendIds":[1,5,8,9],
+      "employment":[{
+                      "organizationName":"geomedia",
+                      "startDate":"2010-06-17",
+                      "endDate":"2010-01-26"
+                   }]
+    } ]
 
 `GleambookMessages` collection (or, dataset):
 
-    {"messageId":2,"authorId":1,"inResponseTo":4,"senderLocation":[41.66,80.87],"message":" dislike iphone its touch-screen is horrible"}
-    {"messageId":3,"authorId":2,"inResponseTo":4,"senderLocation":[48.09,81.01],"message":" like samsung the plan is amazing"}
-    {"messageId":4,"authorId":1,"inResponseTo":2,"senderLocation":[37.73,97.04],"message":" can't stand at&t the network is horrible:("}
-    {"messageId":6,"authorId":2,"inResponseTo":1,"senderLocation":[31.5,75.56],"message":" like t-mobile its platform is mind-blowing"}
-    {"messageId":8,"authorId":1,"inResponseTo":11,"senderLocation":[40.33,80.87],"message":" like verizon the 3G is awesome:)"}
-    {"messageId":10,"authorId":1,"inResponseTo":12,"senderLocation":[42.5,70.01],"message":" can't stand motorola the touch-screen is terrible"}
-    {"messageId":11,"authorId":1,"inResponseTo":1,"senderLocation":[38.97,77.49],"message":" can't stand at&t its plan is terrible"}
+    [ {
+      "messageId":2,
+      "authorId":1,
+      "inResponseTo":4,
+      "senderLocation":[41.66,80.87],
+      "message":" dislike iphone its touch-screen is horrible"
+    },
+    {
+      "messageId":3,
+      "authorId":2,
+      "inResponseTo":4,
+      "senderLocation":[48.09,81.01],
+      "message":" like samsung the plan is amazing"
+    },
+    {
+      "messageId":4,
+      "authorId":1,
+      "inResponseTo":2,
+      "senderLocation":[37.73,97.04],
+      "message":" can't stand at&t the network is horrible:("
+    },
+    {
+      "messageId":6,
+      "authorId":2,
+      "inResponseTo":1,
+      "senderLocation":[31.5,75.56],
+      "message":" like t-mobile its platform is mind-blowing"
+    }
+    {
+      "messageId":8,
+      "authorId":1,
+      "inResponseTo":11,
+      "senderLocation":[40.33,80.87],
+      "message":" like verizon the 3G is awesome:)"
+    },
+    {
+      "messageId":10,
+      "authorId":1,
+      "inResponseTo":12,
+      "senderLocation":[42.5,70.01],
+      "message":" can't stand motorola the touch-screen is terrible"
+    },
+    {
+      "messageId":11,
+      "authorId":1,
+      "inResponseTo":1,
+      "senderLocation":[38.97,77.49],
+      "message":" can't stand at&t its plan is terrible"
+    } ]
 
 ## <a id="Select_clauses">SELECT Clause</a>
 The SQL++ `SELECT` clause always returns a collection value as its result (even if the result is empty or a singleton).
 
-### <a id="Select_element">SELECT VALUE Clause</a>
+### <a id="Select_element">Select Element/Value/Raw</a>
 The `SELECT VALUE` clause in SQL++ returns a collection that contains the results of evaluating the `VALUE` expression, with one evaluation being performed per "binding tuple" (i.e., per `FROM` clause item) satisfying the statement's selection criteria.
 For historical reasons SQL++ also allows the keywords `ELEMENT` or `RAW` to be used in place of `VALUE` (not recommended).
 
@@ -338,7 +419,7 @@
     , 3
      ]
 
-### <a id="Unnamed_projections">Unnamed projections</a>
+### <a id="Unnamed_projections">Unnamed Projections</a>
 Similar to standard SQL, SQL++ supports unnamed projections (a.k.a, unnamed `SELECT` clause items), for which names are generated.
 Name generation has three cases:
 
@@ -402,7 +483,7 @@
 
 Note that `UNNEST` has SQL's inner join semantics --- that is, if a user has no employment history, no tuple corresponding to that user will be emitted in the result.
 
-### <a id="Left_outer_unnests">Left outer UNNEST</a>
+### <a id="Left_outer_unnests">Left Outer UNNEST</a>
 As an alternative, the `LEFT OUTER UNNEST` clause offers SQL's left outer join semantics. For example, no collection-valued field named `hobbies` exists in the object for the user whose id is 1, but the following query's result still includes user 1.
 
 ##### Example
@@ -420,7 +501,7 @@
 
 Note that if `u.hobbies` is an empty collection or leads to a `MISSING` (as above) or `NULL` value for a given input tuple, there is no corresponding binding value for variable `h` for an input tuple. A `MISSING` value will be generated for `h` so that the input tuple can still be propagated.
 
-### <a id="Expressing_joins_using_unnests">Expressing joins using UNNEST</a>
+### <a id="Expressing_joins_using_unnests">Expressing Joins Using UNNEST</a>
 The SQL++ `UNNEST` clause is similar to SQL's `JOIN` clause except that it allows its right argument to be correlated to its left argument, as in the examples above --- i.e., think "correlated cross-product".
 The next example shows this via a query that joins two data sets, GleambookUsers and GleambookMessages, returning user/message pairs. The results contain one object per pair, with result objects containing the user's name and an entire message. The query can be thought of as saying "for each Gleambook user, unnest the `GleambookMessages` collection and filter the output with the condition `message.authorId = user.id`".
 
@@ -487,7 +568,7 @@
       3
     ]
 
-### <a id="Multiple_from_terms">Multiple FROM terms</a>
+### <a id="Multiple_from_terms">Multiple FROM Terms</a>
 SQL++ permits correlations among `FROM` terms. Specifically, a `FROM` binding expression can refer to variables defined to its left in the given `FROM` clause. Thus, the first unnesting example above could also be expressed as follows:
 
 ##### Example
@@ -497,7 +578,7 @@
     WHERE u.id = 1;
 
 
-### <a id="Expressing_joins_using_from_terms">Expressing joins using FROM terms</a>
+### <a id="Expressing_joins_using_from_terms">Expressing Joins Using FROM Terms</a>
 Similarly, the join intentions of the other `UNNEST`-based join examples above could be expressed as:
 
 ##### Example
@@ -518,7 +599,7 @@
 
 Note that the first alternative is one of the SQL-92 approaches to expressing a join.
 
-### <a id="Implicit_binding_variables">Implicit binding variables</a>
+### <a id="Implicit_binding_variables">Implicit Binding Variables</a>
 
 Similar to standard SQL, SQL++ supports implicit `FROM` binding variables (i.e., aliases), for which a binding variable is generated. SQL++ variable generation falls into three cases:
 
@@ -575,7 +656,7 @@
     Error: "Syntax error: Need an alias for the enclosed expression:\n(select element GleambookMessages\n    from GleambookMessages as GleambookMessages\n    where (GleambookMessages.authorId = GleambookUsers.id)\n )",
         "query_from_user": "use TinySocial;\n\nSELECT GleambookUsers.name, GleambookMessages.message\n    FROM GleambookUsers,\n      (\n        SELECT VALUE GleambookMessages\n        FROM GleambookMessages\n        WHERE GleambookMessages.authorId = GleambookUsers.id\n      );"
 
-## <a id="Join_clauses">JOIN clauses</a>
+## <a id="Join_clauses">JOIN Clauses</a>
 The join clause in SQL++ supports both inner joins and left outer joins from standard SQL.
 
 ### <a id="Inner_joins">Inner joins</a>
@@ -586,7 +667,7 @@
     SELECT u.name AS uname, m.message AS message
     FROM GleambookUsers u JOIN GleambookMessages m ON m.authorId = u.id;
 
-### <a id="Left_outer_joins">Left outer joins</a>
+### <a id="Left_outer_joins">Left Outer Joins</a>
 SQL++ supports SQL's notion of left outer join. The following query is an example:
 
     SELECT u.name AS uname, m.message AS message
@@ -633,7 +714,7 @@
 
 In general, in SQL++, SQL-style join queries can also be expressed by `UNNEST` clauses and left outer join queries can be expressed by `LEFT OUTER UNNESTs`.
 
-## <a id="Group_By_clauses">GROUP BY clauses</a>
+## <a id="Group_By_clauses">GROUP BY Clauses</a>
 The SQL++ `GROUP BY` clause generalizes standard SQL's grouping and aggregation semantics, but it also retains backward compatibility with the standard (relational) SQL `GROUP BY` and aggregation features.
 
 ### <a id="Group_variables">Group variables</a>
@@ -915,7 +996,7 @@
         "uid": 2
     } ]
 
-### <a id="Implicit_group_key_variables">Implicit grouping key variables</a>
+### <a id="Implicit_group_key_variables">Implicit Grouping Key Variables</a>
 In the SQL++ syntax, providing named binding variables for `GROUP BY` key expressions is optional.
 If a grouping key is missing a user-provided binding variable, the underlying compiler will generate one.
 Automatic grouping key variable naming falls into three cases in SQL++, much like the treatment of unnamed projections:
@@ -983,7 +1064,7 @@
 Based on the three variable generation rules, the generated variable for the grouping key expression `message.authorId`
 is `authorId` (which is how it is referred to in the example's `SELECT` clause).
 
-### <a id="Implicit_group_variables">Implicit group variables</a>
+### <a id="Implicit_group_variables">Implicit Group Variables</a>
 The group variable itself is also optional in SQL++'s `GROUP BY` syntax.
 If a user's query does not declare the name and structure of the group variable using `GROUP AS`,
 the query compiler will generate a unique group variable whose fields include all of the
@@ -1035,11 +1116,11 @@
     FROM GleambookMessages gbm
     GROUP BY gbm.authorId AS uid GROUP AS g(gbm as msg);
 
-### <a id="Aggregation_functions">Aggregation functions</a>
-In traditional SQL, which doesn't support nested data, grouping always also involves the use of aggregation
-to compute properties of the groups (e.g., the average number of messages per user rather than the actual set
+### <a id="Aggregation_functions">Aggregation Functions</a>
+In the traditional SQL, which doesn't support nested data, grouping always also involves the use of aggregation
+to compute properties of the groups (for example, the average number of messages per user rather than the actual set
 of messages per user).
-Each aggregation function in SQL++ takes a collection (e.g., the group of messages) as its input and produces
+Each aggregation function in SQL++ takes a collection (for example, the group of messages) as its input and produces
 a scalar value as its output.
 These aggregation functions, being truly functional in nature (unlike in SQL), can be used anywhere in a
 query where an expression is allowed.
@@ -1097,7 +1178,7 @@
 The query then uses the collection aggregate function ARRAY_COUNT to get the cardinality of each
 group of messages.
 
-### <a id="SQL-92_aggregation_functions">SQL-92 aggregation functions</a>
+### <a id="SQL-92_aggregation_functions">SQL-92 Aggregation Functions</a>
 For compatibility with the traditional SQL aggregation functions, SQL++ also offers SQL-92's
 aggregation function symbols (`COUNT`, `SUM`, `MAX`, `MIN`, and `AVG`) as supported syntactic sugar.
 The SQL++ compiler rewrites queries that utilize these function symbols into SQL++ queries that only
@@ -1123,7 +1204,7 @@
 In contrast to the SQL++ collection aggregate functions, these special SQL-92 function symbols
 can only be used in the same way they are in standard SQL (i.e., with the same restrictions).
 
-### <a id="SQL-92_compliant_gby">SQL-92 compliant GROUP BY aggregations</a>
+### <a id="SQL-92_compliant_gby">SQL-92 Compliant GROUP BY Aggregations</a>
 SQL++ provides full support for SQL-92 `GROUP BY` aggregation queries.
 The following query is such an example:
 
@@ -1144,7 +1225,7 @@
     } ]
 
 In principle, a `msg` reference in the query's `SELECT` clause would be "sugarized" as a collection
-(as described in [Implicit group variables](#Implicit_group_variables)).
+(as described in [Implicit Group Variables](#Implicit_group_variables)).
 However, since the SELECT expression `msg.authorId` is syntactically identical to a GROUP BY key expression,
 it will be internally replaced by the generated group key variable.
 The following is the equivalent rewritten query that will be generated by the compiler for the query above:
@@ -1153,7 +1234,7 @@
     FROM GleambookMessages msg
     GROUP BY msg.authorId AS authorId GROUP AS `$1`(msg AS msg);
 
-### <a id="Column_aliases">Column aliases</a>
+### <a id="Column_aliases">Column Aliases</a>
 SQL++ also allows column aliases to be used as `GROUP BY` keys or `ORDER BY` keys.
 
 ##### Example
@@ -1172,12 +1253,12 @@
         "aid": 2
     } ]
 
-## <a id="Where_having_clauses">WHERE clauses and HAVING clauses</a>
+## <a id="Where_having_clauses">WHERE Clauses and HAVING clauses</a>
 Both `WHERE` clauses and `HAVING` clauses are used to filter input data based on a condition expression.
 Only tuples for which the condition expression evaluates to `TRUE` are propagated.
 Note that if the condition expression evaluates to `NULL` or `MISSING` the input tuple will be disgarded.
 
-## <a id="Order_By_clauses">ORDER BY clauses</a>
+## <a id="Order_By_clauses">ORDER BY Clauses</a>
 The `ORDER BY` clause is used to globally sort data in either ascending order (i.e., `ASC`) or descending order (i.e., `DESC`).
 During ordering, `MISSING` and `NULL` are treated as being smaller than any other value if they are encountered
 in the ordering key(s). `MISSING` is treated as smaller than `NULL` if both occur in the data being sorted.
@@ -1251,7 +1332,7 @@
           ]
       } ]
 
-## <a id="Limit_clauses">LIMIT clauses</a>
+## <a id="Limit_clauses">LIMIT Clauses</a>
 The `LIMIT` clause is used to limit the result set to a specified constant size.
 The use of the `LIMIT` clause is illustrated in the next example.
 
@@ -1290,7 +1371,7 @@
           ]
       } ]
 
-## <a id="With_clauses">WITH clauses</a>
+## <a id="With_clauses">WITH Clauses</a>
 As in standard SQL, `WITH` clauses are available to improve the modularity of a query.
 The next query shows an example.
 
@@ -1373,7 +1454,7 @@
 an array-valued query expression's result; this is needed above, even though the result is an array of one
 element, to extract the only element in the singleton array and obtain the desired scalar for the comparison.
 
-## <a id="Let_clauses">LET clauses</a>
+## <a id="Let_clauses">LET Clauses</a>
 Similar to `WITH` clauses, `LET` clauses can be useful when a (complex) expression is used several times within a query, allowing it to be written once to make the query more concise. The next query shows an example.
 
 ##### Example
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl.md
index e7625b8..1c36f13 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl.md
@@ -74,7 +74,7 @@
       { "id": 2, "name": "IsbelDull", "friendCount": 2 }
     ]
 
-## <a id="Lifecycle_management_statements">Lifecycle management statements</a>
+## <a id="Lifecycle_management_statements">Lifecycle Management Statements</a>
 
     CreateStatement ::= "CREATE" ( DatabaseSpecification
                                  | TypeSpecification
@@ -210,7 +210,7 @@
 An External dataset, in contrast to an Internal dataset, has data stored outside of the system's control.
 Files living in HDFS or in the local filesystem(s) of a cluster's nodes are currently supported.
 External dataset support allows SQL++ queries to treat foreign data as though it were stored in the system,
-making it possible to query "legacy" file data (e.g., Hive data) without having to physically import it.
+making it possible to query "legacy" file data (for example, Hive data) without having to physically import it.
 When defining an External dataset, an appropriate adapter type must be selected for the desired external data.
 (See the [Guide to External Data](externaldata.html) for more information on the available adapters.)
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameter.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameter.md
index 6ef0dd6..f189d6a 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameter.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameter.md
@@ -1,4 +1,4 @@
-## <a id="Performance_tuning">Appendix 2. Performance tuning</a>
+## <a id="Performance_tuning">Appendix 2. Performance Tuning</a>
 The SET statement can be used to override some cluster-wide configuration parameters for a specific request:
 
           SET <IDENTIFIER> <STRING_LITERAL>
@@ -7,7 +7,7 @@
 Note that changing query parameters will not affect query correctness but only impact performance
 characteristics, such as response time and throughput.
 
-## <a id="Parallelism_parameter">Parallelism parameter</a>
+## <a id="Parallelism_parameter">Parallelism Parameter</a>
 The system can execute each request using multiple cores on multiple machines (a.k.a., partitioned parallelism)
 in a cluster. A user can manually specify the maximum execution parallelism for a request to scale it up and down
 using the following parameter:
@@ -24,7 +24,7 @@
      - all other cases:  the system will use the user-specified number as the maximum number of CPU cores to use for
        executing the query.
 
-## <a id="Memory_parameters">Memory parameters</a>
+## <a id="Memory_parameters">Memory Parameters</a>
 In the system, each blocking runtime operator such as join, group-by and order-by
 works within a fixed memory budget, and can gracefully spill to disks if
 the memory budget is smaller than the amount of data they have to hold.
@@ -41,7 +41,7 @@
    32MB is the default budget.
 
 For each memory budget value, you can use a 64-bit integer value
-with a 1024-based binary unit suffix (e.g., B, KB, MB, GB).
+with a 1024-based binary unit suffix (for example, B, KB, MB, GB).
 If there is no user-provided suffix, "B" is the default suffix. See the following examples.
 
 ##### Example