Use cases: Merge standard and extension use cases

Author: awwright

jsonschema-use-cases.xml

@@ -78,7 +78,7 @@
 
         <section title="Objectives">
             <t>
-                JSON Schema shall be built to support two objectives, including expansion into uses not currently described by any use case, but fall within the objectives.
+                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.
             </t>
 
             <section title="Validation">
@@ -98,7 +98,7 @@
 
             <section title="Internet">
                 <t>
-                    JSON is a technology standardized as a part of a larger ecosystem of Internet technology, and likewise, JSON Schema may also specify how it is used in this ecosystem, for example, use in HTTP, or the meaning of media type parameters.
+                    JSON is a technology standardized as a part of a larger ecosystem of Internet technology, and likewise, JSON Schema may also specify its role in this ecosystem; for example, use in HTTP, or the meaning of media type parameters.
                 </t>
             </section>
 
@@ -107,15 +107,15 @@
                     Use cases or requirements that do not advance these objectives are likely out of scope, and better suited in separate work that references JSON Schema.
                 </t>
                 <t>
-                    For example, a method of describing an API interface would exceed the scope of JSON Schema, although JSON Schema may be used as a part of such a description, in the cases where describing JSON documents is necessary.
+                    For example, a method of describing an API interface would exceed the scope of JSON Schema, although JSON Schema may be used as a part of such a description, such as when the API is using JSON and needs a way to describe these JSON documents.
                 </t>
             </section>
 
         </section>
 
         <section title="Use Cases">
             <t>
-                JSON Schema shall standardize these use cases.
+                JSON Schema shall written to standardize these use cases, or to accommodate implementations targeted at these uses.
             </t>
 
             <section title="Structural validation" anchor="uc-structural">
@@ -246,24 +246,16 @@
 
             <section title="Extension points" anchor="extension-points">
                 <t>
-                    Application developers may wish to express a wide variety of constraints that would be impractical to require every validator to implement.
-                </t>
-                <t>
-                    Like in the <xref target="partial-validation">"Partial validation"</xref> use case, validators need to understand when the extension is not supported, and allow the application to determine if validation may continue without it. For example, if a Web API does not use XML, it would be unnecessary for its JSON validator to support keywords dealing with XML, so in this case, it's appropriate for its JSON validator to reject constraints dealing with XML altogether.
+                    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.
                 </t>
             </section>
-        </section>
-
-        <section title="Use cases for extensions">
-            <t>
-                This section lists use cases that are not required for interoperability and are not standardized, but fall within the objectives and could be standardized in the future.
-                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>
 
             <section title="External validation">
                 <t>
-                    JSON may embed resources of other media types, like base64 or hex-encoded documents; and may wish to pass off validation of these documents to another software tool.
+                    Authors may embed resources of other media types, such as text documents, or base64 or hex-encoded binary documents; and may wish to pass off validation of these documents to another software tool.
                 </t>
             </section>
 
@@ -295,7 +287,7 @@
                     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.
                 </t>
                 <t>
-                    This is not a core part of JSON because it may violate the semantics of JSON, 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 two documents that are supposed to be equal to the receiving application.
                 </t>
             </section>
         </section>