Re-sync with Main

sources/document.adoc

@@ -51,3 +51,4 @@ include::sections/ac-definitions.adoc[]
 
 include::sections/ad-bibliography.adoc[]
 
+include::sections/ae-acknowledgements.adoc[]

sources/models/ogc-modspec.lutaml

@@ -1,7 +1,7 @@
 diagram OGCModSpec {
   title "OGC 08-131r3 ModSpec"
 
-  class Specification {
+  class Standard {
     definition {
       For a draft standard (aka specification) to become an international standard, the document must be approved by an authority, 
       such as ISO or the OGC. The attributes of a standard describe its local name, its authority, the date of publication 
@@ -36,9 +36,9 @@ diagram OGCModSpec {
 
   class ConformanceSuite {
     definition {
-      The unique conformance suite of a standard lists the tests (grouped
-      into conformance test classes consisting of some number of conformance
-      test modules, containing some number of conformance tests) that allow
+      The unique conformance suite of a standard lists the tests (possibly grouped
+      into conformance test modules consisting of some number of conformance
+      test classes, each containing some number of conformance tests) that allow
       testing of an implementation of the standard for conformance with the
       requirements stated in the standard. Every standard needs one of these suites, or
       conformance cannot be claimed with proof. In ISO and the OGC, the conformance
@@ -64,7 +64,7 @@ diagram OGCModSpec {
     definition {
       The requirements in the requirements classes of a standard must be
       tested and the conformance classes are the containers for these tests’
-      definition. The requirements classes will have interdependencies, and this
+      definition. The requirements classes may have interdependencies, and this
       is reflected in the explicit dependencies between the conformance classes.
       If class "a" is dependent on class "b", then to pass the test for "a" a
       standardization target must also pass the test for "b." The class name is
@@ -112,7 +112,7 @@ diagram OGCModSpec {
     }
     modules: RequirementsModule[1..*] {
       definition {
-        Requirements modules that make up this requirements class.
+        A set of one or more requirement(s) classes, recommendations, and permissions with the same standardization target.
       }
     }
     targetType: StandardizationTargetType {
@@ -124,7 +124,7 @@ diagram OGCModSpec {
 
   class RequirementsModule {
     definition {
-      A requirements modules (usually realized as groups of one or more
+      A requirements module (usually realized as groups of one or more
       requirements classes in the standard) group the
       requirements and recommendations in the standard in a manner consistent with the
       conformance test modules.
@@ -138,7 +138,7 @@ diagram OGCModSpec {
 
     requirements: Requirement[1..*] {
       definition {
-        Requirements classes that this requirements module contains.
+        Requirements classes, recommendations, and permissions that this requirements module contains.
       }
     }
   }

sources/ogc-modspec-policy/00-forward.adoc

@@ -0,0 +1,13 @@
+[.preface]
+== Foreword
+
+This OGC ModSpec Policy specifies requirements and guidance for using the ModSpec as the formal structure for all OGC standards documents.
+
+_Attention is drawn to the possibility that some of the elements of this document may
+be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be
+held responsible for identifying any or all such patent rights._
+
+_Recipients of this document are requested to submit, with their comments,
+notification of any relevant patent claims or other intellectual property rights of
+which they may be aware that might be infringed by any implementation of the standard
+set forth in this document, and to provide supporting documentation._

sources/ogc-modspec-policy/00-preface.adoc

@@ -0,0 +1,42 @@
+[.preface]
+== Preface
+
+This OGC member Policy mandates the use if the ModSpec a model and related requirements and recommendations for writing and structuring modular OGC standards Further, this Policy mandates that every OGC Implementation Standard will provide an ABstract Test Suite (confomrance suite)  designed to enable the consistent and verifiable testing of implementations of an OGC Standard that claim conformance.
+
+The goal of this Policy is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
+
+Suggested additions, changes, and comments on this this document are welcome and
+encouraged. Such suggestions may be submitted through the OGC Change Request System
+(http://www.opengeospatial.org/standards/cr) or by creating an issue in the GitHub repository for this document (https://github.com/opengeospatial/ogc-modspec).
+
+[.preface]
+== Document terms and definitions
+
+This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008], 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
+imperative verb form used to indicate a requirement to be strictly followed to
+conform to this standard.
+
+[.preface]
+== Document editors
+
+The following OGC Members participated in editing this document:
+
+[%unnumbered]
+|===
+^h| Person ^h| Organization Represented
+| Carl Reed | Carl Reed & Associates
+|===
+
+[.preface]
+== Document Contributors
+
+The following OGC Members contributed and particpated in developing Version 2 of the ModSpec.
+
+[%unnumbered]
+|===
+^h| Person ^h| Organization Represented
+| Chuck Heazel | Heazeltech
+| Jeff Yutzler | ImageMatters
+|===

sources/ogc-modspec-policy/01-scope.adoc

@@ -0,0 +1,17 @@
+== Scope
+This OGC Policy Document defines the OGC Policy and Guidance related to the use of the ModSpec.
+
+The ModSpec defines characteristics and structure for the specification of Standards 
+that will encourage implementation by minimizing difficulty determining
+requirements, mimicking implementation structure and maximizing usability and
+interoperability. 
+
+Part 1 of the ModSpec defines the requirements for using UML. 
+The use case is if the organizing mechanism for the data model 
+used in a standard is an object model, then the mapping from parts of the model to 
+the requirements classes should follow the logical mechanism described in Part 1 of the ModSpec.
+
+Part 2 of the ModSpec defines the requirements for using XML. The XML related requirements classes 
+cover any standard which has as one of its purposes the introduction of a new XML schema. 
+Such a standard would normally define the schema, all of its components, and its intended uses.
+

sources/ogc-modspec-policy/02-conformance.adoc

@@ -0,0 +1,6 @@
+[[cls-2]]
+== Conformance
+
+Conformance to the ModSpec by technical implementation standards 
+can be tested by inspection. The ModSpec test suite is specified in annex-A of the ModSpec.
+

sources/ogc-modspec-policy/06-policy.adoc

@@ -0,0 +1,22 @@
+[[modspec-policy]]
+== ModSpec Policy Requirements
+
+The following requirement states that in OGC Standards development, the ModSpec model will be used.
+
+[[req-01]]
+[requirement,model=ogc,type="general"]
+[width="90%",cols="2,6"]
+|===
+|*REQ001* | */req/policy/conformance-with-modspec* +
+Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard _SHALL_ comply with the requirements stated in the OGC ModSpec.
+|===
+
+Any OGC Standards document will specify the standardization goal.
+
+[[req-02]]
+[requirement,model=ogc,type="general"]
+[width="90%",cols="2,6"]
+|===
+|*REQ002* | */req/policy/standardization-goal* +
+Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard _SHALL_ clearly state the stanrdization goal for the standard or abstract specification. This statement _SHOULD_ be in the `Abstract` or `Scope` clauses of the standard.
+|===

sources/ogc-modspec-policy/document.adoc

@@ -0,0 +1,29 @@
+= The ModSpec Model OGC Policy
+:doctype: draft policy
+:docsubtype: logical-model
+:status: Draft
+:committee: technical
+:docnumber: 24-xxx
+:edition: 1.1.0
+:received-date: 2025-01-01
+:issued-date: xxxx-xx-xx
+:published-date: xxxx-xx-xx
+:copyright-year: 2024
+:fullname: Carl Reed
+:role: editor
+:submitting-organizations: Carl Reed
+:imagesdir: images
+:mn-document-class: ogc
+:mn-output-extensions: xml,html,doc,pdf,rxl
+:local-cache-only:
+:data-uri-image:
+
+include::00-preface.adoc[]
+
+include::00-foreword.adoc[]
+
+include::01-scope.adoc[]
+
+include::02-conformance.adoc[]
+
+include::06-policy.adoc[]

sources/part2/00-preface.adoc

@@ -31,7 +31,7 @@ The following OGC Members participated in editing this document:
 |===
 ^h| Person ^h| Organization Represented
 | Carl Reed | Carl Reed & Associates
-| Chuck Heazel | Heazeltech
+| John Herring | Oracle
 |===
 
 [.preface]
@@ -48,26 +48,6 @@ The following OGC Members contributed and particpated in developing Version 2 of
 | Jeff Yutzler | ImageMatters
 |===
 
-[.preface]
-== Acknowledgements
-
-The following OGC Members were key contributors to Version 1 of the ModSpec
-
-[%unnumbered]
-|===
-^h| Person ^h| Organization Represented
-| Simon Cox | CSIRO
-| David Danko | ESRI
-| James Greenwood | SeiCorp, Inc.
-| John R. Herring | Oracle USA
-| Andreas Matheus | University of the Bundeswehr -- ITS
-| Richard Pearsall | US National Geospatial-Intelligence Agency (NGA)
-| Clemens Portele | interactive instruments GmbH
-| Barry Reff | US Department of Homeland Security (DHS)
-| Paul Scarponcini | Bentley Systems, Inc.
-| Arliss Whiteside | BAE Systems - C3I Systems
-|===
-
 [.preface]
 == Revision history
 

sources/relaton/cache/iso/iso_19105_2022.xml

@@ -0,0 +1,54 @@
+<bibdata type="standard" schema-version="v1.2.8">
+  <fetched>2024-12-17</fetched>
+  <title type="title-intro" format="text/plain" language="en" script="Latn">Geographic information</title>
+  <title type="title-main" format="text/plain" language="en" script="Latn">Conformance and testing</title>
+  <title type="main" format="text/plain" language="en" script="Latn">Geographic information - Conformance and testing</title>
+  <title type="title-intro" format="text/plain" language="fr" script="Latn">Information géographique</title>
+  <title type="title-main" format="text/plain" language="fr" script="Latn">Conformité et essais</title>
+  <title type="main" format="text/plain" language="fr" script="Latn">Information géographique - Conformité et essais</title>
+  <uri type="src">https://www.iso.org/standard/76457.html</uri>
+  <uri type="obp">https://www.iso.org/obp/ui/en/#!iso:std:76457:en</uri>
+  <uri type="rss">https://www.iso.org/contents/data/standard/07/64/76457.detail.rss</uri>
+  <docidentifier type="ISO" primary="true">ISO 19105:2022</docidentifier>
+  <docidentifier type="iso-reference">ISO 19105:2022(E)</docidentifier>
+  <docidentifier type="URN">urn:iso:std:iso:19105:stage-60.60</docidentifier>
+  <docnumber>19105</docnumber>
+  <date type="published">
+    <on>2022-07</on>
+  </date>
+  <contributor>
+    <role type="publisher"/>
+    <organization>
+      <name>International Organization for Standardization</name>
+      <abbreviation>ISO</abbreviation>
+      <uri>www.iso.org</uri>
+    </organization>
+  </contributor>
+  <edition>2</edition>
+  <language>en</language>
+  <language>fr</language>
+  <script>Latn</script>
+  <abstract format="text/plain" language="en" script="Latn">This document specifies the framework, concepts and methodology for conformance testing and criteria to be achieved to claim conformance to the family of applicable standardization documents regarding geographic information and relevant application domains. This document provides a framework for specifying abstract test suites composed of abstract test cases grouped in conformance classes and for defining the procedures to be followed during conformance testing.
+Conformance can be claimed for data or software products or services or by specifications including any profile or functional standard. The structure of, and relationships between, conformance classes as defined in this document underly a systematic approach to configuration management involving managing dependencies within and between modules.</abstract>
+  <abstract format="text/plain" language="fr" script="Latn">Le présent document spécifie le cadre, les concepts et la méthodologie applicables aux tests et critères de conformité à respecter pour revendiquer la conformité avec la famille de document de normalisation sur l'information géographique et les domaines d'application concernés. Le présent document propose un cadre pour la spécification des suites de tests abstraits composées de cas de test abstraits regroupés en classes de conformité, et pour la définition des procédures à suivre lors des tests de conformité.
+Il est possible de revendiquer la conformité pour les données ou les produits et services logiciels, ou par les spécifications, y compris de n'importe quel profil ou norme opératoire. La structure des classes de conformité définies dans le présent document, et les relations entre celles-ci, sous-tendent une approche systématique de la gestion de configuration qui implique la gestion des dépendances au sein des modules et entre ceux-ci.</abstract>
+  <status>
+    <stage>60</stage>
+    <substage>60</substage>
+  </status>
+  <copyright>
+    <from>2022</from>
+    <owner>
+      <organization>
+        <name>ISO</name>
+      </organization>
+    </owner>
+  </copyright>
+  <relation type="obsoletes">
+    <bibitem type="standard">
+      <formattedref format="text/plain">ISO 19105:2000</formattedref>
+      <docidentifier type="ISO" primary="true">ISO 19105:2000</docidentifier>
+    </bibitem>
+  </relation>
+  <place>Geneva</place>
+</bibdata>

sources/relaton/cache/omg/omg_uml_2.4.1_superstructure.notfound

@@ -0,0 +1 @@
+not_found 2024-12-17

sources/relaton/cache/omg/omg_uml_2.5_infrastructure.notfound

@@ -0,0 +1 @@
+not_found 2024-12-17

sources/sections/00-foreword.adoc

@@ -1,8 +1,7 @@
 [.preface]
 == Foreword
 
-The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a formal structure for standards documents but does not supply
-specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <<cls-6>>
+The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a formal structure and requirements for writing modular standards documents. However, the ModSpec does not supply specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <<cls-6>>
 and the Conformance Test Suite <<annex-A-1>>).
 
 _Attention is drawn to the possibility that some of the elements of this document may

sources/sections/00-preface.adoc

@@ -1,17 +1,15 @@
 [.preface]
 == Preface
 
-This OGC member developed and approved document defines a model and related requirements and recommendations for writing and structuring modular standards documents. Further, this model is designed to enable the consistent and verifiable testing of implementations of a standard that claim conformance.
+This OGC member developed and approved document, referred to as the `ModSpec`, defines a model and related requirements and recommendations for writing and structuring modular standards documents. Further, this model is designed to enable the consistent and verifiable testing of implementations of a standard that claim conformance.
 
 The goal is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
 
-NOTE: For OGC only: Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard shall comply with the requirements stated in this document.
-
 NOTE: Historically, this document has been known and abbreviated as the "ModSpec". For continuity and ease of understanding this document may also be refered to as the "OGC ModSpec".
 
 Suggested additions, changes, and comments on this this document are welcome and
 encouraged. Such suggestions may be submitted through the OGC Change Request System
-(http://www.opengeospatial.org/standards/cr) or by creating an issue in the GitHub repository for this document (https://github.com/opengeospatial/ogc-modspec).
+(http://ogc.standardstracker.org/) or by creating an issue in the OGC ModSpec GitHub repository (https://github.com/opengeospatial/ogc-modspec).
 
 [.preface]
 == Document terms and definitions
@@ -20,7 +18,7 @@ This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008],
 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
 imperative verb form used to indicate a requirement to be strictly followed to
-conform to this standard.
+conform to the ModSpec.
 
 [.preface]
 == Document editors
@@ -31,7 +29,7 @@ The following OGC Members participated in editing this document:
 |===
 ^h| Person ^h| Organization Represented
 | Carl Reed | Carl Reed & Associates
-| Chuck Heazel | Heazeltech
+| Chuck Heazel | Charles Heazel
 |===
 
 [.preface]
@@ -43,31 +41,11 @@ The following OGC Members contributed and particpated in developing Version 2 of
 |===
 ^h| Person ^h| Organization Represented
 | Simon Cox | CSIRO and OGC Fellow
-| Chuck Heazel | Heazeltech
+| Chuck Heazel | Charles Heazel
 | Clemens Portele | interactive instruments GmbH
 | Jeff Yutzler | ImageMatters
 |===
 
-[.preface]
-== Acknowledgements
-
-The following OGC Members were key contributors to Version 1 of the ModSpec
-
-[%unnumbered]
-|===
-^h| Person ^h| Organization Represented
-| Simon Cox | CSIRO
-| David Danko | ESRI
-| James Greenwood | SeiCorp, Inc.
-| John R. Herring | Oracle USA
-| Andreas Matheus | University of the Bundeswehr -- ITS
-| Richard Pearsall | US National Geospatial-Intelligence Agency (NGA)
-| Clemens Portele | interactive instruments GmbH
-| Barry Reff | US Department of Homeland Security (DHS)
-| Paul Scarponcini | Bentley Systems, Inc.
-| Arliss Whiteside | BAE Systems - C3I Systems
-|===
-
 [.preface]
 == Revision history