Use cases: Reword some language for clarity

Author: awwright

jsonschema-use-cases.xml

@@ -68,7 +68,7 @@
             </t>
 
             <t>
-                Use Cases catalog a variety of personal objectives that users may have, due to various objectives and constraints, that the specification shall address, but without concern for a specific design or implementation. Use cases guide the minimum functionality that the specification must be capable of.
+                Use Cases catalog a variety of personal objectives that users may have, due to various motivations and constraints, that the specification shall accommodate, but without proscribing a specific design or implementation.
             </t>
 
             <t>
@@ -78,7 +78,7 @@
 
         <section title="Objectives">
             <t>
-                JSON Schema shall be built to support the following objectives, including expansion into uses not currently described by any use case, but which fall within the objectives.
+                JSON Schema shall be built to support the following objectives, supporting expansion into uses not currently described by any use case, but which fall within the objectives.
             </t>
 
             <section title="Validation">
@@ -115,7 +115,7 @@
 
         <section title="Use Cases">
             <t>
-                JSON Schema shall written to standardize these use cases, or to accommodate implementations targeted at these uses.
+                JSON Schema shall written to standardize these use cases, or shall accommodate implementations targeted at these uses.
             </t>
 
             <section title="Structural validation" anchor="uc-structural">
@@ -248,8 +248,8 @@
                 <t>
                     Not every feature needs to be supported by every implementation.
                     To accommodate a wide variety of niche audiences, it should be possible to specify features that are optional to implement.
-                    This includes standardized features that are optional to implement, and bespoke or user-defined features that are not standardized.
-                    Implementations that do not support optional extensions must degrade in a predictable fashion.
+                    This includes standardized features that are optional to implement, bespoke or user-defined features that are not standardized, and new features added to future publications of the specification.
+                    For forward compatibility, implementations that do not support optional extensions must degrade in a predictable fashion.
                 </t>
             </section>
 
@@ -261,7 +261,7 @@
 
             <section title="Intra-document data consistency validation">
                 <t>
-                    A JSON document may carry relational data whose consistency must be verified. Example constraints include:
+                    A JSON document may carry relational data that must be internally consistent. Example constraints include:
                 </t>
                 <ul>
                     <li>One-to-one calculations, like that children's birthdates come after their parent's birthdates;</li>
@@ -271,7 +271,7 @@
 
             <section title="Inter-database consistency validation">
                 <t>
-                    A JSON document may carry relational data whose consistency must be verified. Example constraints include:
+                    A JSON document may carry relational data that must be verified against outside data sources. Example constraints include:
                 </t>
                 <ul>
                     <li>References to a user ID points to a user in a central users database.</li>
@@ -284,10 +284,10 @@
                     Sometimes it's desirable to require formatting that does not impact the application-level meaning of the document, but instead specifies requirements purely for aesthetic or compatibility reasons.
                 </t>
                 <t>
-                    For example, for security reasons, a linter may need to ensure that a JSON document does not contain the string "<tt>&lt;/script</tt>" but is written instead with a character escape such as "<tt>&lt;\/script</tt>". This would ensure that, if the JSON were to be embedded in a <tt>&lt;script&gt;</tt> tag, that it would not have any part that could close the tag and start being interpreted as HTML.
+                    For example, for security reasons, an application may want to verify a JSON document does not contain the string "<tt>&lt;/script</tt>" but is written instead with a character escape such as "<tt>&lt;\/script</tt>". This would ensure that, if the JSON were to be embedded in a <tt>&lt;script&gt;</tt> tag, it could not close the tag and be interpreted as HTML.
                 </t>
                 <t>
-                    This is not a standard part of JSON Schema because it may violate the semantics of JSON, by adding an ability to distinguish two documents that are supposed to be equal to the receiving application.
+                    This is not a standard part of JSON Schema because it may violate the semantics of JSON, by adding an ability to distinguish between encodings which are supposed to be equal to receiving applications.
                 </t>
             </section>
         </section>