Fix some typos.

Author: heidivanparys

sources/24-066-part3-xml/sections/06-req-class.adoc

@@ -194,11 +194,11 @@ assertions about the presence or absence of patterns in XML trees. It is a struc
 language expressed in XML using a small number of elements and XPath languages.
 
 This requirements class covers any standard that
-uses Schematron to create patterns or constrains for an XML Schema. 
+uses Schematron to create patterns or constraints for an XML Schema. 
 
 [cols="1,4",width="90%"]
 |===
-2+|*Requirements Class - XML schmeatron extension to the core* 
+2+|*Requirements Class - XML Schematron extension to the core* 
 2+|/req/core/data-representation 
 |Target | ModSpec Conformant XML Model
 |Dependency |OGC ModSpec Version 1.1 (need proper title and document number)

sources/sections/00-preface.adoc

@@ -21,7 +21,7 @@ OGC ModSpec GitHub repository (https://github.com/opengeospatial/ogc-modspec).
 == Document terms and definitions
 
 This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. 
-In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this ModSPec standard.
+In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this ModSpec standard.
 
 [.preface]
 == Document editors

sources/sections/04-terms-and-defs.adoc

@@ -131,7 +131,7 @@ document containing recommendations, requirements, permissions, and conformance
 
 NOTE:  This definition is included for completeness. 
 
-NOTE:  In the OGC, there are Abstract Specifications and Implementation Standards. Abstract Specifications may of may not be testable. Further, Abstract Specifications may not be directly implementable. Implementation Standards are always testable and contain a conformance test suite. 
+NOTE:  In the OGC, there are Abstract Specifications and Implementation Standards. Abstract Specifications may or may not be testable. Further, Abstract Specifications may not be directly implementable. Implementation Standards are always testable and contain a conformance test suite. 
 
 [[Standard-definition]]
 

sources/sections/06-fundamentals.adoc

@@ -66,7 +66,7 @@ declared once and is uniquely identified as such, each requirement will be in a
 
 Therefore, the ModSpec defines a "requirements class" as a set of requirements that must
 all be passed as per the tests defined in the related conformance class (see
-<<ConformanceClass-definition>>). Each requirements class has a one-to-one correspondence with a conformance class. A standard written to conform with the ModSpec mayuse this "module" structure in any manner consistent with the rest of the ModSpec.
+<<ConformanceClass-definition>>). Each requirements class has a one-to-one correspondence with a conformance class. A standard written to conform with the ModSpec may use this "module" structure in any manner consistent with the rest of the ModSpec.
 
 A standard may have mandatory and optional requirements classes.  This allows the options
 in the testing procedure to be grouped into non-varying mandatory and optional conformance classes.
@@ -98,7 +98,7 @@ consistent with the conformance test classes, see <<req-6,Requirement 6>> and <<
 Standards development should be a repeatable process producing a suite of standards with a common look and feel. In addition, that process should embody the ModSpec principles so that ModSpec conformance is almost automatic. A standardized template is an essential element of such a repeatable process.   
 
 NOTE: OGC Standards are written using an OGC Member approved template that is conformant with the 
-requirements stated in the ModSpec
+requirements stated in the ModSpec.
 
 This template should be specified by the following descriptions:
 

sources/sections/06-req-class.adoc

@@ -348,7 +348,7 @@ The following recommendation is guidance to the group developing a standard to k
 [[rec-4]]
 include::../recommendations/core/REC004-simple-core.adoc[]
 
-The following enables the development and documentation of anstract standards. Examples of such standards are the OGC Abstract Specification.
+The following enables the development and documentation of abstract standards. Examples of such standards are the OGC Abstract Specification.
 Typically, an abstract standard cannot be directly implemented.
 
 include::../permissions/core/PER006_core-type.adoc[]

sources/sections/definitions.adoc

@@ -44,7 +44,7 @@ document containing recommendations, requirements, permissions, and conformance
 
 NOTE:  This definition is included for completeness. 
 
-NOTE:  In the OGC, there are Abstract Specifications and Implementation Standards. Abstract Specifications may of may not be testable. Further, Abstract Specifications may not be directly implementable. Implementation Standards are always testable and contain a conformance test suite. 
+NOTE:  In the OGC, there are Abstract Specifications and Implementation Standards. Abstract Specifications may or may not be testable. Further, Abstract Specifications may not be directly implementable. Implementation Standards are always testable and contain a conformance test suite. 
 
 [[Standard-definition]]