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 20c81a0..c108cc0 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/0_toc.md
@@ -17,7 +17,7 @@
  ! under the License.
  !-->
 
-# The SQL++ Query Language
+# The Query Language
 
 * [1. Introduction](#Introduction)
 * [2. Expressions](#Expressions)
@@ -71,7 +71,7 @@
       * [WITH Clauses](#With_clauses)
       * [LET Clauses](#Let_clauses)
       * [UNION ALL](#Union_all)
-      * [SQL++ Vs. SQL-92](#Vs_SQL-92)
+      * [Differences from SQL-92](#Vs_SQL-92)
 * [4. Errors](#Errors)
       * [Syntax Errors](#Syntax_errors)
       * [Identifier Resolution Errors](#Identifier_resolution_errors)
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
index f7df33f..e5441ba 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
@@ -20,21 +20,24 @@
 # <a id="Introduction">1. Introduction</a><font size="3"/>
 
 This document is intended as a reference guide to the full syntax and semantics of
-the SQL++ Query Language, a SQL-inspired language for working with semistructured data.
-SQL++ has much in common with SQL, but some differences do exist due to the different
-data models that the two languages were designed to serve.
+AsterixDB's query language, a SQL-based language for working with semistructured data.
+The language is a derivative of SQL++, a declarative query language for JSON data which
+is largely backwards compatible with SQL.
+SQL++ originated from research in the FORWARD project at UC San Diego, and it has
+much in common with SQL; some differences exist due to the different data models that
+the two languages were designed to serve.
 SQL was designed in the 1970's for interacting with the flat, schema-ified world of
 relational databases, while SQL++ is much newer and targets the nested, schema-optional
 (or even schema-less) world of modern NoSQL systems.
 
-In the context of Apache AsterixDB, SQL++ is intended for working with the Asterix Data Model
-([ADM](../datamodel.html)),a data model based on a superset of JSON with an enriched and flexible type system.
+In the context of Apache AsterixDB, the query language is intended for working with the Asterix Data Model
+([ADM](../datamodel.html)), a data model based on a superset of JSON with an enriched and flexible type system.
 New AsterixDB users are encouraged to read and work through the (much friendlier) guide
 "[AsterixDB 101: An ADM and SQL++ Primer](primer-sqlpp.html)" before attempting to make use of this document.
 In addition, readers are advised to read through the [Asterix Data Model (ADM) reference guide](../datamodel.html)
-first as well, as an understanding of the data model is a prerequisite to understanding SQL++.
+first as well, as an understanding of the data model is a prerequisite to understanding the query language.
 
-In what follows, we detail the features of the SQL++ language in a grammar-guided manner.
-We list and briefly explain each of the productions in the SQL++ grammar, offering examples
+In what follows, we detail the features of the query language in a grammar-guided manner.
+We list and briefly explain each of the productions in the query grammar, offering examples
 (and results) for clarity.
 
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 a1f0420..41cf1d8 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
@@ -17,10 +17,12 @@
  ! under the License.
  !-->
 
-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), or a QuantifiedExpression (which yields a boolean value).
-Each will be detailed as we explore the full SQL++ grammar.
+The query language is a highly composable expression language.
+Each expression in the query language returns zero or more data model instances.
+There are three major kinds of expressions.
+At the topmost level, an expression can be an OperatorExpression (similar to a mathematical expression) or a
+QuantifiedExpression (which yields a boolean value).
+Each will be detailed as we explore the full grammar of the language.
 
     Expression ::= OperatorExpression | QuantifiedExpression
 
@@ -29,14 +31,16 @@
 
 ## <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:
+Operators perform a specific operation on the input values or expressions.
+The syntax of an operator expression is as follows:
 
     OperatorExpression ::= PathExpression
                            | Operator OperatorExpression
                            | OperatorExpression Operator (OperatorExpression)?
                            | OperatorExpression <BETWEEN> OperatorExpression <AND> OperatorExpression
 
-SQL++ provides a full set of operators that you can use within its statements. Here are the categories of operators:
+The language 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;
@@ -65,7 +69,9 @@
 [comparison operators](#Comparison_operators) and [logical operators](#Logical_operators).
 
 ### <a id="Arithmetic_operators">Arithmetic Operators</a>
-Arithmetic operators are used to exponentiate, add, subtract, multiply, and divide numeric values, or concatenate string values.
+
+Arithmetic operators are used to exponentiate, add, subtract, multiply, and divide numeric values, or concatenate string
+values.
 
 | Operator     |  Purpose                                                                | Example    |
 |--------------|-------------------------------------------------------------------------|------------|
@@ -89,12 +95,13 @@
 | 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>
-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.
+Comparison operators are used to compare values.
+The comparison operators fall into one of two sub-categories: missing value comparisons and regular value comparisons.
+The query language (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
 {"name": "Jack", "friend": "Jill"}
@@ -103,7 +110,7 @@
 
 {"name": "Joe"}
 
-The following table enumerates all of SQL++'s comparison operators.
+The following table enumerates all of the query language's comparison operators.
 
 | Operator       |  Purpose                                       | Example    |
 |----------------|------------------------------------------------|------------|
@@ -203,14 +210,16 @@
     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, 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.
+Components of complex types in the data model are accessed via path expressions.
+Path access can be applied to the result of a query 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.
 Attempts to access non-existent fields or out-of-bound array elements produce the special value `MISSING`.
-For multisets path access is also zero-based and returns an arbitrary multiset element if the index
-is within the size of the multiset or `MISSING` otherwise.
-Type errors will be raised for inappropriate use of a path expression, such as applying a field
-accessor to a numeric value.
+For multisets path access is also zero-based and returns an arbitrary multiset element if the index is within the size
+of the multiset or `MISSING` otherwise.
+Type errors will be raised for inappropriate use of a path expression, such as applying a field accessor to a numeric
+value.
 
 The following examples illustrate field access for a object, index-based element access for an array, and also a
 composition thereof.
@@ -234,10 +243,10 @@
                   | CaseExpression
                   | Constructor
 
-The most basic building block for any SQL++ expression is PrimaryExpression. This can be a simple literal (constant)
-value, a reference to a query variable that is in scope, a statement parameter, a parenthesized expression,
-a function call, a conditional (case) expression, or a newly constructed instance of the data model
-(such as a newly constructed object, array, or multiset of data model instances).
+The most basic building block for any expression in the query langauge is PrimaryExpression.
+This can be a simple literal (constant) 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>
 
@@ -289,9 +298,13 @@
     DoubleLiteral  ::= <DIGITS> "." <DIGITS>
                        | "." <DIGITS>
 
-Literals (constants) in SQL++ can be strings, integers, floating point values, double values, boolean constants, or special constant values like `NULL` and `MISSING`. The `NULL` value is like a `NULL` in SQL; it is used to represent an unknown field value. The specialy value `MISSING` is only meaningful in the context of SQL++ field accesses; it occurs when the accessed field simply does not exist at all in a object being accessed.
+Literals (constants) in a query can be strings, integers, floating point values, double values, boolean constants, or
+special constant values like `NULL` and `MISSING`.
+The `NULL` value is like a `NULL` in SQL; it is used to represent an unknown field value.
+The special value `MISSING` is only meaningful in the context of field accesses; it occurs when the accessed field
+simply does not exist at all in a object being accessed.
 
-The following are some simple examples of SQL++ literals.
+The following are some simple examples of literals.
 
 ##### Examples
 
@@ -299,7 +312,7 @@
     "test string"
     42
 
-Different from standard SQL, double quotes play the same role as single quotes and may be used for string literals in SQL++.
+Different from standard SQL, double quotes play the same role as single quotes and may be used for string literals in queries as well.
 
 ### <a id="Variable_references">Variable References</a>
 
@@ -317,10 +330,15 @@
                                     | ~["`","\\"])*
                               "`"
 
-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, 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. More information on exactly how variable references are resolved can be found in the appendix section on Variable Resolution.
+A variable in a query 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, for example, \`id\`, are used for delimited identifiers.
+Delimiting is needed when a variable's desired name clashes with a keyword or includes characters not allowed in regular
+identifiers.
+More information on exactly how variable references are resolved can be found in the appendix section on Variable
+Resolution.
 
 ##### Examples
 
@@ -336,7 +354,8 @@
     PositionalParameterReference    ::= ("$" <DIGITS>) | "?"
 
 A statement parameter is an external variable which value is provided through the [statement execution API](../api.html#queryservice).
-An error will be raised if the parameter is not bound at the query execution time. Positional parameter numbering starts at 1.
+An error will be raised if the parameter is not bound at the query execution time.
+Positional parameter numbering starts at 1.
 "?" parameters are interpreted as $1, .. $N in the order in which they appear in the statement.
 
 ##### Examples
@@ -349,7 +368,8 @@
 
     ParenthesizedExpression ::= "(" Expression ")" | Subquery
 
-An expression can be parenthesized to control the precedence order or otherwise clarify a query. In SQL++, for composability, a subquery is also an parenthesized expression.
+An expression can be parenthesized to control the precedence order or otherwise clarify a query.
+For composability, a subquery is also an parenthesized expression.
 
 The following expression evaluates to the value 2.
 
@@ -361,7 +381,11 @@
 
     FunctionCallExpression ::= FunctionName "(" ( Expression ( "," Expression )* )? ")"
 
-Functions are included in SQL++, like most languages, as a way to package useful functionality or to componentize complicated or reusable SQL++ computations. A function call is a legal SQL++ query expression that represents the value resulting from the evaluation of its body expression with the given parameter bindings; the parameter value bindings can themselves be any SQL++ expressions.
+Functions are included in the query language, like most languages, as a way to package useful functionality or to
+componentize complicated or reusable computations.
+A function call is a legal query expression that represents the value resulting from the evaluation of its body
+expression with the given parameter bindings; the parameter value bindings can themselves be any expressions in the
+query language.
 
 The following example is a (built-in) function call expression whose value is 8.
 
@@ -394,7 +418,7 @@
     ObjectConstructor        ::= "{" ( FieldBinding ( "," FieldBinding )* )? "}"
     FieldBinding             ::= Expression ":" Expression
 
-A major feature of SQL++ is its ability to construct new data model instances. This is accomplished using
+A major feature of the query language is its ability to construct new data model instances. This is accomplished using
 its constructors for each of the model's complex object structures, namely arrays, multisets, and objects.
 Arrays are like JSON arrays, while multisets have bag semantics.
 Objects are built from fields that are field-name/field-value pairs, again like JSON.
@@ -402,9 +426,9 @@
 The following examples illustrate how to construct a new array with 4 items and a new object with 2 fields respectively.
 Array elements can be homogeneous (as in the first example),
 which is the common case, or they may be heterogeneous (as in the second example). The data values and field name values
-used to construct arrays, multisets, and objects in constructors are all simply SQL++ expressions. Thus, the collection
+used to construct arrays, multisets, and objects in constructors are all simply query expressions. Thus, the collection
 elements, field names, and field values used in constructors can be simple literals or they can come from query variable
-references or even arbitrarily complex SQL++ expressions (subqueries).
+references or even arbitrarily complex query expressions (subqueries).
 Type errors will be raised if the field names in an object are not strings, and
 duplicate field errors will be raised if they are not distinct.
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_dataverse.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_dataverse.md
index 1d1ab8e..d33d680 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_dataverse.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_dataverse.md
@@ -22,7 +22,7 @@
     DatabaseDeclaration ::= "USE" Identifier
 
 At the uppermost level, the world of data is organized into data namespaces called **dataverses**.
-To set the default dataverse for a series of statements, the USE statement is provided in SQL++.
+To set the default dataverse for statements, the USE statement is provided.
 
 As an example, the following statement sets the default dataverse to be "TinySocial".
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_function.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_function.md
index a45996c..8e77de9 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_function.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_declare_function.md
@@ -17,15 +17,15 @@
  ! under the License.
  !-->
 
-When writing a complex SQL++ query, it can sometimes be helpful to define one or more auxilliary functions
+When writing a complex query, it can sometimes be helpful to define one or more auxilliary functions
 that each address a sub-piece of the overall query.
 The declare function statement supports the creation of such helper functions.
-In general, the function body (expression) can be any legal SQL++ query expression.
+In general, the function body (expression) can be any legal query expression.
 
     FunctionDeclaration  ::= "DECLARE" "FUNCTION" Identifier ParameterList "{" Expression "}"
     ParameterList        ::= "(" ( <VARIABLE> ( "," <VARIABLE> )* )? ")"
 
-The following is a simple example of a temporary SQL++ function definition and its use.
+The following is a simple example of a temporary function definition and its use.
 
 ##### Example
 
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 223e188..22313d0 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
@@ -19,7 +19,7 @@
 
 ##  <a id="SELECT_statements">SELECT Statements</a>
 
-The following shows the (rich) grammar for the `SELECT` statement in SQL++.
+The following shows the (rich) grammar for the `SELECT` statement in the query language.
 
     SelectStatement    ::= ( WithClause )?
                            SelectSetOperation (OrderbyClause )? ( LimitClause )?
@@ -169,13 +169,13 @@
     } ]
 
 ## <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).
+The `SELECT` clause always returns a collection value as its result (even if the result is empty or a singleton).
 
 ### <a id="Select_element">Select Element/Value/Raw</a>
-The `SELECT VALUE` clause in SQL++ returns an array or multiset that contains the results of evaluating the `VALUE`
+The `SELECT VALUE` clause returns an array or multiset 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`
+For historical reasons the query language also allows the keywords `ELEMENT` or `RAW` to be used in place of `VALUE`
 (not recommended).
 
 If there is no FROM clause, the expression after `VALUE` is evaluated once with no binding tuples
@@ -228,10 +228,10 @@
     } ]
 
 ### <a id="SQL_select">SQL-style SELECT</a>
-In SQL++, the traditional SQL-style `SELECT` syntax is also supported.
-This syntax can also be reformulated in a `SELECT VALUE` based manner in SQL++.
+The traditional SQL-style `SELECT` syntax is also supported in the query language.
+This syntax can also be reformulated in a `SELECT VALUE` based manner.
 (E.g., `SELECT expA AS fldA, expB AS fldB` is syntactic sugar for `SELECT VALUE { 'fldA': expA, 'fldB': expB }`.)
-Unlike in SQL, the result of an SQL++ query does not preserve the order of expressions in the `SELECT` clause.
+Unlike in SQL, the result of a query does not preserve the order of expressions in the `SELECT` clause.
 
 ##### Example
     SELECT user.alias user_alias, user.name user_name
@@ -246,7 +246,7 @@
     } ]
 
 ### <a id="Select_star">SELECT *</a>
-In SQL++, `SELECT *` returns a object with a nested field for each input tuple.
+`SELECT *` returns a object with a nested field for each input tuple.
 Each field has as its field name the name of a binding variable generated by either the `FROM` clause or `GROUP BY`
 clause in the current enclosing `SELECT` statement, and its field value is the value of that binding variable.
 
@@ -395,7 +395,7 @@
 
 
 ### <a id="Select_distinct">SELECT DISTINCT</a>
-SQL++'s `DISTINCT` keyword is used to eliminate duplicate items in results. The following example shows how it works.
+The `DISTINCT` keyword is used to eliminate duplicate items in results. The following example shows how it works.
 
 ##### Example
 
@@ -423,7 +423,7 @@
      ]
 
 ### <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.
+Similar to standard SQL, the query language  supports unnamed projections (a.k.a, unnamed `SELECT` clause items), for which names are generated.
 Name generation has three cases:
 
   * If a projection expression is a variable reference expression, its generated name is the name of the variable.
@@ -446,7 +446,7 @@
 In the result, `$1` is the generated name for `substr(user.name, 1)`, while `alias` is the generated name for `user.alias`.
 
 ### <a id="Abbreviated_field_access_expressions">Abbreviated Field Access Expressions</a>
-As in standard SQL, SQL++ field access expressions can be abbreviated (not recommended!) when there is no ambiguity. In the next example, the variable `user` is the only possible variable reference for fields `id`, `name` and `alias` and thus could be omitted in the query. More information on abbbreviated field access can be found in the appendix section on Variable Resolution.
+As in standard SQL, field access expressions can be abbreviated (not recommended!) when there is no ambiguity. In the next example, the variable `user` is the only possible variable reference for fields `id`, `name` and `alias` and thus could be omitted in the query. More information on abbbreviated field access can be found in the appendix section on Variable Resolution.
 
 ##### Example
 
@@ -505,7 +505,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>
-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 `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`".
 
 ##### Example
@@ -540,7 +540,7 @@
         "message": " like product-y the plan is amazing"
     } ]
 
-Similarly, the above query can also be expressed as the `UNNEST`ing of a correlated SQL++ subquery:
+Similarly, the above query can also be expressed as the `UNNEST`ing of a correlated subquery:
 
 ##### Example
 
@@ -556,7 +556,7 @@
 A `FROM` clause is used for enumerating (i.e., conceptually iterating over) the contents of collections, as in SQL.
 
 ### <a id="Binding_expressions">Binding expressions</a>
-In SQL++, in addition to stored collections, a `FROM` clause can iterate over any intermediate collection returned by a valid SQL++ expression.
+In addition to stored collections, a `FROM` clause can iterate over any intermediate collection returned by a valid query expression.
 In the tuple stream generated by a `FROM` clause, the ordering of the input tuples are not guaranteed to be preserved.
 
 ##### Example
@@ -572,7 +572,7 @@
     ]
 
 ### <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:
+The query language 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
 
@@ -604,7 +604,8 @@
 
 ### <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:
+Similar to standard SQL, the query language supports implicit `FROM` binding variables (i.e., aliases), for which a binding variable is generated.
+Variable generation falls into three cases:
 
   * If the binding expression is a variable reference expression, the generated variable's name will be the name of the referenced variable itself.
   * If the binding expression is a field access expression (or a fully qualified name for a dataset), the generated
@@ -662,7 +663,7 @@
 More information on implicit binding variables can be found in the appendix section on Variable Resolution.
 
 ## <a id="Join_clauses">JOIN Clauses</a>
-The join clause in SQL++ supports both inner joins and left outer joins from standard SQL.
+The join clause in the query language supports both inner joins and left outer joins from standard SQL.
 
 ### <a id="Inner_joins">Inner joins</a>
 Using a `JOIN` clause, the inner join intent from the preceeding examples can also be expressed as follows:
@@ -673,7 +674,7 @@
     FROM GleambookUsers u JOIN GleambookMessages m ON m.authorId = u.id;
 
 ### <a id="Left_outer_joins">Left Outer Joins</a>
-SQL++ supports SQL's notion of left outer join. The following query is an example:
+The query language supports SQL's notion of left outer join. The following query is an example:
 
     SELECT u.name AS uname, m.message AS message
     FROM GleambookUsers u LEFT OUTER JOIN GleambookMessages m ON m.authorId = u.id;
@@ -705,7 +706,7 @@
         "uname": "EmoryUnk"
     } ]
 
-For non-matching left-side tuples, SQL++ produces `MISSING` values for the right-side binding variables; that is why the last object in the above result doesn't have a `message` field. Note that this is slightly different from standard SQL, which instead would fill in `NULL` values for the right-side fields. The reason for this difference is that, for non-matches in its join results, SQL++ views fields from the right-side as being "not there" (a.k.a. `MISSING`) instead of as being "there but unknown" (i.e., `NULL`).
+For non-matching left-side tuples, the query language produces `MISSING` values for the right-side binding variables; that is why the last object in the above result doesn't have a `message` field. Note that this is slightly different from standard SQL, which instead would fill in `NULL` values for the right-side fields. The reason for this difference is that, for non-matches in its join results, the query language views fields from the right-side as being "not there" (a.k.a. `MISSING`) instead of as being "there but unknown" (i.e., `NULL`).
 
 The left-outer join query can also be expressed using `LEFT OUTER UNNEST`:
 
@@ -717,13 +718,13 @@
         WHERE message.authorId = u.id
       ) m;
 
-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`.
+In general, 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>
-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.
+The `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>
-In a `GROUP BY` clause, in addition to the binding variable(s) defined for the grouping key(s), SQL++ allows a user to define a *group variable* by using the clause's `GROUP AS` extension to denote the resulting group.
+In a `GROUP BY` clause, in addition to the binding variable(s) defined for the grouping key(s), the query language allows a user to define a *group variable* by using the clause's `GROUP AS` extension to denote the resulting group.
 After grouping, then, the query's in-scope variables include the grouping key's binding variables as well as this group variable which will be bound to one collection value for each group. This per-group collection (i.e., multiset) value will be a set of nested objects in which each field of the object is the result of a renamed variable defined in parentheses following the group variable's name. The `GROUP AS` syntax is as follows:
 
     <GROUP> <AS> Variable ("(" VariableReference <AS> Identifier ("," VariableReference <AS> Identifier )* ")")?
@@ -835,8 +836,8 @@
 This variable contains a collection of objects associated with the group; each of the group's `message` values
 appears in the `msg` field of the objects in the `msgs` collection.
 
-The group variable in SQL++ makes more complex, composable, nested subqueries over a group possible, which is
-important given the more complex data model of SQL++ (relative to SQL).
+The group variable in the query language makes more complex, composable, nested subqueries over a group possible, which is
+important given the language's more complex data model (relative to SQL).
 As a simple example of this, as we really just want the messages associated with each user, we might wish to avoid
 the "extra wrapping" of each message as the `msg` field of a object.
 (That wrapping is useful in more complex cases, but is essentially just in the way here.)
@@ -991,9 +992,9 @@
     } ]
 
 ### <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.
+In the query language 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:
+Automatic grouping key variable naming falls into three cases, much like the treatment of unnamed projections:
 
   * If the grouping key expression is a variable reference expression, the generated variable gets the same name as the referred variable;
   * If the grouping key expression is a field access expression, the generated variable gets the same name as the last identifier in the expression;
@@ -1059,7 +1060,7 @@
 is `authorId` (which is how it is referred to in the example's `SELECT` clause).
 
 ### <a id="Implicit_group_variables">Implicit Group Variables</a>
-The group variable itself is also optional in SQL++'s `GROUP BY` syntax.
+The group variable itself is also optional in the `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 binding
 variables defined in the `FROM` clause of the current enclosing `SELECT` statement.
@@ -1071,11 +1072,11 @@
 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 (for example, the group of messages) as its input and produces
+Each aggregation function in the query language 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.
-The following table catalogs the SQL++ built-in aggregation functions and also indicates how each one handles
+The following table catalogs the built-in aggregation functions of the query language and also indicates how each one handles
 `NULL`/`MISSING` values in the input collection or a completely empty input collection:
 
 | Function       | NULL         | MISSING      | Empty Collection |
@@ -1091,8 +1092,8 @@
 | ARRAY_MIN      | ignores NULL | ignores NULL | returns NULL     |
 | ARRAY_AVG      | ignores NULL | ignores NULL | returns NULL     |
 
-Notice that SQL++ has twice as many functions listed above as there are aggregate functions in SQL-92.
-This is because SQL++ offers two versions of each -- one that handles `UNKNOWN` values in a semantically
+Notice that the query language has twice as many functions listed above as there are aggregate functions in SQL-92.
+This is because the language offers two versions of each -- one that handles `UNKNOWN` values in a semantically
 strict fashion, where unknown values in the input result in unknown values in the output -- and one that
 handles them in the ad hoc "just ignore the unknown values" fashion that the SQL standard chose to adopt.
 
@@ -1130,7 +1131,7 @@
 The query then uses the collection aggregate function ARRAY_COUNT to get the cardinality of each
 group of messages.
 
-Each aggregation function in SQL++ supports DISTINCT modifier that removes duplicate values from
+Each aggregation function in the query language supports DISTINCT modifier that removes duplicate values from
 the input collection.
 
 ##### Example
@@ -1142,11 +1143,11 @@
     6
 
 ### <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
+For compatibility with the traditional SQL aggregation functions, the query language 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
-use the SQL++ collection aggregate functions. The following example uses the SQL-92 syntax approach
-to compute a result that is identical to that of the more explicit SQL++ example above:
+The query compiler rewrites queries that utilize these function symbols into queries that only
+use the collection aggregate functions of the query language. The following example uses the SQL-92 syntax approach
+to compute a result that is identical to that of the more explicit example above:
 
 ##### Example
 
@@ -1154,8 +1155,8 @@
     FROM GleambookMessages msg
     GROUP BY msg.authorId AS uid;
 
-It is important to realize that `COUNT` is actually **not** a SQL++ built-in aggregation function.
-Rather, the `COUNT` query above is using a special "sugared" function symbol that the SQL++ compiler
+It is important to realize that `COUNT` is actually **not** a built-in aggregation function.
+Rather, the `COUNT` query above is using a special "sugared" function symbol that the query compiler
 will rewrite as follows:
 
     SELECT uid AS uid, ARRAY_COUNT( (SELECT VALUE 1 FROM `$1` as g) ) AS msgCnt
@@ -1165,13 +1166,13 @@
 
 
 The same sort of rewritings apply to the function symbols `SUM`, `MAX`, `MIN`, and `AVG`.
-In contrast to the SQL++ collection aggregate functions, these special SQL-92 function symbols
+In contrast to the collection aggregate functions of the query language, 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).
 
 DISTINCT modifier is also supported for these aggregate functions.
 
 ### <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 query language provides full support for SQL-92 `GROUP BY` aggregation queries.
 The following query is such an example:
 
 ##### Example
@@ -1202,7 +1203,7 @@
     GROUP AS `$1`(msg AS msg);
 
 ### <a id="Column_aliases">Column Aliases</a>
-SQL++ also allows column aliases to be used as `ORDER BY` keys.
+The query language also allows column aliases to be used as `ORDER BY` keys.
 
 ##### Example
 
@@ -1411,15 +1412,15 @@
 
 WITH can be particularly useful when a value needs to be used several times in a query.
 
-Before proceeding further, notice that both  the WITH query and its equivalent inlined variant
-include the syntax "[0]" -- this is due to a noteworthy difference between SQL++ and SQL-92.
+Before proceeding further, notice that both the WITH query and its equivalent inlined variant
+include the syntax "[0]" -- this is due to a noteworthy difference between the query language and SQL-92.
 In SQL-92, whenever a scalar value is expected and it is being produced by a query expression,
 the SQL-92 query processor will evaluate the expression, check that there is only one row and column
 in the result at runtime, and then coerce the one-row/one-column tabular result into a scalar value.
-SQL++, being designed to deal with nested data and schema-less data, does not (and should not) do this.
-Collection-valued data is perfectly legal in most SQL++ contexts, and its data is schema-less,
-so a query processor rarely knows exactly what to expect where and such automatic conversion is often
-not desirable. Thus, in the queries above, the use of "[0]" extracts the first (i.e., 0th) element of
+A JSON query language, being designed to deal with nested data and schema-less data, should not do this.
+Collection-valued data is perfectly legal in most contexts, and its data is schema-less,
+so the query processor rarely knows exactly what to expect where and such automatic conversion would often
+not be desirable. Thus, in the queries above, the use of "[0]" extracts the first (i.e., 0th) element of
 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.
 
@@ -1532,7 +1533,7 @@
 ## <a id="Union_all">UNION ALL</a>
 UNION ALL can be used to combine two input arrays or multisets into one. As in SQL, there is no ordering guarantee
 on the contents of the output stream.
-However, unlike SQL, SQL++ does not constrain what the data looks like on the input streams; in particular,
+However, unlike SQL, the query language does not constrain what the data looks like on the input streams; in particular,
 it allows heterogenity on the input and output streams.
 A type error will be raised if one of the inputs is not a collection.
 The following odd but legal query is an example:
@@ -1557,7 +1558,7 @@
      ]
 
 ## <a id="Subqueries">Subqueries</a>
-In SQL++, an arbitrary subquery can appear anywhere that an expression can appear.
+In the query language, an arbitrary subquery can appear anywhere that an expression can appear.
 Unlike SQL-92, as was just alluded to, the subqueries in a SELECT list or a boolean predicate need
 not return singleton, single-column relations.
 Instead, they may return arbitrary collections.
@@ -1601,8 +1602,8 @@
 Note that a subquery, like a top-level `SELECT` statment, always returns a collection -- regardless of where
 within a query the subquery occurs -- and again, its result is never automatically cast into a scalar.
 
-## <a id="Vs_SQL-92">SQL++ vs. SQL-92</a>
-SQL++ offers the following additional features beyond SQL-92 (hence the "++" in its name):
+## <a id="Vs_SQL-92">Differences from SQL-92</a>
+The query language offers the following additional features beyond SQL-92:
 
   * Fully composable and functional: A subquery can iterate over any intermediate collection and can appear anywhere in a query.
   * Schema-free: The query language does not assume the existence of a static schema for any data that it processes.
@@ -1611,9 +1612,9 @@
   * Generalized SELECT clause: A SELECT clause can return any type of collection, while in SQL-92, a `SELECT` clause has to return a (homogeneous) collection of objects.
 
 
-The following matrix is a quick "SQL-92 compatibility cheat sheet" for SQL++.
+The following matrix is a quick "SQL-92 compatibility cheat sheet" for the query language.
 
-| Feature |  SQL++ | SQL-92 |  Why different?  |
+| Feature |  The query language | SQL-92 |  Why different?  |
 |----------|--------|-------|------------------|
 | SELECT * | Returns nested objects | Returns flattened concatenated objects | Nested collections are 1st class citizens |
 | SELECT list | order not preserved | order preserved | Fields in a JSON object are not ordered |
@@ -1624,7 +1625,7 @@
 | String literal | Double quotes or single quotes | Single quotes only | Double quoted strings are pervasive |
 | Delimited identifiers | Backticks | Double quotes | Double quoted strings are pervasive |
 
-The following SQL-92 features are not implemented yet. However, SQL++ does not conflict with these features:
+The following SQL-92 features are not implemented yet. However, the query language does not conflict with these features:
 
   * CROSS JOIN, NATURAL JOIN, UNION JOIN
   * RIGHT and FULL OUTER JOIN
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
index e35ad29..bc36260 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
@@ -19,7 +19,7 @@
 
 # <a id="Queries">3. Queries</a>
 
-A SQL++ query can be any legal SQL++ expression or `SELECT` statement. A SQL++ query always ends with a semicolon.
+A query can be any legal expression or `SELECT` statement. A query always ends with a semicolon.
 
     Query ::= (Expression | SelectStatement) ";"
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_error.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_error.md
index b7d5da3..18fce14 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_error.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_error.md
@@ -17,7 +17,7 @@
  ! under the License.
  !-->
 
-A SQL++ query can potentially result in one of the following errors:
+A query can potentially result in one of the following errors:
 
  * syntax error,
  * identifier resolution error,
@@ -29,7 +29,7 @@
 immediately return an error message to the client.
 
 ## <a id="Syntax_errors">Syntax Errors</a>
-An valid SQL++ query must satisfy the SQL++ grammar rules.
+A valid query must satisfy the grammar rules of the query language.
 Otherwise, a syntax error will be raised.
 
 ##### Example
@@ -48,7 +48,7 @@
     FROM GleambookUsers user
     WHERE type="advertiser";
 
-Since "type" is a reserved keyword in the SQL++ parser,
+Since "type" is a reserved keyword in the query parser,
 we will get a syntax error as follows:
 
     Error: Syntax error: In line 3 >>WHERE type="advertiser";<< Encountered 'type' "type" at column 7.
@@ -82,8 +82,8 @@
 
 ## <a id="Type_errors">Type Errors</a>
 
-The SQL++ compiler does type checks based on its available type information.
-In addition, the SQL++ runtime also reports type errors if a data model instance
+The query compiler does type checks based on its available type information.
+In addition, the query runtime also reports type errors if a data model instance
 it processes does not satisfy the type requirement.
 
 ##### Example
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dataset_index.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dataset_index.md
index bdd9706..589b038 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dataset_index.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dataset_index.md
@@ -28,15 +28,15 @@
     QualifiedName       ::= Identifier ( "." Identifier )?
     DoubleQualifiedName ::= Identifier "." Identifier ( "." Identifier )?
 
-The CREATE statement in SQL++ is used for creating dataverses as well as other persistent artifacts in a dataverse.
-It can be used to create new dataverses, datatypes, datasets, indexes, and user-defined SQL++ functions.
+The CREATE statement is used for creating dataverses as well as other persistent artifacts in a dataverse.
+It can be used to create new dataverses, datatypes, datasets, indexes, and user-defined query functions.
 
 ### <a id="Dataverses"> Dataverses</a>
 
     DatabaseSpecification ::= "DATAVERSE" Identifier IfNotExists
 
 The CREATE DATAVERSE statement is used to create new dataverses.
-To ease the authoring of reusable SQL++ scripts, an optional IF NOT EXISTS clause is included to allow
+To ease the authoring of reusable query scripts, an optional IF NOT EXISTS clause is included to allow
 creation to be requested either unconditionally or only if the dataverse does not already exist.
 If this clause is absent, an error is returned if a dataverse with the indicated name already exists.
 
@@ -122,7 +122,7 @@
 
 The CREATE DATASET statement is used to create a new dataset.
 Datasets are named, multisets of object type instances;
-they are where data lives persistently and are the usual targets for SQL++ queries.
+they are where data lives persistently and are the usual targets for queries.
 Datasets are typed, and the system ensures that their contents conform to their type definitions.
 An Internal dataset (the default kind) is a dataset whose content lives within and is managed by the system.
 It is required to have a specified unique primary key field which uniquely identifies the contained objects.
@@ -152,7 +152,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,
+External dataset support allows queries to treat foreign data as though it were stored in the system,
 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/5_ddl_dml.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dml.md
index f2c404e..2eb5820 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dml.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_dml.md
@@ -23,9 +23,9 @@
 
     InsertStatement ::= <INSERT> <INTO> QualifiedName Query
 
-The SQL++ INSERT statement is used to insert new data into a dataset.
-The data to be inserted comes from a SQL++ query expression.
-This expression can be as simple as a constant expression, or in general it can be any legal SQL++ query.
+The INSERT statement is used to insert new data into a dataset.
+The data to be inserted comes from a query expression.
+This expression can be as simple as a constant expression, or in general it can be any legal query.
 If the target dataset has an auto-generated primary key field, the insert statement should not include a
 value for that field in it.
 (The system will automatically extend the provided object with this additional field and a corresponding value.)
@@ -45,7 +45,7 @@
 
     UpsertStatement ::= <UPSERT> <INTO> QualifiedName Query
 
-The SQL++ UPSERT statement syntactically mirrors the INSERT statement discussed above.
+The UPSERT statement syntactically mirrors the INSERT statement discussed above.
 The difference lies in its semantics, which for UPSERT are "add or replace" instead of the INSERT "add if not present, else error" semantics.
 Whereas an INSERT can fail if another object already exists with the specified key, the analogous UPSERT will replace the previous object's value with that of the new object in such cases.
 
@@ -55,13 +55,13 @@
 
     UPSERT INTO UsersCopy (SELECT VALUE user FROM GleambookUsers user)
 
-*Editor's note: Upserts currently work in AQL but are not yet enabled (at the moment) in SQL++.
+*Editor's note: Upserts currently work in AQL but are not yet enabled (at the moment) in the current query language.
 
 ### <a id="Deletes">DELETEs</a>
 
     DeleteStatement ::= <DELETE> <FROM> QualifiedName ( ( <AS> )? Variable )? ( <WHERE> Expression )?
 
-The SQL++ DELETE statement is used to delete data from a target dataset.
+The DELETE statement is used to delete data from a target dataset.
 The data to be deleted is identified by a boolean expression involving the variable bound to the target dataset in the DELETE statement.
 
 Deletes are processed transactionally by the system.
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_function_removal.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_function_removal.md
index 7b2c603..9fcaa11 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_function_removal.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_function_removal.md
@@ -19,8 +19,8 @@
 
 ### <a id="Functions"> Functions</a>
 
-The create function statement creates a **named** function that can then be used and reused in SQL++ queries.
-The body of a function can be any SQL++ expression involving the function's parameters.
+The create function statement creates a **named** function that can then be used and reused in queries.
+The body of a function can be any query expression involving the function's parameters.
 
     FunctionSpecification ::= "FUNCTION" FunctionOrTypeName IfNotExists ParameterList "{" Expression "}"
 
@@ -44,7 +44,7 @@
                                    | "FUNCTION" FunctionSignature IfExists )
     IfExists            ::= ( "IF" "EXISTS" )?
 
-The DROP statement in SQL++ is the inverse of the CREATE statement. It can be used to drop dataverses, datatypes, datasets, indexes, and functions.
+The DROP statement is the inverse of the CREATE statement. It can be used to drop dataverses, datatypes, datasets, indexes, and functions.
 
 The following examples illustrate some uses of the DROP statement.
 
@@ -64,7 +64,7 @@
 (see the DROP DATASET example above) or from the specified dataverse (see the DROP TYPE example above)
 if one is specified by fully qualifying the artifact name in the DROP statement.
 When specifying an index to drop, the index name must be qualified by the dataset that it indexes.
-When specifying a function to drop, since SQL++ allows functions to be overloaded by their number of arguments,
+When specifying a function to drop, since the query language allows functions to be overloaded by their number of arguments,
 the identifying name of the function to be dropped must explicitly include that information.
 (`friendInfo@1` above denotes the 1-argument function named friendInfo in the current dataverse.)
 
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_head.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_head.md
index 658190b..83fa4c9 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_head.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/5_ddl_head.md
@@ -30,8 +30,7 @@
                       | DeleteStatement
                       | Query
 
-In addition to queries, an implementation of SQL++ needs to support statements for data definition
-and manipulation purposes as well as controlling the context to be used in evaluating SQL++ expressions.
-This section details the DDL and DML statements supported in the SQL++ language as realized today in
-Apache AsterixDB.
+In addition to queries, an implementation of the query language needs to support statements for data definition
+and manipulation purposes as well as controlling the context to be used in evaluating query expressions.
+This section details the DDL and DML statements supported in the query language as realized today in Apache AsterixDB.