diff --git a/tconfpy.3 b/tconfpy.3
index 2bd8437..0cb066f 100644
--- a/tconfpy.3
+++ b/tconfpy.3
@@ -91,7 +91,7 @@
                          InitialSymTable={},
                          AllowNewVars=True,
                          AllowNewNamespaces=True,
-                         LiteralVars=False,
+                         LiteralVars=True,
                          Debug=False
                         )
 
@@ -129,7 +129,7 @@
 .B LiteralVars   (Default: False)
 
 
-If set to True this option enables variable substitutions within
+If set to False this option enables variable substitutions within
 \'.literal\' blocks of a configuration file.  See the section in the
 language reference below on \'.literal\' usage for details.
 
@@ -670,7 +670,6 @@
 other language or text.
 
 
-
 .SS The \'Debug\' API Option
 
 \*(TC has a fairly rich set of debugging features built into its
@@ -1442,18 +1441,152 @@
 
 
 
-.SS The \'.include\' Directive
-
-.SS Conditional Directives
-
-.SS \'.literal\. - Using \*(TC As A Preprocessor For Other Languages
-
 .SS Type And Value Enforcement
 
-.SS Some Notes On Boolean Variables
+By default, any variable (or namespace) you create in a configuration file
+is understood to just hold a string of characters.  There are no limits
+to what that string may contain, how long it is, and so on.
+
+However, \*(TC gives the programmer considerable power to enforce variable
+types and values, if they so choose.  (See the section above entitled,
+.B PROGRAMMING USING THE \*(TC API
+for the details.)  The programmer can set all kinds of limitations
+about a variable's type, permissible values, and (in the case of
+strings) how long or short it may be.  The programmer does this by
+defining these limitations for each variable of interest
+.B prior to calling \*(TC to parse your configuration file.
+In that case, when \*(TC actually processes the configuration file,
+it "enforces" these restrictions any time you attempt to change the
+value of one of these variables.  If you try to assign a value that
+fails one of these "validation" tests, \*(TC will produce an error
+and leave the variable's value unchanged.
+
+For instance, suppose the programmer has defined
+variable "Foo" to be a floating point number, and that it must have
+a value between -10.5 and 100.1.  In that case:
+
+.nf
+    Foo  = 6.023E23     # Error - Value is out of range
+    Foo  = MyGoodness   # Error - Value must be a FP number, not a string
+    Foo  = -2.387       # Good  - Value is both FP an in range
+.fi
+
+
+.SS What Specific Validations Are Available?
+
+The programmer has several different restrictions they can place on
+a variable's value.  You do not need to understand how they work,
+merely what they are so that any error messages you see will make sense.
+
+.IP \(bu 4 
+The programmer may declare any variable to be
+.B Read Only.
+This means you can still use references to that variable to extract
+its value, but any attempt to change it value within the configuration
+file will fail and produce an error.
+
+.IP \(bu 4
+The programmer may specify the variable's
+.B type
+as string (the default), integer, floating point, complex, or boolean.
+
+.IP \(bu 4
+The programmer may specify 
+.B the set of all legal values
+that can be assigned to a variable.  For instance, the programmer
+might specify that the floating point variable \'Transcend\' can only
+be set to either 3.14 or 2.73.  Similarly, the programmer might
+specify that the string variable \'Color\' can only ever be set to
+\'Red\', \'Green\', or \'Blue\'.  In fact, in the case of string
+variables, the programmer can actually specify a set of patterns
+(regular expressions) the value has to match.  For instance, they can
+demand that you only set a particular string variable to strings that
+begin with \'a'\ and end with \'bob\'.
+
+.IP \(bu 4
+For integer and floating point variables, the programmer can specify
+a legal
+.B value range
+for the variable.  If you change the value of such a variable, that value
+must be within the defined range or you'll get an error.
+
+.IP \(bu 4
+For string variables, the programmer can specify a minimum and maxium
+.B length
+for the strings you assign to the variable in question.
+
+.IP \(bu 4
+The programmer can limit you to
+.B only being able to use existing variables.
+(.i.e. The Predefined variables and any variables the programmer
+has defined ahead of time.)  In that case, any attempt to create a
+new variable in the configuration file will fail and produce an error.
+
+.IP \(bu 4
+The programmer can limit you to
+.B only being able to use namespaces they have defined ahead of time.
+In that case, if you attempt to enter a namespace not on the list
+the programmer created ahead of time will fail and produce an error.
+
+.IP \(bu 4
+The programmer can enable or prevent
+.B the substitution of variable references in literal blocks
+(see below).  If they disable this option, something like \'[Foo]\'
+is left unchanged within the literal block. i.e., It too, is treated
+"literally".
+
+
+.SS Notes On Variable Type/Value Enforcement
+
+There are a few other things you should know about how \*(TC 
+enforces restrictions on variables:
+
+.IP \(bu 4
+Within the configuration file,
+.B variable references are always converted to strings
+regardless of the actual type of the variable in question.   For
+instance, suppose the programmer defines variable \'Foo\' to be
+floating point.  Then:
+
+.nf
+    Foo = 1.23
+    Bar = Value is [Foo] # Creates a new *string* variable with the
+                         # value: "Value is 1.23"
+.fi
+
+In other words, variable values are "coerced" into strings for
+the purposes of substution and conditional testing within a
+configuration file.
+            
+
+.IP \(bu 4
+You cannot create anything but a string variable with no limitations
+from within a configuration file.  All validation features
+.B require
+the limitations to be specified by the calling program ahead of time.
+
+.IP \(bu 4
+Similarly, you cannot change any of the enforcement options from
+within a configuration file.  These features are only available
+under program control, presumably by the application program that
+is calling \*(TC.
+
+.IP \(bu 4
+There is no way to know what the limitations are on a particular
+variable from within the configuration file.  Programmers
+who use these features should document the variable restrictions
+they've employed as a part of the documentation for the application
+in question.
+
+
+
+.SS Some Further Notes On Boolean Variables
 
 One last note here concerns Boolean variables.  Booleans are actually
-stored in the symbol table as the Python values, True or False.
+stored in the symbol table as the Python boolean values,
+.B True
+or
+.B False.
 However, \*(TC accepts user statements that set the value of the
 boolean in a number of formats:
 
@@ -1479,17 +1612,23 @@
 observe case and test for either \'True\' or \'False\':
 
 .nf
-     boolvar = YES
+     boolvar = No
 
-    .if [boolvar] != False    # This works fine
+    .if [boolvar] == False    # This works fine
 
-    .if [boolvar] != FALSE    # This does not work - Case is not being observed
+    .if [boolvar] == FALSE    # This does not work - Case is not being observed
 
-    .if [boolvar] != Off      # Neither does this - Only True and False can be tested
+    .if [boolvar] == Off      # Neither does this - Only True and False can be tested
 
 .fi
 
 
+.SS The \'.include\' Directive
+
+.SS Conditional Directives
+
+.SS The  \'.literal\. Directive
+
 .SH ADVANCED TOPICS
 
 .SS Guaranteeing A Correct Base Configuration