Update docs

lwasylow · lwasylow · commit 10a6bf705057 · 2019-03-15T13:24:32.000Z
diff --git a/docs/userguide/advanced_data_comparison.md b/docs/userguide/advanced_data_comparison.md
@@ -6,7 +6,7 @@ utPLSQL expectations incorporates advanced data comparison options when comparin
 - object type
 - nested table and varray  
 
-Advanced data-comparison options are available for the [`equal`](expectations.md#equal) and  [`include / contain`](expectations.md#include--contain) matcher.
+Advanced data-comparison options are available for the [`equal`](expectations.md#equal) and  [`contain`](expectations.md#include--contain) matcher.
 
 ## Syntax
 
@@ -164,7 +164,7 @@ Above test will result in two differences of one row extra and one row missing.
 
 **Note**
 
-> `include / contain` matcher is not considering order of compared data-sets. Using `unordered` makes no difference (it's default)
+> `contain` matcher is not considering order of compared data-sets. Using `unordered` makes no difference (it's default)
 
 
 ## Join By option
@@ -375,10 +375,10 @@ end;
 
 ## Unordered columns / uc option
 
-If you need to perform data comparison of cursors without strictly deending on column order in the returned result-set, use the `unordered_columns` option.
+If you need to perform data comparison of compound data types without strictly depending on column order in the returned result-set, use the `unordered_columns` option.
 Shortcut name `uc` is also available for that option.
 
-Expectations that compare cursor data with `unordered_Columns` option, will not fail when columns are ordered differently.
+Expectations that compare compound data type data with `unordered_columns` option, will not fail when columns are ordered differently.
 
 This option can be useful whn we have no control over the ordering of the column or the column order is not of importance from testing perspective.
 
diff --git a/docs/userguide/expectations.md b/docs/userguide/expectations.md
@@ -435,9 +435,9 @@ To change the behavior of `NULL = NULL` comparison pass the `a_nulls_are_equal =
 
 ## contain
 
-This matcher supports only cursor comparison. It check if the give set contain all values from given subset.
+This matcher supports only compound data comparison. It check if the give set contain all values from given subset.
 
-When comparing data using `contain` matcher, the data-types of columns for compared cursors must be exactly the same.
+When comparing data using `contain` matcher, the data-types of columns for compared compound types must be exactly the same.
 
 The matcher supports all advanced comparison options as `equal` like: `include` , `exclude`, `join_by` etc..
 
@@ -716,7 +716,7 @@ utPLSQL is capable of comparing compound data-types including:
 
 - Compound data can contain elements of any data-type. This includes blob, clob, object type, nested table, varray or even a nested-cursor within a cursor.
 - Attributes in nested table and array types are compared as **ordered lists of elements**. If order of attributes in nested table and array differ, expectation will fail.
-- Columns in cursors are compared as **ordered list of elements** by default. Use `unordered_columns` option when order of columns in cursor is not relevant
+- Columns in compound data are compared as **ordered list of elements** by default. Use `unordered_columns` option when order of columns in cursor is not relevant
 - Comparison of compound data is data-type aware. So a column `ID NUMBER` in a cursor is not the same as `ID VARCHAR2(100)`, even if they both hold the same numeric values.
 - Comparison of cursor columns containing `DATE` will only compare date part **and ignore time** by default. See [Comparing cursor data containing DATE fields](#comparing-cursor-data-containing-date-fields) to check how to enable date-time comparison in cursors.
 - Comparison of cursor returning `TIMESTAMP` **columns** against cursor returning `TIMESTAMP` **bind variables** requires variables to be casted to proper precision. This is an Oracle SQL - PLSQL compatibility issue and usage of CAST is the only known workaround for now. See [Comparing cursor data containing TIMESTAMP bind variables](#comparing-cursor-data-containing-timestamp-bind-variables) for examples.    
