Fix bookmarks and Standardization goal wording.

sources/sections/01-scope.adoc

@@ -7,16 +7,16 @@ The OGC Standard for Designing and Writing Modular Standards, also known as the
 - Is designed to enable the clear and concise specification of requirements (the _shalls_ or _musts_ in a standard) that fully supports the ability to define implementable conformance tests. 
 - Formalizes implementing the requirements specified in the ModSpec so that reusable, modular standards can be developed.
 
-The standardization goal of the ModSpec is to define characteristics and a structure for the specification of Standards 
+The standardization goal of the ModSpec is to define characteristics and a structure for the specification of modular and testable Standards 
 that will encourage implementation by minimizing difficulty determining
 requirements, mimicking implementation structure, and maximizing usability and
-interoperability.The goal of this approach is to enable implementations of a standard to be tested and deemed _conformant_ or not.
+interoperability.The ultimate goal of this approach is to enable interoperable implementations of a standard to be tested and deemed _conformant_ or not.
 
 NOTE: For OGC Standards work, the word “standard” in the ModSpec applies to all OGC draft standards, approved standards, draft Abstract Specifications, and approved Abstract Specifications. The exceptions are OGC Abstract Specifications that originate in ISO or Community Standards that are developed external to the OGC and then submitted to the OGC.
 
 Therefore, a standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. 
 
-<<Annex C,Annex-C>> defines the UML model upon which the ModSpec is
+<<Annex C,annex-C>> defines the UML model upon which the ModSpec is
 based. Annex C also contains informal and non-normative definitions ordered for ease
 of understanding. These two sections can be read first to aid in the understanding of
 the rest of the document.
@@ -26,7 +26,7 @@ NOTE: Please note that the ModSpec has been approved by the OGC Membership as a
 [[things-to-know]]
 === Things to know
 
-NOTE: Reading the Terms and Definitions clause and Clause <TBD> will help understanding the content and
+NOTE: Reading the Terms and Definitions clause and Clause <<Terms and Definitions, cls-4>> will help understanding the content and
 requirements stated in this document.
 
 This OGC document, also known as the `ModSpec`:
@@ -41,7 +41,7 @@ NOTE: Please note that the ModSpec has been approved by the OGC Membership as a
 
 A standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. 
 
-There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the https://docs.ogc.org/is/19-072/19-072.html[OGC API - Common Part 1: Core Standard] and in the https://github.com/opengeospatial/cdbswg/blob/master/cdb-2.0/cdb-core-crs-requirements-class.adoc[CDB 2.0 Standard CRS Requirements Module]. By formally implementing the requirements specified in the ModSpec, reusable, modular standards can be developed.
+There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the https://docs.ogc.org/is/19-072/19-072.html[OGC API - Common Part 1: Core Standard] and in the https://github.com/opengeospatial/cdbswg/blob/master/cdb-2.0/cdb-core-crs-requirements-class.adoc[CDB 2.0 Standard CRS Requirements Module]. By formally implementing the requirements specified in the ModSpec, reusable, testable, modular standards can be developed.
 
 NOTE: The approach modelled in the ModSpec has been referred to as the "core and extension model" due to its
 insistence on a modular structure throughout all parts of a standard and its implementation.