MONDRIAN: Fix typos in doc (Pentaho Jira INTERNAL-702)

[git-p4: depot-paths = "//open/mondrian/": change = 8769]

doc/architecture.html

@@ -49,7 +49,7 @@ <h3>Layers of a Mondrian system</h3>
 
 <p>The second layer is the dimensional layer. The dimensional layer parses, validates and executes MDX queries. A query is evaluted in multiple phases. The axes are computed first, then the values of the cells within the axes. For efficiency, the dimensional layer sends cell-requests to the aggregation layer in batches. A query transformer allows the application to manipulate existing queries, rather than building an MDX statement from scratch for each request. And metadata describes the the dimensional model, and how it maps onto the relational model.</p>
 
-<p>The third layer is the star layer, and is responsible for maintaining an aggregate cache. An aggregation is a set of measure values ('cells') in memory, qualified by a set of dimension column values. The dimensional layer sends requests for sets of cells. If the requested cells are not in the cache, or derivable by rolling up an aggregation in the cache, the aggregation manager and sends a request to the storage layer.</p>
+<p>The third layer is the star layer, and is responsible for maintaining an aggregate cache. An aggregation is a set of measure values ('cells') in memory, qualified by a set of dimension column values. The dimensional layer sends requests for sets of cells. If the requested cells are not in the cache, or derivable by rolling up an aggregation in the cache, the aggregation manager sends a request to the storage layer.</p>
 
 <p>The storage layer is an RDBMS. It is responsible for providing aggregated cell data, and members from dimension tables. I describe <a href="#Storage_and_aggregation_strategies">below</a> why I decided to use the features of the RDBMS rather than developing a storage system optimized for multidimensional data.</p>
 
@@ -141,7 +141,7 @@ <h3>Storage and aggregation strategies<a name="Storage_and_aggregation_strategie
 <ul>
 	<li>Fact data is stored in the RDBMS. Why develop a storage manager when the RDBMS already has one? </li>
 	<li>Read aggregate data into the cache by submitting group by queries. Again, why develop an aggregator when the RDBMS has one? </li>
-	<li>If the RDBMS supports materialized views, and the database administrator chooses to create materialized views for particular aggregations, then Mondrian will use them implicitly. Ideally, Mondrian's aggregation manager should be aware that these materialized views exist and that those particular aggregations are cheap to compute. If should even offer tuning suggestings to the database administrator. </li>
+	<li>If the RDBMS supports materialized views, and the database administrator chooses to create materialized views for particular aggregations, then Mondrian will use them implicitly. Ideally, Mondrian's aggregation manager should be aware that these materialized views exist and that those particular aggregations are cheap to compute. It should even offer tuning suggestings to the database administrator. </li>
 </ul>
 
 <p>The general idea is to delegate unto the database what is the database's. This places additional burden on the database, but once those features are added to the database, all clients of the database will benefit from them. Multidimensional storage would reduce I/O and result in faster operation in some circumstances, but I don't think it warrants the complexity at this stage.</p>

doc/mdx.html

@@ -25,7 +25,7 @@
 ######################## -->
 <h3>What is MDX?</h3>
 
-<p>MDX is stands for 'multi-dimensional expressions'. It is the main query language implemented by Mondrian.</p>
+<p>MDX stands for 'multi-dimensional expressions'. It is the main query language implemented by Mondrian.</p>
 
 <p>MDX was introduced by Microsoft with Microsoft SQL Server OLAP Services in around 1998, as the language component of the OLE DB for OLAP API. More recently, MDX has appeared as part of the XML for Analysis API. Microsoft proposed MDX as a standard, and its adoption among application writers and other OLAP providers is steadily increasing.</p>
 

doc/schema.html

@@ -244,7 +244,7 @@ <h1>3.2 Measures<a name="Measures">&nbsp;</a></h1>
 	</code>
 </blockquote>
 <p>Each measure (see <code><a href="#XML_Measure">&lt;Measure&gt;</a></code>) has a name, a column in the fact table, and an 
-<code>aggregator</code>. The aggregator is usually "sum", but "count", "mix", "max", "avg", and 
+<code>aggregator</code>. The aggregator is usually "sum", but "count", "min", "max", "avg", and 
 "distinct count" are also allowed; "distinct count" has some limitations if your cube contains a 
 <a href="#Parent_child_hierarchies">parent-child hierarchy</a>.</p>
 
@@ -1236,7 +1236,7 @@ <h1>5.2.2 Closure tables</h1>
 </blockquote>
 
 <p>This table allows totals to be evaluated in pure SQL. Even though this introduces an extra 
-able into the query, database optimizers are very good at handling joins. I recommend that 
+table into the query, database optimizers are very good at handling joins. I recommend that 
 you declare both <code>supervisor_id</code> and <code>employee_id</code> NOT NULL, and index 
 them as follows:</p>