Addressing typos for issue #947. (#955)

docs/content/about/_index.md

@@ -27,7 +27,7 @@ There are a number of complicating factors contributing to the challenges faced
 * Regulatory standards and frameworks overlap in scope and can often conflict or be difficult to manage together; and
 * Information systems are increasing in size and complexity.
 
-To address information security and privacy risks, the implementation of selected controls need to be verified and shown to be effective. To provide assurance of a system's security and privacy posture, the control implementation of a system must be both correctly described, assessed, and authorized. These tasks are resource-intensive, and often challenging to perform within budget constraints given the complexity of the problem.
+To address information security and privacy risks, the implementation of selected controls needs to be verified and shown to be effective. To provide assurance of a system's security and privacy posture, the control implementation of a system must be both correctly described, assessed, and authorized. These tasks are resource-intensive, and often challenging to perform within budget constraints given the complexity of the problem.
 
 The standardized formats provided by the OSCAL project help to streamline and standardize the processes of documenting, implementing and assessing security controls. The automation enabled by the OSCAL formats will reduce complexity, decrease implementation costs, and enable the simultaneous, continuous assessment of a system's security against multiple sets of requirements. Additionally, paperwork will be significantly reduced.
 
@@ -59,7 +59,7 @@ The OSCAL project is working to address the following goals.
 
 Drive a large decrease in the paperwork burden for both information security professionals and vendors.
 
-- Normalize the representation of security control catalogs, regulatory frameworks, and system information using precise, machine readable formats.
+- Normalize the representation of security control catalogs, regulatory frameworks, and system information using precise, machine-readable formats.
 - Allow the sharing of control implementation information across communities.
 
 ### Improve System Security Assessments

docs/content/about/use-cases/_index.md

@@ -29,9 +29,9 @@ To meet the requirements of different regulatory frameworks and to perform good
 
 OSCAL is designed to provide a standardized format that reduces or eliminates this paper-based process, by transitioning documentation to a highly normalized, machine-readable format. This approach has multiple benefits:
 
-1. data between plans is consistent in both format and mapping to requirements and controls from multiple regulatory frameworks, when applicable,
-1. data is machine readable and can be exposed to other security tools to provide additional automation, and
-1. data consistency and standardization allows for innovation in the commercial tooling to provide further automation of assessment and accreditation processes.
+1. Data between plans is consistent in both format and mapping to requirements and controls from multiple regulatory frameworks, when applicable,
+1. Data is machine-readable and can be exposed to other security tools to provide additional automation, and
+1. Data consistency and standardization support innovation in commercial and open-source tooling to provide further automation of assessment and accreditation processes.
 
 By representing system information using the OSCAL [system security plan model](/concepts/layer/implementation/ssp/), this data can be analyzed using automated processes, streamlining the review and assessment process. The management systems that are used to manage the security and privacy controls implemented in the system can be integrated to provide up-to-date system information using this model. Human-oriented documentation can be easily generated from the OSCAL data. This results in a more usable information set over what is provided using Word and Excel files alone.
 

docs/content/concepts/layer/_index.md

@@ -37,7 +37,7 @@ The following image depicts each layer and the corresponding model(s) for each l
   {{<area alt="Control Layer" title="Control Layer" href="control/" coords="0,300,896,400" shape="rect">}}
 {{</imagemap>}}
 
-Each OSCAL model is represented in multiple, machine readable *formats* (e.g., XML, JSON, YAML), which provide a serialization and encoding mechanism for representing and exchanging OSCAL data, also referred to as *OSCAL content*.
+Each OSCAL model is represented in multiple, machine-readable *formats* (e.g., XML, JSON, YAML), which provide a serialization and encoding mechanism for representing and exchanging OSCAL data, also referred to as *OSCAL content*.
 
 Individual layers are summarized below, with links to additional layer and model information. There is also an [introduction to the OSCAL models](overview/), as well as information related to the [terminology](../terminology/) used in describing each model.
 

docs/content/concepts/layer/control/catalog/_index.md

@@ -22,7 +22,7 @@ aliases:
 
 The OSCAL catalog model represents a collection of [controls](/concepts/terminology/#control), represented as a control [catalog](/concepts/terminology/#catalog).
 
-The OSCAL catalog model was designed to represent security and privacy controls in standardized, machine readable formats. The OSCAL catalog model standardizes the representation of control definitions from different sources (e.g., SP 800-53, ISO/IEC 27002, COBIT 5) allowing control information to be easily searched, imported, and exported by applications using a common format.
+The OSCAL catalog model was designed to represent security and privacy controls in standardized, machine-readable formats. The OSCAL catalog model standardizes the representation of control definitions from different sources (e.g., SP 800-53, ISO/IEC 27002, COBIT 5) allowing control information to be easily searched, imported, and exported by applications using a common format.
 
 The OSCAL catalog model was designed to represent security and privacy controls; however, it may be possible to apply OSCAL to other applications related to safety, health, or other purposes. These other applications have not been explored so far.
 

docs/content/concepts/layer/overview.md

@@ -83,7 +83,7 @@ UUIDs in OSCAL are intended to uniquely identify information and link informatio
 
 Version 4 Universally Unique Identifier (UUID) as defined by [RFC 4122](https://tools.ietf.org/html/rfc4122) are a good fit for this use case and have been selected for use in OSCAL for this purpose.
 
-Fields containing UUIDs tend to be named `uuid` in OSCAL. When an associated subject is created that has a `uuid` field, then a tool should automatically generate a UUId for this field.
+Fields containing UUIDs tend to be named `uuid` or `xyz-uuid` (where `xyz` refers to the referenced subject with the assigned UUID) in OSCAL. When an associated subject is created that has a `uuid` field, then a tool should automatically generate a UUID for this field.
 
 UUIDs are intended to be consistently used to represent the same concept over multiple major and minor revisions of the same document; thus, they should only be changed if the underlying identified subject has changed in a significant way that no longer represents the same identified subject.
 
@@ -101,7 +101,7 @@ Identifiers may be referenced from other locations within OSCAL content using on
 
 ## Metadata Overview
 
-Every OSCAL document has a <code>metadata</code> section that shares the same structure. The required fields in <code>metadata</code> as as follows:
+Every OSCAL document has a <code>metadata</code> section that shares the same structure. The required fields in <code>metadata</code> are as follows:
 
 1. title: A human readable title for the document, represented in markdown.
 2. last-modified: The date and time that the document was last modified.
@@ -123,7 +123,7 @@ When used this way, <code>document-id</code> allows for consumers of OSCAL docum
 
 OSCAL recommends the use of <code>link</code> to establish resolvable version graphs of OSCAL documents. [RFC5829](https://tools.ietf.org/html/rfc5829) defines a set of values for the <code>rel</code> flag of <code>link</code> that allow for a document to provides resolvable links to the latest version, the next version, and the previous version. With this combination of links, a human or machine consumer of an OSCAL document can understand the version history of a document, and automatically update itself to the latest version.
 
-Note that successful deployment of version control through <code>link</code> requires the document creator to maintain a well-structured static set of ersolvable resources that are reachable from where ever the document is to be consumed (usually on the public web).
+Note that successful deployment of version control through <code>link</code> requires the document creator to maintain a well-structured static set of resolvable resources that are reachable from wherever the document is consumed (usually on the public web).
 
 As an example of such a system, let us assume that "Author" has just released OSCAL document "Example 1.0". They can now setup a redirect system based on the document-id:
 
@@ -177,15 +177,15 @@ In addition to providing improved control over modeling and documentation, the f
 
 OSCAL models are designed to be broadly applicable to a variety of security compliance frameworks and organizational needs. Where an organization has unique modeling needs not supported by the core OSCAL syntax, it is possible to extend the syntax to address these requirements.
 
-Models in OSCAL are organized hierarchically. At each level of this hierarchy, OSCAL syntax provides property (JSON: `property` / XML: `prop`) and annotation (`annotation`) objects. While these are sometimes used for core OSCAL syntax, they can also be assigned an organizational namespace (`ns`) value, which uniquely identifies the organization creating the extension.
+Models in OSCAL are organized hierarchically. At each level of this hierarchy, OSCAL syntax provides property (JSON: `property` / XML: `prop`) objects. While these properties are sometimes used for core OSCAL syntax, they can also be assigned an organizational namespace (`ns`) value, which uniquely identifies the organization creating the extension.
 
-For any property or annotation identified with the organization's namespace, the organization may use any [NCName](/reference/datatypes/#ncname) value in the property/annotation's `name`. This allows the organization to define the containing content as required. Organizations are strongly encouraged to publish these extensions to their community of OSCAL tool developers.
+For any property identified with the organization's namespace, the organization may use any [token](/reference/datatypes/#token) value in the property's `name`. This allows the organization to define the containing content as required. Organizations are strongly encouraged to publish these extensions to their community of OSCAL tool developers.
 
 {{% callout %}}
 **IMPORTANT NOTE TO DEVELOPERS**
 
 Tools should always check for the `ns` assignment within properties and annotations.
-When no `ns` is provided, the default is `http://csrc.nist.gov/ns/oscal`, which means the annotation or property is assumed to be part of the core OSCAL syntax.
+When no `ns` is provided, the default is `http://csrc.nist.gov/ns/oscal`, which means the property is assumed to be part of the core OSCAL syntax.
 
 This is especially important as organizations extending OSCAL may use the same `name` value, but in a different namespace as compared to core OSCAL.
 

docs/content/concepts/relations-to-other.md

@@ -23,7 +23,7 @@ OSCAL seeks to complement HTML and other web technologies such as Markdown, by f
 
 ### MS Word/Excel formats <code>.docx .xlsx</code> (word processor and spreadsheet)
 
-Microsoft's Office Open XML is the format underlying its Word and Excel applications; it is documented as ISO. Ubiquitous as an application format, these formats are tractable using tools built to the applications' APIs and data models, but they are not designed to support application-independepent data exchange. OSCAL enables greater data interoperability among disparate systems by capturing the semantics of controls, independent of how they may be displayed using various representations (such as word processors). However, we expect that word processors and spreadsheets will continue to be used in workflows supporting OSCAL, supported where necessary by data conversion utilities.
+Microsoft's Office Open XML is the format underlying its Word and Excel applications; it is documented as ISO. Ubiquitous as an application format, these formats are tractable using tools built to the applications' APIs and data models, but they are not designed to support application-independent data exchange. OSCAL enables greater data interoperability among disparate systems by capturing the semantics of controls, independent of how they may be displayed using various representations (such as word processors). However, we expect that word processors and spreadsheets will continue to be used in workflows supporting OSCAL, supported where necessary by data conversion utilities.
 
 ### OpenOffice formats <code>.odt .ods</code> (word processor and spreadsheet formats)
 

docs/content/concepts/terminology/_index.md

@@ -105,7 +105,7 @@ A baseline, or overlay in other terminology, defines a specific set of selected
 
 {{<callout>}}NIST Special Publication (SP) [800-37 Revision 2](https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final) defines a baseline as "the set of controls that are applicable to information or an information system to meet legal, regulatory, or policy requirements, as well as address protection needs for the purpose of managing risk."{{</callout>}}
 
-Using the OSCAL profile model to express a baselines makes the mappings between the control catalog and the profile explicit and machine readable. A single OSCAL profile can reference controls in multiple catalogs. OSCAL permits profiles to use the same interoperable format irrespective of which catalogs are being used.
+Using the OSCAL profile model to express a baseline makes the mappings between the control catalog and the profile explicit and machine-readable. A single OSCAL profile can reference controls in multiple catalogs. OSCAL permits profiles to use the same interoperable format irrespective of which catalogs are being used.
 
 The figure below uses the NIST SP 800-53 low baseline as an example to sketch how a baseline relates to a catalog. The low baseline indicates which controls from the NIST SP 800-53 catalog are required for compliance with this baseline.
 

docs/content/contribute/model-review/_index.md

@@ -33,7 +33,7 @@ Each bi-weekly teleconference will cover some or all of the following topics:
 
 -	Reviewing one or more of the OSCAL models
 -	Answering questions on model usage
--	Discussing property and annotation values
+-	Discussing property values and other controlled vocabularies
 -	Collecting feedback on how to improve the models and related documentation
 
 We specifically want to hear from community members that are authoring OSCAL content and creating OSCAL tools. ***Your [feedback](/contact/) is important to us***, which is the primary reason we are hosting these teleconferences.

docs/content/contribute/model-review/oscal-model-review.ics

@@ -24,7 +24,7 @@ CREATED:20210421T162550Z
 DESCRIPTION:We will be hosting the first of a set of bi-weekly meetings to 
 	review the OSCAL models on Friday\, May 15th\, 2020.\n\n \n\nDuring these 
 	meetings we will be:\n\n*	Reviewing the OSCAL models\n*	Answering question
-	s on model usage\n*	Discussing property and annotation values\n*	Collectin
+	s on model usage\n*	Discussing property values and other controlled vocabularies\n*	Collectin
 	g feedback on how to improve the models and related documentation\n\n \n\n
 	If you are interested in developing OSCAL content or tools\, we would enco
 	urage you to participate.\n\n \n\nMeeting Info:\n\n \n\nhttps://bluejeans.

docs/content/learn/presentations/_index.md

@@ -9,5 +9,5 @@ The following are presentations on OSCAL-related topics. Some of the older prese
 - [Using Leveraged Authorizations in OSCAL](/presentations/oscal-leveraged-authorizations-v6a.pdf) presented during the [OSCAL Model Review](/contribute/model-review/) - July 24, 2020
 - [OSCAL Assessment Models Overview](/presentations/oscal-ap-ar-poam-v3.pdf) presented during the [Lunch with the OSCAL Developers](/contribute/dev-lunch/) - July 2, 2020
 - [NIST OSCAL Workshop](OSCAL-workshop-20191105.pdf) - November 5, 2019
-- [Security Automation Simplified via NIST OSCAL: We're Not in Kansas Anymore](https://www.youtube.com/watch?v=eP8K7piU5UQ) presented at RSAConference 2018 - April 18, 2018
+- [Security Automation Simplified via NIST OSCAL: We're Not in Kansas Anymore](https://www.youtube.com/watch?v=eP8K7piU5UQ) presented at RSA Conference 2018 - April 18, 2018
 - [Automating Security and Compliance via a New Standard of Standards](https://www.youtube.com/watch?v=mo3J0tFxixg) presented at Docker Government Summit 2018 - April 11, 2018

docs/content/learn/tutorials/_index.md

@@ -6,4 +6,5 @@ suppresstopiclist: true
 The following tutorials provide a step-by-step walkthrough on explaining how to create OSCAL content of various types:
 
 - [Creating a Basic Control Catalog](/learn/tutorials/catalog/): A tutorial on creating a [catalog](/concepts/terminology/#catalog) of [controls](/concepts/terminology/#control) using the OSCAL [catalog model](/concepts/layer/control/catalog/).
+- [Representing Test Validation Information](/learn/tutorials/validation-modeling/): A mini-tutorial on providing test validation information (e.g., FIPS 140-2 validation) as an OSCAL component in a [component definition](/concepts/layer/implementation/component-definition/) or [system security plan](/concepts/layer/implementation/ssp/).