Fixed typos related to issues usnistgov#402, usnistgov#403, and usnis…

…tgov#404 (usnistgov#412)

docs/content/learnmore/assessors.html

@@ -27,6 +27,6 @@ <h3>How Does OSCAL Help Me?</h3>
   <li>
   <p>Provides ongoing, automated assessment of an information systems assurance, allowing any drift in control implementation to be detected as it occurs, reducing overall risk.</p></li>
   <li>
-  <p>Enables mapping standard catalogs of controls and common baselines, to system implmentations, reducing the number of assessments required to ensure compliance with multiple frameworks.</p></li>
+  <p>Enables mapping standard catalogs of controls and common baselines, to system implementations, reducing the number of assessments required to ensure compliance with multiple frameworks.</p></li>
 </ul>
 </div>

docs/content/learnmore/roadmap.md

@@ -10,7 +10,9 @@ layout: post
 
 ## The problem solved by OSCAL
 
-The IT security domain is characterized by a growing number of regulatory guidelines and frameworks, such as NIST Special Publication (SP) 800-53, NIST Cybersecurity Framework, ISO/IEC 27001 and 27002, COBIT, PCI DSS, HIPAA, and so others. Within this context, the major challenge of IT systems security is developing, applying and coordinating consistent and appropriate policies, both within and across organizational boundaries. With the advent of cloud and the Internet of Things (IoT), the complexity of the IT landscape in general is increasing, with a broadening and dispersal of the attack surface and a proliferation of vulnerabilities: this too makes system security planning more complicated. A great deal of system security planning, auditing, and assessing is now done using spreadsheets and (page-oriented) word processors, supporting manual and paper-based compliance processes. This approach is not only labor intensive, it also takes time, sometimes resulting in documentation that is out of date soon after it is produced -- which can leave critical risks undiscovered or unaddressed. When a system plan and system description is unable to keep up with reality on the ground (a phenomenon sometimes referred to as "security drift"), it becomes a pointless exercise as well as a costly one.
+The IT security domain is characterized by a growing number of regulatory guidelines and frameworks, such as NIST Special Publication (SP) 800-53, NIST Cybersecurity Framework, ISO/IEC 27001 and 27002, COBIT, PCI DSS, HIPAA, and so others. Within this context, the major challenge of IT systems security is developing, applying and coordinating consistent and appropriate policies, both within and across organizational boundaries. With the advent of cloud and the Internet of Things (IoT), the complexity of the IT landscape in general is increasing, with a broadening and dispersal of the attack surface and a proliferation of vulnerabilities: this too makes system security planning more complicated.
+
+A great deal of system security planning, auditing, and assessing is now done using spreadsheets and (page-oriented) word processors, supporting manual and paper-based compliance processes. This approach is not only labor intensive, it also takes time, sometimes resulting in documentation that is out of date soon after it is produced -- which can leave critical risks undiscovered or unaddressed. When a system plan and system description is unable to keep up with reality on the ground (a phenomenon sometimes referred to as "security drift"), it becomes a pointless exercise as well as a costly one.
 
 <img src="{{ site.baseurl }}/assets/img/oscal-components.png" alt="oscal components" width="800"/>
 
@@ -53,7 +55,7 @@ NIST's Open Security Controls Assessment Language (OSCAL) serves as a "Standard
 
 ## The OSCAL approach
 
-OSCAL is being developed leveraging an incremental and agile approach. Through a series of development sprints, increased value is provided with a focus on an 80% solution (Minimally Viable Product (MVP)) that can be implemented in 20% of the time. OSCAL is a community-driven, NIST-led project, with an open invition to the community to participate in the framing and development of OSCAL. User stories can be created and submitted directly into GitHub per the requirements defined in the OSCAL CONTRIBUTING.MD. To learn more, [contact us]({{ site.baseurl }}/contact/).
+OSCAL is being developed leveraging an incremental and agile approach. Through a series of development sprints, increased value is provided with a focus on an 80% solution (Minimally Viable Product (MVP)) that can be implemented in 20% of the time. OSCAL is a community-driven, NIST-led project, with an open invitation to the community to participate in the framing and development of OSCAL. User stories can be created and submitted directly into GitHub per the requirements defined in the OSCAL CONTRIBUTING.MD. To learn more, [contact us]({{ site.baseurl }}/contact/).
 <!-- Include link to CONTRIBUTING.MD -->
 
 ### OSCAL Guiding Principles

docs/content/resources/examples/catalogs.md

@@ -12,11 +12,11 @@ subnav:
     href: /resources/examples/profiles/
 ---
 
-## NIST 800-53
+## NIST SP 800-53
 
-A complete representation of [NIST 800-53 encoded in OSCAL](https://github.com/usnistgov/OSCAL/blob/master/content/nist.gov/SP800-53/rev4/xml/NIST_SP-800-53_rev4_catalog.xml) including materials from Appendix A (Assessments and Objectives), is available on the OSCAL web site.
+A complete representation of [NIST SP 800-53 encoded in OSCAL](https://github.com/usnistgov/OSCAL/blob/master/content/nist.gov/SP800-53/rev4/xml/NIST_SP-800-53_rev4_catalog.xml) including materials from Appendix A (Assessments and Objectives), is available on the OSCAL web site.
 
-Here is a (non-normative, partial) copy showing how control **AC1** from NIST SP800-53 can be rendered in OSCAL in XML with a `<control>` element. A short walkthrough follows.
+Here is a (non-normative, partial) copy showing how control **AC1** from NIST SP 800-53 can be rendered in OSCAL in XML with a `<control>` element. A short walkthrough follows.
 
 ```xml
 {% include examples/catalog.xml %}
@@ -29,7 +29,7 @@ structured.
 - The control ID is "ac.1". All `id` values are unique within the document and serve for addressing and linking. In the case of controls and subcontrols, the lexical form of the `id` is designed to be consistent with its formal name or label, which is **also** encoded within the control (in this case, "AC-1"). A discrepancy between these values indicates degradation in the data.
 - `<param>` elements define parameter values for the control that permit (and may require) setting in context. Typically, a catalog will expose parameters where profiling applications are expected either to provide values themselves (appropriate to each profile) or to permit setting at higher levels of implementation. These values are available for assignment wherever indicated in the language of the control, using corresponding `<insert/>` elements.
 - `<prop>` elements specify properties appropriate to this control. Here only a `label` property is given, for the control's canonical label. For other catalogs, other properties may assign values to controls according to any system of labels or associations.
-- `<part>` elements indicate larger articulated structures. Here the part provides the *statement* for the control (as shown by its class). In SP800-53, control statements give the text (formal prose definition and description) of the control. As the example shows, statements can also be articulated into subparts, with each discrete piece of the statement handled separately and assigned its own identifier.
+- `<part>` elements indicate larger articulated structures. Here the part provides the *statement* for the control (as shown by its class). In SP 800-53, control statements give the text (formal prose definition and description) of the control. As the example shows, statements can also be articulated into subparts, with each discrete piece of the statement handled separately and assigned its own identifier.
 - `<insert>` elements reference parameters (`param-id` referencing parameter IDs) to bring in user-defined values.
 
 The following snippet from the example above contains supplemental guidance given with the control (line breaks added for readability).
@@ -51,7 +51,7 @@ The following snippet from the example above contains supplemental guidance give
 </part>
 ```
 
-Note that unlike the control statement, which has a structure whose parts are labelled and addressable, the supplemental guidance is a simple paragraph. Where catalogs do not provide structure, OSCAL does not impose any.
+Note that unlike the control statement, which has a structure whose parts are labeled and addressable, the supplemental guidance is a simple paragraph. Where catalogs do not provide structure, OSCAL does not impose any.
 
 Finally, the control description gives references for the control:
 

src/file-naming-conventions.md

@@ -142,7 +142,7 @@ oscal_{OSCAL Model}_{Source Format}-to-{Destination Format}_converter[_{File Rev
 The following XSL template converts an OSCAL catalog in JSON format to the OSCAL catalog XML format:
 
 ```
-oscal-catalog-json-to-xml-converter.xsl
+oscal_catalog_json-to-xml-converter.xsl
 ```
 
 Uses the following fields: