Reword structural validation, and add linting section for contrast

Author: awwright

jsonschema-use-cases.xml

@@ -71,14 +71,14 @@
                 Requirements list functional and non-functional or quality requirements, and the use cases they may be derived from/related to.
             </t>
         </section>
-
+expressed as a context-free grammar that follows JSON
         <section title="Use Cases">
             <section title="Structural validation" anchor="uc-structural">
                 <t>
-                    Structural validation allows specifications to use JSON Schema to define a protocol where all equivalent encodings of a value will validate the same, as opposed to generic formal grammars that cannot provide this guarantee. A validator language that supports structural validation can entirely replace generic grammars such as <xref target="RFC5234">ABNF</xref>.
+                    Structural validation refers to define the "structure" or pattern that a JSON document is supposed to follow, such as which properties must exist, what types of values are expected where, and what they must look like. More specifically, structural validation is any validation that can be expressed as a context-free grammar that follows JSON semantics, so that different forms which are equal according to JSON will be guaranteed to have the same validation result.
                 </t>
                 <t>
-                    Structural validation is a type of "context-free" validation: validation that can be performed with a finite amount of states or a stack of them, which do not distinguish between different encodings of the same value (the "structure"), but at each step, only uses the current state, without reading from other parts of the document (the "context"). Schemas that limit themselves to structural validation keywords can be implemented as a deterministic pushdown automata, and guaranteed to return a result in proportional time.
+                    Validators that support structural validation can entirely replace generic grammar languages such as <xref target="RFC5234">ABNF</xref> and in addition, guarantee compliance with JSON semantics. Schemas whose validation is limited to structural validation can be implemented as a deterministic pushdown automata, and guarantee a result in proportional time without error.
                 </t>
                 <t>
                     The following features of JSON are part of structural validation:
@@ -93,7 +93,7 @@
                     <t>Descent into object properties and array items</t>
                 </list>
                 <t>
-                    Multiple forms that are value-equal according JSON need not be distinguished under this use-case. This includes the ordering of properties in an object, character escapes in strings, and whitespace.
+                    Multiple forms that are value-equal according to JSON are not distinguishable under this use-case. This includes the ordering of properties in an object, character escapes in strings, and whitespace.
                 </t>
             </section>
 
@@ -199,7 +199,7 @@
 
         <section title="Use cases for extensions">
             <t>
-                This section lists use cases that not required for interoperability in media type handling, but which should be defined as as standard extensions to maximize support and feature interoperability.
+                This section lists use cases that not required for interoperability in media type handling, but which should be defined as standard extensions to maximize support and feature interoperability.
                 As specified in <xref target="extension-points">"Extension points,"</xref>
                 validators should gracefully degrade in the presence of extensions that they do not support.
             </t>
@@ -230,6 +230,18 @@
                 </ul>
             </section>
 
+            <section title="Linting">
+                <t>
+                    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 "&lt;/script" but instead contains a character escape such as "&lt;\/script". This would ensure that, if the JSON were to be embedded in a &lt;script&gt; tag, that it would not have any part that could be interpreted as HTML.
+                </t>
+                <t>
+                    This is not a core part of JSON because it may violate the semantics of JSON, adding an ability to distinguish two document that JSON requires be equal to the receiving application.
+                </t>
+            </section>
+
         </section>
 
         <section title="Requirements" anchor="requirements">