Merge branch 'main' into fix_typos

Author: cmheazel

sources/24-065-part2-uml/document.adoc

@@ -6,8 +6,8 @@
 :docnumber: 24-065
 :edition: 1.1.0
 :received-date: 2025-03-15
-:issued-date: xxxx-xx-xx
-:published-date: xxxx-xx-xx
+:issued-date: 2025-xx-xx
+:published-date: 2025-xx-xx
 :copyright-year: 2025
 :fullname: Carl Reed
 :role: editor

sources/24-065-part2-uml/sections/05-conventions.adoc

@@ -12,13 +12,13 @@ available standard (PAS) by ISO in its earlier 1.3 version.
 
 The normative provisions in this standard are denoted by the URI namespace
 
-https://www.opengis.net/spec/modspec/1.1/
+https://www.opengis.net/spec/modspec-2/1.1/
 
 All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.
 
 For the sake of brevity, the use of “req” in a requirement URI denotes:
 
-https://www.opengis.net/spec/modspec/1.1/
+https://www.opengis.net/spec/modspec-2/1.1/
 
 An example might be:
 
@@ -28,7 +28,7 @@ All conformance tests that appear in this document are denoted by partial URIs w
 
 For the sake of brevity, the use of “conf” in a requirement URI denotes:
 
-https://www.opengis.net/spec/modspec/1.1/
+https://www.opengis.net/spec/modspec-2/1.1/
 
 The same convention is used for permissions (per) and recommendations (rec).
 

sources/24-065-part2-uml/sections/06-req-class.adoc

@@ -1,5 +1,5 @@
 [[cls-6]]
-== Requirements Class: Part 1 UML
+== Requirements Class: Part 2 UML
 
 This clause defines the key concepts and requirements that represent Part 2 of the ModSpec.
 
@@ -135,7 +135,7 @@ and all classes and constraints in those packages.
 If a requirement uses or refers to elements of more than one package, then one of
 the packages will be called the source of the requirement, and the other targets.
 The requirement with the same source package will always be associated with the same
-requirements module and/or class.
+requirements package and/or class.
 
 [[req-07]]
 [requirement,model=ogc,type="general"]

sources/24-066-part3-xml/sections/05-conventions.adoc

@@ -12,11 +12,11 @@ available standard (PAS) by ISO in its earlier 1.3 version.
 
 The normative provisions in this standard are denoted by the URI namespace
 
-https://www.opengis.net/spec/modspec/1.1/
+https://www.opengis.net/spec/modspec-3/1.1/
 
 All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.
 
-For the sake of brevity, the use of “req” in a requirement URI denotes https://www.opengis.net/spec/modspec/1.1/
+For the sake of brevity, the use of “req” in a requirement URI denotes https://www.opengis.net/spec/modspec-3/1.1/
 
 An example might be:
 
@@ -26,7 +26,7 @@ All conformance tests that appear in this document are denoted by partial URIs w
 
 For the sake of brevity, the use of “conf” in a requirement URI denotes:
 
-https://www.opengis.net/spec/modspec/1.1/
+https://www.opengis.net/spec/modspec-3/1.1/
 
 The same convention is used for permissions (per) and recommendations (rec).
 

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

@@ -11,7 +11,7 @@ logical form (template).
 In informative sections, the use of the word "will" implies that something is an implication of a requirement. 
 The "will" statements are not requirements but explain the consequence of requirements.
 
-The ModSpec defines a "requirement" of a standard as an atomic testable
+The ModSpec defines a "requirement" of a standard as an testable
 criterion. See the formal definition of requirement in the ModSpec Core document.
 
 [[cls-6-1]]
@@ -203,8 +203,7 @@ uses Schematron to create patterns or constraints for an XML Schema.
 |Target | ModSpec Conformant XML Model
 |Dependency |OGC ModSpec Version 1.1 (need proper title and document number)
 |REQ007 | /req/part3/xml/schematron-xml-schema 
-|REQ008 | /req/part3/xml/sch-pattern-constraints 
-|REQ009 | /req/part3/xml/pattern-to-element 
+|REQ008 | /req/part3/xml/sch-pattern-constraints  
 |REQ010 | /req/part3/xml/fpi-attribute-is-uri
 |REQ011 | /req/part3/xml/see-attribute-is-identifier
 |REQ012 | /req/part3/xml/one-fpi-attribute-per-schema
@@ -230,18 +229,12 @@ that corresponds with conformance tests and a conformance test class as follows:
 [width="90%",cols="2,6"]
 |===
 |*REQ008* | */req/part3/xml/sch-pattern-constraints* +
-^| A |Each sch:pattern element _SHALL_ implement constraints described in no more than one
+^| A |Each sch:assert element _SHALL_ implement constraints described in no more than one
 requirement. 
 ^| B |Each requirement _SHALL_ be implemented by no more than one sch:pattern.
 |===
 
-[[req-09]]
-[requirement,model=ogc,type="general"]
-[width="90%",cols="2,6"]
-|===
-|*REQ009* | */req/part3/xml/pattern-to-element* +
-Each sch:pattern element _SHALL_ be contained within one sch:schema element.
-|===
+NOTE: Requirement 9 was removed in the ModSpec version 1.1 as this requirement is present in the latest Schematron RelaxNG schema.
 
 The Formal Public Identifier (fpi) attribute names the Schematron schema. In the ModSpec Part 2 extension, this identifier is a URI.
 

sources/abstract_tests/core/ATS13_imported-requirements-class.adoc

@@ -4,7 +4,7 @@
 [%metadata]
 identifier:: /conf/core/imported-requirements-class
 target:: /req/core/imported-requirements-class
-test-purpose:: Validate that if a requirements class is imported from another standard for use within a standard conformant to the ModSpec, and if any imported requirement is “optional,” then that requirement SHALL be factored out as a separate requirements class in the profile of that imported standard used in the conformant standard. +
+test-purpose:: Validate that if a requirements class is imported from another standard and that requirements class is “optional,” then that requirement class _SHALL_ be factored out as a separate requirements class in the profile of that imported standard used in the conformant standard. +
 And that each such used requirements class is a conformance class of the source standard or a combination of conformance classes of the source standard or standards..
 test-method:: Inspect the document to verify the above.
 ====

sources/abstract_tests/core/ATS20_core-requirements-separate.adoc

@@ -4,6 +4,6 @@
 [%metadata]
 identifier:: /conf/core/core-requirements-separate
 target:: /req/core/core-requirements-separate
-test-purpose:: Validate that every standard defines and identifies a core set of requirements as a separate requirements class with a corresponding conformance class.
+test-purpose:: Validate that the standard defines and identifies a core set of requirements as a separate requirements class with a corresponding conformance class.
 test-method:: Inspect the document to verify the above.
 ====

sources/abstract_tests/core/ATS21_general-recommendations-core.adoc

@@ -4,6 +4,6 @@
 [%metadata]
 identifier:: /conf/core/general-recommendations-core
 target:: /req/core/general-recommendations-core
-test-purpose:: Validate that all general recommendations for a standard are in the core.
+test-purpose:: Validate that all general recommendations for the standard are in the core.
 test-method:: Inspect the document to verify the above.
 ====

sources/abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc

@@ -4,6 +4,6 @@
 [%metadata]
 identifier:: /conf/core/req-class-not-core-stt-subtype-of-core
 target:: /req/core/req-class-not-core-stt-subtype-of-core
-test-purpose:: Validate that every requirements class in a standard, with the exception of the core, has a standardization target type which is a subtype of that of the core. And that every requirement class, with the exception of the core, has the core as a direct dependency.
+test-purpose:: Validate that every requirements class in the standard, with the exception of the core, has a standardization target type which is a subtype of that of the core. And that every requirement class, with the exception of the core, has the core as a direct dependency.
 test-method:: Inspect the document to verify the above.
 ====

sources/abstract_tests/core/ATS23_core-and-extensions.adoc

@@ -4,6 +4,6 @@
 [%metadata]
 identifier:: /conf/core/core-and-extensions
 target:: /req/core/core-and-extensions
-test-purpose:: Validate that each standard conformant to the ModSpec consists of a core and some number of requirements classes defined as extensions to that core.
+test-purpose:: Validate that the standard defines and identifies a core set of requirements as a separate requirements class with a corresponding conformance class.
 test-method:: Inspect the document to verify the above.
 ====