Apply Dave's suggestions from code review

Co-authored-by: David Waltermire <david.waltermire@nist.gov>

README_validations.md

@@ -2,39 +2,39 @@
 
 ## XML or JSON?
 
-XML files use XML syntax: they are *well-formed* by the rules of XML. (See page on wf vs/and valid.) If you can process your file using a conformant XML processor, it is XML.
+XML files use XML syntax: they are *well-formed* by the rules of XML. (See page on wf vs/and valid.) If you can process your file using a conformant XML parser, the file is XML.
 
-Same for JSON (although of course you need a JSON processor, not an XML processor).
+This same notion applies for JSON and YAML (although of course you need a JSON or YAML parser, instead of an XML parser).
 
-But *validating* goes beyond parsing: it tells you not only that a file is can be read successfully, but also that its data structures conform to rules known ahead or stipulated for a particular application of XML or JSON. All XML is well-formed XML, but only OSCAL XML is valid to the OSCAL models. Likewise with JSON and YAML.
+But *validating* goes beyond parsing: it tells you not only that a file can be read successfully, but also that its data structures conform to rules for a particular application of XML, JSON, or YAML. Just because an XML instance is well-formed XML, doesn't mean it is valid OSCAL XML. Likewise with JSON and YAML.
 
 If working with XML you will need an XML *schema* (or functional equivalent) to validate your OSCAL. If working with JSON or YAML, you will need a JSON Schema. Normative schemas suitable for validating the various OSCAL models are available on the [project web site]().
 
-## What is my model?
+## What are the OSCAL models?
 
-OSCAL comes in several different forms, depending on the data set. At time of writing we have the following models. Each will come with its own schema.
+OSCAL comes in several different forms, depending on the data set. At the time of writing there are the following OSCAL models. Each comes with its own XML and JSON schema.
 
 | Model | XML Schema | JSON Schema |
 | -------- | -------- | -------- |
 | Catalog | LINK     | LINK     |
 | Profile | LINK     | LINK     |
-| System security plan (SSP) | LINK     | LINK     |
-| Component definition | LINK     | LINK     |
+| System Security Plan (SSP) | LINK     | LINK     |
+| Component Definition | LINK     | LINK     |
 | Assessment Plan | LINK     | LINK     |
 | Assessment Results | LINK     | LINK     |
 | Plan of Action & Milestones (POAM) | LINK     | LINK     |
 
 Once you have the model and the schema to validate it with, you are ready.
 
-## OSCAL "all" schema
+## OSCAL "complete" schema
 
-Additionally, for both XML and JSON we have an "all" schema, which can validate any kind of OSCAL, distinguishing them internally. It is larger and more complex than the model-specific schemas and may not be as efficient or useful; but it can be convenient for certain use cases.
+Additionally, there are "complete" XML and JSON schemas, which can validate any kind of OSCAL. It is larger and more complex than the model-specific schemas and may not be as efficient or useful, but it can be convenient for certain use cases.
 
 ## How do I apply a schema to a document to determine validity?
 
-Schemas are built using standard schema languages, in order that commodity tools can all apply the same schemas to the same documents, and give the same results.
+Schemas are built using standard schema languages that are supported by commodity tools. These tools can all apply the same schemas to the same documents, and give the same results.
 
-For OSCAL XML Schemas, this syntax is XSD (XML Schema Definition). For JSON Schemas, it is JSON Schema v7. Free and open-source implementations are available for these; they are also built in to many common application frameworks and dev environments.
+For OSCAL XML Schemas, this syntax is XML Schema Definition (XSD). For JSON Schemas, it is JSON Schema. Many freely available and open-source implementations are available for these, as well as commercial tools. These schema standards are also built in to many common application frameworks and development environments.
 
 Each tool will have its own way to provide for validation. Bindings or configurations to link documents to schemas can be maintained either inside or outside the documents themselves; many tools offer several ways to do this.
 
@@ -63,7 +63,7 @@ test-profile.xml validates
 
 In other words, no data is returned other than the statement that validation has been performed successfully.
 
-(If you remove the `--nonout` flag from the command line, a copy of the input will be returned. This is because the utility is designed for a pipeline architecture, whose outputs will be a functio of its inputs.)
+If you remove the `--nonout` flag from the command line, a copy of the input will be returned. This is because the utility is designed for a pipeline architecture, whose outputs will be provided as the next tool's inputs.
 
 The results from validating an OSCAL JSON file using AJV will look like this: