Merge pull request #94 from heidivanparys/fix_typos

Typo fix

Author: cmheazel

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

@@ -198,7 +198,7 @@ uses Schematron to create patterns or constraints for an XML Schema.
 
 [cols="1,4",width="90%"]
 |===
-2+|*Requirements Class - XML schematron 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/04-terms-and-defs.adoc

@@ -141,7 +141,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

@@ -69,8 +69,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 may use 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.
@@ -103,7 +102,7 @@ Standards development should be a repeatable process producing a suite of standa
 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

@@ -358,7 +358,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]]