Wording clarifications in general considerations.

These are the leftover bits of Issue json-schema-org#55 and some clarifications
requested in a comment on issue json-schema-org#101 that have not already been
added in some other PR for some other issue.

These specific chagnes were previously approved in json-schema-org#143, but so
many other things have changed since json-schema-org#143 that most of it was
no longer relevant, so I closed it and started these changes over.

In particular, explaining {} and {"not": {}} is no longer needed
as they are covered while introducing "true" and "false" schemas
in the core specification, so that is no longer repeated in this
change.

Likewise, the parent/child validation descriptions have been
modified in several PRs and no longer has the problems that were
previously a concern.

jsonschema-validation.xml

@@ -191,21 +191,25 @@
                 </t>
             </section>
 
-            <section title="Missing keywords">
+            <section title="Constraints and missing keywords">
+                <t>
+                    Each JSON Schema validation keyword adds constraints that
+                    an instance must satisfy in order to successfully validate.
+                </t>
                 <t>
                     Validation keywords that are missing never restrict validation.
                     In some cases, this no-op behavior is identical to a keyword that exists with certain values,
                     and these values are noted where known.
                 </t>
             </section>
 
-            <section title="Linearity">
-                <!-- I call this "linear" in the same manner e.g. waves are linear, they don't interact with each other -->
+            <section title="Keyword independence">
                 <t>
-                    Validation keywords typically operate independent of each other, without affecting each other.
+                    Validation keywords typically operate independently, without
+                    affecting each other's outcomes.
                 </t>
                 <t>
-                    For author convenience, there are some exceptions:
+                    For schema author convenience, there are some exceptions:
                     <list>
                         <t>"additionalProperties", whose behavior is defined in terms of "properties" and "patternProperties";</t>
                         <t>"additionalItems", whose behavior is defined in terms of "items"; and</t>