diff --git a/.gitignore b/.gitignore index eb2c7d1..fba984f 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,4 @@ .DS_Store -relaton/cache -iev/cache +*/relaton +*/iev *.err diff --git a/sources/abstract_tests/core/ATS10_all-parameters-expressed.adoc b/sources/abstract_tests/core/ATS10_all-parameters-expressed.adoc index 168940c..ef30658 100644 --- a/sources/abstract_tests/core/ATS10_all-parameters-expressed.adoc +++ b/sources/abstract_tests/core/ATS10_all-parameters-expressed.adoc @@ -1,7 +1,9 @@ [[ats_all-parameters-expressed]] [abstract_test] +.Certificate of conformance specifies all parameters used ==== [%metadata] +name:: Certificate of conformance specifies all parameters used identifier:: /conf/core/all-parameters-expressed target:: /req/core/all-parameters-expressed test-purpose:: Validate that a certificate of conformance specifies all parameter values used to pass the tests in its conformance test class. diff --git a/sources/abstract_tests/core/ATS11_conf-class-single-req-class.adoc b/sources/abstract_tests/core/ATS11_conf-class-single-req-class.adoc index 3ad550f..f9fc1b3 100644 --- a/sources/abstract_tests/core/ATS11_conf-class-single-req-class.adoc +++ b/sources/abstract_tests/core/ATS11_conf-class-single-req-class.adoc @@ -1,7 +1,9 @@ [[ats_conf-class-single-req-class]] [abstract_test] +.Conformance class tests only one requirements class ==== [%metadata] +name:: Conformance class tests only one requirements class identifier:: /conf/core/conf-class-single-req-class target:: /req/core/conf-class-single-req-class test-purpose:: Validate that every conformance class explicitly tests only requirements from a single requirements class. diff --git a/sources/abstract_tests/core/ATS12_con-class-dependencies.adoc b/sources/abstract_tests/core/ATS12_con-class-dependencies.adoc index 2b131a3..336da8c 100644 --- a/sources/abstract_tests/core/ATS12_con-class-dependencies.adoc +++ b/sources/abstract_tests/core/ATS12_con-class-dependencies.adoc @@ -1,7 +1,9 @@ [[ats_con-class-dependencies]] [abstract_test] +.Conformance class specifies all dependencies ==== [%metadata] +name:: Conformance class specifies all dependencies identifier:: /conf/core/con-class-dependencies target:: /req/core/con-class-dependencies test-purpose:: Validate that all conformance classes specify any other conformance class upon which they are dependent and that other conformance class shall be used to test the specified dependency. diff --git a/sources/abstract_tests/core/ATS13_imported-requirements-class.adoc b/sources/abstract_tests/core/ATS13_imported-requirements-class.adoc index 785c19c..f868b90 100644 --- a/sources/abstract_tests/core/ATS13_imported-requirements-class.adoc +++ b/sources/abstract_tests/core/ATS13_imported-requirements-class.adoc @@ -1,7 +1,9 @@ [[ats_imported-requirements-class]] [abstract_test] +.Imported Conformance class tests are consistent with the specification ==== [%metadata] +name:: Imported Conformance class tests are consistent with the specification 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 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. + diff --git a/sources/abstract_tests/core/ATS14_all-classes-explicitly-named.adoc b/sources/abstract_tests/core/ATS14_all-classes-explicitly-named.adoc index 20b4000..961949c 100644 --- a/sources/abstract_tests/core/ATS14_all-classes-explicitly-named.adoc +++ b/sources/abstract_tests/core/ATS14_all-classes-explicitly-named.adoc @@ -1,7 +1,9 @@ [[ats_all-classes-explicitly-named]] [abstract_test] +.Naming consistency ==== [%metadata] +name:: Naming consistency identifier:: /conf/core/all-classes-explicitly-named target:: /req/core/all-classes-explicitly-named test-purpose:: Validate that all requirements classes and all conformance test classes are explicitly named, with corresponding requirements classes and conformance test classes having similar names. diff --git a/sources/abstract_tests/core/ATS15_req-in-only-one-req-class.adoc b/sources/abstract_tests/core/ATS15_req-in-only-one-req-class.adoc index 1497a78..60b7924 100644 --- a/sources/abstract_tests/core/ATS15_req-in-only-one-req-class.adoc +++ b/sources/abstract_tests/core/ATS15_req-in-only-one-req-class.adoc @@ -1,7 +1,9 @@ [[ats_req-in-only-one-req-class]] [abstract_test] +.Requirements in one and only one requirements class ==== [%metadata] +name:: Requirements in one and only one requirements class identifier:: /conf/core/req-in-only-one-req-class target:: /req/core/req-in-only-one-req-class test-purpose:: Validate that each requirement in the standard is contained in one and only one requirements class. And that Inclusion of any requirement in a requirements class by a conformance class implies inclusion of all requirements in its class (as a dependency). diff --git a/sources/abstract_tests/core/ATS16_co-dependent-requirements.adoc b/sources/abstract_tests/core/ATS16_co-dependent-requirements.adoc index 043576a..6c45ce4 100644 --- a/sources/abstract_tests/core/ATS16_co-dependent-requirements.adoc +++ b/sources/abstract_tests/core/ATS16_co-dependent-requirements.adoc @@ -1,7 +1,9 @@ [[ats_co-dependent-requirements]] [abstract_test] +.Co-dependent Requirements are in the same requirements class ==== [%metadata] +name:: Co-dependent Requirements are in the same requirements class identifier:: /conf/core/co-dependent-requirements target:: /req/core/co-dependent-requirements test-purpose:: Validate that if any two requirements are co-dependent (each dependent on the other) then they are in the same requirements class. And if any two requirements classes are co-dependent, they have been merged into a single class. diff --git a/sources/abstract_tests/core/ATS17_structure-requirements-classes.adoc b/sources/abstract_tests/core/ATS17_structure-requirements-classes.adoc index 622153d..a400b0b 100644 --- a/sources/abstract_tests/core/ATS17_structure-requirements-classes.adoc +++ b/sources/abstract_tests/core/ATS17_structure-requirements-classes.adoc @@ -1,7 +1,9 @@ [[ats_structure-requirements-classes]] [abstract_test] +.Modularity in implementation is possible ==== [%metadata] +name:: Modularity in implementation is possible identifier:: /conf/core/structure-requirements-classes target:: /req/core/structure-requirements-classes test-purpose:: Validate that there is a natural structure to the requirements classes so that each may be implemented on top of any implementations of its dependencies and independent of its extensions. diff --git a/sources/abstract_tests/core/ATS18_requirements-and-dependencies.adoc b/sources/abstract_tests/core/ATS18_requirements-and-dependencies.adoc index ed977cf..fa2ba8c 100644 --- a/sources/abstract_tests/core/ATS18_requirements-and-dependencies.adoc +++ b/sources/abstract_tests/core/ATS18_requirements-and-dependencies.adoc @@ -1,7 +1,9 @@ [[ats_requirements-and-dependencies]] [abstract_test] +.Requirements follow rules of inheritance ==== [%metadata] +name:: Requirements follow rules of inheritance identifier:: /conf/core/requirements-and-dependencies target:: /req/core/requirements-and-dependencies test-purpose:: Validate that no requirements class redefines the requirements of its dependencies, unless that redefinition is for an entity derived from but not contained in those dependencies. diff --git a/sources/abstract_tests/core/ATS19_profile-conformance.adoc b/sources/abstract_tests/core/ATS19_profile-conformance.adoc index 2a3c02c..88703c6 100644 --- a/sources/abstract_tests/core/ATS19_profile-conformance.adoc +++ b/sources/abstract_tests/core/ATS19_profile-conformance.adoc @@ -1,7 +1,9 @@ [[ats_profile-conformance]] [abstract_test] +.Profiles are expressed as sets of conformance classes ==== [%metadata] +name:: Profiles are expressed as sets of conformance classes identifier:: /conf/core/profile-conformance target:: /req/core/profile-conformance test-purpose:: Validate that the conformance tests for a profile of a standard are defined as the union of a list of conformance classes that are to be satisfied by that profile’s standardization targets. diff --git a/sources/abstract_tests/core/ATS1_testable.adoc b/sources/abstract_tests/core/ATS1_testable.adoc index 76bdf7a..d57ee34 100644 --- a/sources/abstract_tests/core/ATS1_testable.adoc +++ b/sources/abstract_tests/core/ATS1_testable.adoc @@ -1,7 +1,9 @@ [[ats_requirements-are-testable]] [abstract_test] +.Requirements are testable ==== [%metadata] +name:: Requirements are testable identifier:: /conf/core/reqs-are-testable target:: /req/core/reqs-are-testable test-purpose:: Validate that all the parts of a requirement are testable and that Failure to pass any part of a requirement is also a failure to pass the associated conformance test. diff --git a/sources/abstract_tests/core/ATS20_core-requirements-separate.adoc b/sources/abstract_tests/core/ATS20_core-requirements-separate.adoc index e8ecacb..f340e25 100644 --- a/sources/abstract_tests/core/ATS20_core-requirements-separate.adoc +++ b/sources/abstract_tests/core/ATS20_core-requirements-separate.adoc @@ -1,7 +1,9 @@ [[ats_core-requirements-separate]] [abstract_test] +.There is a named Core requirements class ==== [%metadata] +name:: There is a named Core requirements class identifier:: /conf/core/core-requirements-separate target:: /req/core/core-requirements-separate test-purpose:: Validate that the standard defines and identifies a core set of requirements as a separate requirements class with a corresponding conformance class. diff --git a/sources/abstract_tests/core/ATS21_general-recommendations-core.adoc b/sources/abstract_tests/core/ATS21_general-recommendations-core.adoc index d288788..308e406 100644 --- a/sources/abstract_tests/core/ATS21_general-recommendations-core.adoc +++ b/sources/abstract_tests/core/ATS21_general-recommendations-core.adoc @@ -1,7 +1,9 @@ [[ats_general-recommendations-core]] [abstract_test] +.General conditions are in the core ==== [%metadata] +name:: General conditions are in the core identifier:: /conf/core/general-recommendations-core target:: /req/core/general-recommendations-core test-purpose:: Validate that all general recommendations for the standard are in the core. diff --git a/sources/abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc b/sources/abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc index 51622f2..ec26cdf 100644 --- a/sources/abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc +++ b/sources/abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc @@ -1,7 +1,9 @@ [[ats_req-class-not-core-stt-subtype-of-core]] [abstract_test] +.Every extension has a consistent target type ==== [%metadata] +name:: Every extension has a consistent target type 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 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. diff --git a/sources/abstract_tests/core/ATS23_core-and-extensions.adoc b/sources/abstract_tests/core/ATS23_core-and-extensions.adoc index 00ddaf6..60e106b 100644 --- a/sources/abstract_tests/core/ATS23_core-and-extensions.adoc +++ b/sources/abstract_tests/core/ATS23_core-and-extensions.adoc @@ -1,7 +1,9 @@ [[ats_core-and-extensions]] [abstract_test] +.A standard is a core plus some number of extensions ==== [%metadata] +name:: A standard is a core plus some number of extensions identifier:: /conf/core/core-and-extensions target:: /req/core/core-and-extensions test-purpose:: Validate that the standard defines and identifies a core set of requirements as a separate requirements class with a corresponding conformance class. diff --git a/sources/abstract_tests/core/ATS24_extensions-conformant-to-modspec.adoc b/sources/abstract_tests/core/ATS24_extensions-conformant-to-modspec.adoc index 1a64f02..43d1f40 100644 --- a/sources/abstract_tests/core/ATS24_extensions-conformant-to-modspec.adoc +++ b/sources/abstract_tests/core/ATS24_extensions-conformant-to-modspec.adoc @@ -1,7 +1,9 @@ [[ats_extensions-conformant-to-the-modspec]] [abstract_test] +.Conformance to this ModSpec is required for any extensions ==== [%metadata] +name:: Conformance to this ModSpec is required for any extensions identifier:: /conf/core/extensions-conformant-to-the-modspec target:: /req/core/extensions-conformant-to-the-modspec test-purpose:: Validate that the standard requires all conformant extensions to be conformant to the ModSpec. diff --git a/sources/abstract_tests/core/ATS25_restriction-of-extensions.adoc b/sources/abstract_tests/core/ATS25_restriction-of-extensions.adoc index 5140f8e..7876155 100644 --- a/sources/abstract_tests/core/ATS25_restriction-of-extensions.adoc +++ b/sources/abstract_tests/core/ATS25_restriction-of-extensions.adoc @@ -1,7 +1,9 @@ [[ats_restriction-of-extensions]] [abstract_test] +.Future extensions cannot be restricted ==== [%metadata] +name:: Future extensions cannot be restricted identifier:: /conf/core/restriction-of-extensions target:: /req/core/restriction-of-extensions test-purpose:: Validate that the standard never restricts in any manner future, logically valid extensions of its standardization target types. diff --git a/sources/abstract_tests/core/ATS26_optional-requirements.adoc b/sources/abstract_tests/core/ATS26_optional-requirements.adoc index 92e9e1f..254a896 100644 --- a/sources/abstract_tests/core/ATS26_optional-requirements.adoc +++ b/sources/abstract_tests/core/ATS26_optional-requirements.adoc @@ -1,7 +1,9 @@ [[ats_optional-requirements]] [abstract_test] +.Optional requirements are organized as requirements classes ==== [%metadata] +name:: Optional requirements are organized as requirements classes identifier:: /conf/core/optional-requirements target:: /req/core/optional-requirements test-purpose:: Validate that the only conditional (optional) requirements acceptable in the standard are expressed as a list of conformance classes to be passed. diff --git a/sources/abstract_tests/core/ATS27_req-class-overlap-by-reference.adoc b/sources/abstract_tests/core/ATS27_req-class-overlap-by-reference.adoc index 84bb775..bc95d64 100644 --- a/sources/abstract_tests/core/ATS27_req-class-overlap-by-reference.adoc +++ b/sources/abstract_tests/core/ATS27_req-class-overlap-by-reference.adoc @@ -1,7 +1,9 @@ [[ats_req-class-overlap-by-reference]] [abstract_test] +.Requirements classes intersect overlap only by reference ==== [%metadata] +name:: Requirements classes intersect overlap only by reference identifier:: /conf/core/req-class-overlap-by-reference target:: /req/core/req-class-overlap-by-reference test-purpose:: Validate that the common portion of any two requirements classes consist only of references to other requirements classes. diff --git a/sources/abstract_tests/core/ATS28_reqs-are-in-class.adoc b/sources/abstract_tests/core/ATS28_reqs-are-in-class.adoc index 37f5c5e..4f7c3f8 100644 --- a/sources/abstract_tests/core/ATS28_reqs-are-in-class.adoc +++ b/sources/abstract_tests/core/ATS28_reqs-are-in-class.adoc @@ -1,7 +1,9 @@ [[ats_requirements-are-in-class]] [abstract_test] +.Requirements are in class ==== [%metadata] +name:: Requirements are in class identifier:: /conf/core/reqs-are-in-class target:: /req/core/reqs-are-in-class test-purpose:: Validate that each requirement in the standard is associated with exactly one requirements class. diff --git a/sources/abstract_tests/core/ATS2_assigned-uri.adoc b/sources/abstract_tests/core/ATS2_assigned-uri.adoc index 60719ec..5fe0473 100644 --- a/sources/abstract_tests/core/ATS2_assigned-uri.adoc +++ b/sources/abstract_tests/core/ATS2_assigned-uri.adoc @@ -1,10 +1,12 @@ [[ats_all-components-assigned-uri]] [abstract_test] +.All components have an assigned URI ==== [%metadata] +name:: All components have an assigned URI identifier:: /conf/core/all-components-assigned-uri target:: /req/core/all-components-assigned-uri -test-purpose:: Validate that each component of the standard, including requirements, requirements modules, requirements classes, +test-purpose:: Validate that each component of the standard, including requirements, requirements modules, requirements classes, conformance test, conformance modules, and conformance test classes are assigned a unique identifer or label. test-method:: Inspect the document to verify the above. ==== \ No newline at end of file diff --git a/sources/abstract_tests/core/ATS3_vocabulary.adoc b/sources/abstract_tests/core/ATS3_vocabulary.adoc index 564602f..6b3c237 100644 --- a/sources/abstract_tests/core/ATS3_vocabulary.adoc +++ b/sources/abstract_tests/core/ATS3_vocabulary.adoc @@ -1,7 +1,9 @@ [[ats_vocabulary-and-parent-req-class]] [abstract_test] +.Requirements on vocabulary are appropriately placed ==== [%metadata] +name:: Requirements on vocabulary are appropriately placed identifier:: /conf/core/vocabulary-and-parent-req-class target:: /req/core/vocabulary-and-parent-req-class test-purpose:: Validate that requirements on the use and interpretation of vocabulary are in the requirements class where that use or interpretation is used. diff --git a/sources/abstract_tests/core/ATS4_single-standardization-target-type.adoc b/sources/abstract_tests/core/ATS4_single-standardization-target-type.adoc index 862b341..b8e6946 100644 --- a/sources/abstract_tests/core/ATS4_single-standardization-target-type.adoc +++ b/sources/abstract_tests/core/ATS4_single-standardization-target-type.adoc @@ -1,7 +1,9 @@ [[ats_single-standardization-target-type]] [abstract_test] +.Requirements have a single target type ==== [%metadata] +name:: Requirements have a single target type identifier:: /conf/core/single-standardization-target-type target:: /req/core/single-standardization-target-type test-purpose:: Validate that each requirement class has a single standardization target type. diff --git a/sources/abstract_tests/core/ATS5_test-class-single-standardization-target.adoc b/sources/abstract_tests/core/ATS5_test-class-single-standardization-target.adoc index 3d9f551..e9d7020 100644 --- a/sources/abstract_tests/core/ATS5_test-class-single-standardization-target.adoc +++ b/sources/abstract_tests/core/ATS5_test-class-single-standardization-target.adoc @@ -1,7 +1,9 @@ [[ats_test-class-single-standardization-target]] [abstract_test] +.Conformance test classes have a single target type ==== [%metadata] +name:: Conformance test classes have a single target type identifier:: /conf/core/test-class-single-standardization-target-type target:: /req/core/test-class-single-standardization-target-type test-purpose:: Validate that all conformance tests in a single conformance test class have the same standardization target type. diff --git a/sources/abstract_tests/core/ATS6_requirements-grouped.adoc b/sources/abstract_tests/core/ATS6_requirements-grouped.adoc index faca250..e84fa06 100644 --- a/sources/abstract_tests/core/ATS6_requirements-grouped.adoc +++ b/sources/abstract_tests/core/ATS6_requirements-grouped.adoc @@ -1,7 +1,9 @@ [[ats_requirements-grouped]] [abstract_test] +.Requirements are organized by clauses ==== [%metadata] +name:: Requirements are organized by clauses identifier:: /conf/core/requirements-grouped target:: /req/core/requirements-grouped test-purpose:: Validate that requirements are grouped together in clauses (numbered sections) of the document in a strictly hierarchical manner, consistent with requirements classes. diff --git a/sources/abstract_tests/core/ATS7_requirements-test-suite-structure.adoc b/sources/abstract_tests/core/ATS7_requirements-test-suite-structure.adoc index aa3a361..55ed2ef 100644 --- a/sources/abstract_tests/core/ATS7_requirements-test-suite-structure.adoc +++ b/sources/abstract_tests/core/ATS7_requirements-test-suite-structure.adoc @@ -1,7 +1,9 @@ [[ats_requirements-test-suite-structure]] [abstract_test] +.Conformance test classes are consistent with requirements classes ==== [%metadata] +name:: Conformance test classes are consistent with requirements classes identifier:: /conf/core/requirements-test-suite-structure target:: /req/core/requirements-test-suite-structure test-purpose:: Validate that the requirements structure of the standard are in a logical correspondence with the test suite structure. diff --git a/sources/abstract_tests/core/ATS8_requirements-correspondence.adoc b/sources/abstract_tests/core/ATS8_requirements-correspondence.adoc index a1c9a1b..2666aaf 100644 --- a/sources/abstract_tests/core/ATS8_requirements-correspondence.adoc +++ b/sources/abstract_tests/core/ATS8_requirements-correspondence.adoc @@ -1,7 +1,9 @@ [[ats_requirements-class-correspondence-to-conformance-classes]] [abstract_test] +.Requirement classes and the Conformance Test classes in correspondence ==== [%metadata] +name:: Requirement classes and the Conformance Test classes in correspondence identifier:: /conf/core/requirements-class-correspondence-to-conformance-classes target:: /req/core/requirements-class-correspondence-to-conformance-classes test-purpose:: Validate that the requirements classes are in a one-to-one correspondence to the conformance test classes, and thus to the various certificate of conformance types possible for a candidate implementation. diff --git a/sources/abstract_tests/core/ATS9_no-optional-tests.adoc b/sources/abstract_tests/core/ATS9_no-optional-tests.adoc index 7cd52fe..aa090b3 100644 --- a/sources/abstract_tests/core/ATS9_no-optional-tests.adoc +++ b/sources/abstract_tests/core/ATS9_no-optional-tests.adoc @@ -1,7 +1,9 @@ [[ats_no-optional-tests]] [abstract_test] +.No Optional Elements in Requirements classes ==== [%metadata] +name:: No Optional Elements in Requirements classes identifier:: /conf/core/no-optional-tests target:: /req/core/no-optional-tests test-purpose:: Validate that a conformance class does not contain any optional conformance tests. diff --git a/sources/document.adoc b/sources/document.adoc index a93bdc1..5d8a688 100644 --- a/sources/document.adoc +++ b/sources/document.adoc @@ -1,13 +1,13 @@ = The ModSpec Model - Part 1: Core - A Standard for Designing and Writing Modular Standards -:doctype: draft standard -:docsubtype: logical-model -:status: Draft +:doctype: standard +:docsubtype: conceptual-model +:status: draft :committee: technical :docnumber: 08-131r5 :edition: 1.1.0 :received-date: 2025-08-22 -:issued-date: 2025-xx-xx -:published-date: 2025-xx-xx +:issued-date: 2025-08-02 +:published-date: 2025-08-22 :copyright-year: 2025 :fullname: Carl Reed, PhD :role: editor @@ -16,10 +16,10 @@ :fullname_3: John Herring, PhD :role_3: editor :language: en -:submitting-organizations: Carl Reed, Charles Heazel, ImageMatters +:submitting-organizations: Carl Reed & Associates; Heazeltech; ImageMatters/Tema; UK Met Office :imagesdir: images :mn-document-class: ogc -:mn-output-extensions: xml,html,doc,pdf,rxl +:mn-output-extensions: xml,html,pdf,rxl :local-cache-only: :data-uri-image: @@ -47,6 +47,8 @@ include::sections/aa-abstract-conformance.adoc[] include::sections/ab-changes-required.adoc[] +include::sections/ac-definitions.adoc[] + include::sections/ad-bibliography.adoc[] include::sections/ae-acknowledgements.adoc[] diff --git a/sources/ogc-modspec-policy/00-preface.adoc b/sources/ogc-modspec-policy/00-preface.adoc index 56f1f33..79cd138 100644 --- a/sources/ogc-modspec-policy/00-preface.adoc +++ b/sources/ogc-modspec-policy/00-preface.adoc @@ -1,9 +1,9 @@ -[.preface] +[abstract] == Abstract -This OGC ModSpec Policy specifies requirements and guidance for using the OGC ModSpec Standard as the formal structure for all OGC standards documents. -This OGC member Policy mandates using the ModSpec 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 (conformance suite) designed to enable the consistent +This OGC ModSpec Policy specifies requirements and guidance for using the OGC ModSpec Standard as the formal structure for all OGC standards documents. +This OGC member Policy mandates using the ModSpec 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 (conformance suite) designed to enable the consistent and verifiable testing of implementations of an OGC Standard that claim conformance. 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 process and then submitted to the OGC. @@ -14,17 +14,17 @@ NOTE: For the purposes of this OGC ModSpec Policy document, all the terms and de == Scope -The ModSpec Core Standard defines characteristics and structure for the specification of Standards +The ModSpec Core Standard 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. +interoperability. Part 1 of the ModSpec defines the core requirements class and the related recommendations that define the ModSpec core. -Part 2 of the ModSpec defines the requirements for using UML. -The UML extension is if the organizing mechanism for the data model used in a standard is an object model. Then the mapping from parts of the +Part 2 of the ModSpec defines the requirements for using UML. +The UML extension 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 3 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. +Part 3 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. diff --git a/sources/permissions/core/PER001_informational-content.adoc b/sources/permissions/core/PER001_informational-content.adoc index dd9a017..74778cd 100644 --- a/sources/permissions/core/PER001_informational-content.adoc +++ b/sources/permissions/core/PER001_informational-content.adoc @@ -1,10 +1,12 @@ [[per-1]] [permission] +.Informational content in the core ==== [%metadata] +name:: Informational content in the core identifier:: /per/core/informational-content-in-core -part:: The informational and structural universals of the standard _MAY_ be included in the core text of the standard without violations of the ModSpec. +part:: The informational and structural universals of the standard _MAY_ be included in the core text of the standard without violations of the ModSpec. This is true if the requirements of the extension are not implicit in what is included in the core. part:: The core _MAY_ contain the definition and schema of commonly used terms and data structures for use in other components and/or structures throughout the standard. ==== diff --git a/sources/permissions/core/PER002_external-vocabs-core.adoc b/sources/permissions/core/PER002_external-vocabs-core.adoc index 348b145..a0a80ca 100644 --- a/sources/permissions/core/PER002_external-vocabs-core.adoc +++ b/sources/permissions/core/PER002_external-vocabs-core.adoc @@ -1,8 +1,10 @@ [[per-2]] [permission] +.External vocabularies and schemas imported to core ==== [%metadata] +name:: External vocabularies and schemas imported to core identifier:: /per/core/external-vocabs-core -part:: Importation of external vocabularies and schemas _MAY_ be in the core of a standard. +statement:: Importation of external vocabularies and schemas _MAY_ be in the core of a standard. ==== diff --git a/sources/permissions/core/PER003_repeated-requirements.adoc b/sources/permissions/core/PER003_repeated-requirements.adoc index 0735a79..70a8491 100644 --- a/sources/permissions/core/PER003_repeated-requirements.adoc +++ b/sources/permissions/core/PER003_repeated-requirements.adoc @@ -1,9 +1,11 @@ [[per-3]] [permission] +.Repeated requirements applies to different standardization target types ==== [%metadata] +name:: Repeated requirements applies to different standardization target types identifier:: /per/core/repeated-requirements -part:: If needed, a requirement _MAY_ be repeated word for word in another requirement up +statement:: If needed, a requirement _MAY_ be repeated word for word in another requirement up to but not including the identification of the standardization target type. ==== diff --git a/sources/permissions/core/PER004_abstract-superclass.adoc b/sources/permissions/core/PER004_abstract-superclass.adoc index 475d374..4a1a8c8 100644 --- a/sources/permissions/core/PER004_abstract-superclass.adoc +++ b/sources/permissions/core/PER004_abstract-superclass.adoc @@ -1,9 +1,11 @@ [[per-4]] [permission] +.Abstract superclass of all affected standardization target types ==== [%metadata] +name:: Abstract superclass of all affected standardization target types identifier:: /per/core/abstract-superclass -part:: The standard _MAY_ introduce an abstract superclass of all affected standardization target types and +statement:: The standard _MAY_ introduce an abstract superclass of all affected standardization target types and use this for the requirements common to all of the affected target types. ==== diff --git a/sources/permissions/core/PER005_conf-class-paramterized.adoc b/sources/permissions/core/PER005_conf-class-paramterized.adoc index 7ca91f8..d585a22 100644 --- a/sources/permissions/core/PER005_conf-class-paramterized.adoc +++ b/sources/permissions/core/PER005_conf-class-paramterized.adoc @@ -1,8 +1,10 @@ [[per-5]] [permission] +.Parameterization of conformance class ==== [%metadata] +name:: Parameterization of conformance class identifier:: /per/core/conf-class-paramterized -part:: A Conformance class _MAY_ be parameterized.. +statement:: A Conformance class _MAY_ be parameterized.. ==== diff --git a/sources/permissions/core/PER006_core-type.adoc b/sources/permissions/core/PER006_core-type.adoc index e695f86..be2f14b 100644 --- a/sources/permissions/core/PER006_core-type.adoc +++ b/sources/permissions/core/PER006_core-type.adoc @@ -1,8 +1,10 @@ [[per-6]] [permission] +.Abstraction level of the core ==== [%metadata] +name:: Abstraction level of the core identifier:: /per/core/core-type -part:: The core _MAY_ be partially or totally abstract. +statement:: The core _MAY_ be partially or totally abstract. ==== diff --git a/sources/permissions/core/PER007_req-class-another-standard.adoc b/sources/permissions/core/PER007_req-class-another-standard.adoc index 7336d0e..54263b9 100644 --- a/sources/permissions/core/PER007_req-class-another-standard.adoc +++ b/sources/permissions/core/PER007_req-class-another-standard.adoc @@ -1,8 +1,10 @@ [[per-7]] [permission] +.Core requirements class from another standard ==== [%metadata] +name:: Core requirements class from another standard identifier:: /per/core/req-class-another-standard -part:: The core requirements class in a standard _MAY_ be a conformance class defined in another standard. +statement:: The core requirements class in a standard _MAY_ be a conformance class defined in another standard. ==== diff --git a/sources/permissions/core/PER008_core-maybe-recommendations.adoc b/sources/permissions/core/PER008_core-maybe-recommendations.adoc index 33a9b67..2e1af0b 100644 --- a/sources/permissions/core/PER008_core-maybe-recommendations.adoc +++ b/sources/permissions/core/PER008_core-maybe-recommendations.adoc @@ -1,9 +1,11 @@ [[per-8]] [permission] +.Requirements not mandatory in core ==== [%metadata] +name:: Requirements not mandatory in core identifier:: /per/core/core-maybe-recommendations -part:: Since the basic concept of some standards is mechanism not implementation, the core _MAY_ contain only +statement:: Since the basic concept of some standards is mechanism not implementation, the core _MAY_ contain only recommendations and state no requirements. ==== diff --git a/sources/recommendations/core/REC001_uri-external-use.adoc b/sources/recommendations/core/REC001_uri-external-use.adoc index f7f49b8..464a5a8 100644 --- a/sources/recommendations/core/REC001_uri-external-use.adoc +++ b/sources/recommendations/core/REC001_uri-external-use.adoc @@ -1,10 +1,12 @@ [[rec-1]] [recommendation] +.Use of unique identifiers/labels in external documentation ==== [%metadata] +name:: Use of unique identifiers/labels in external documentation identifier:: /rec/core/uri-external-use -part:: These unique identifiers/labels _SHOULD_ be used in any external documentation that references +statement:: These unique identifiers/labels _SHOULD_ be used in any external documentation that references component elements of a standard in a normative manner, including but not limited to other standards, implementations of the conformance test suite, or certificates of conformance for implementations conformant to the standard in question. diff --git a/sources/recommendations/core/REC002-parallel-structure.adoc b/sources/recommendations/core/REC002-parallel-structure.adoc index c0b2b7d..8cbdbbd 100644 --- a/sources/recommendations/core/REC002-parallel-structure.adoc +++ b/sources/recommendations/core/REC002-parallel-structure.adoc @@ -1,9 +1,11 @@ [[rec-2]] [recommendation] +.Structural alignment of normative clauses and conformance classes ==== [%metadata] +name:: Structural alignment of normative clauses and conformance classes identifier:: /rec/core/parallel-structure -part:: If possible, the structure of the normative clauses of the standard _SHOULD_ +statement:: If possible, the structure of the normative clauses of the standard _SHOULD_ parallel the structure of the conformance classes in the conformance clause. ==== diff --git a/sources/recommendations/core/REC003-circular-dependencies.adoc b/sources/recommendations/core/REC003-circular-dependencies.adoc index 12e0e82..dcc9750 100644 --- a/sources/recommendations/core/REC003-circular-dependencies.adoc +++ b/sources/recommendations/core/REC003-circular-dependencies.adoc @@ -1,9 +1,11 @@ [[rec-3]] [recommendation] +.Circular dependencies of core elements ==== [%metadata] +name:: Circular dependencies of core elements identifier:: /rec/core/circular-dependencies -part:: Circular dependencies of all types _SHOULD_ be avoided whenever possible. +statement:: Circular dependencies of all types _SHOULD_ be avoided whenever possible. ==== diff --git a/sources/recommendations/core/REC004-simple-core.adoc b/sources/recommendations/core/REC004-simple-core.adoc index c360748..f32fccd 100644 --- a/sources/recommendations/core/REC004-simple-core.adoc +++ b/sources/recommendations/core/REC004-simple-core.adoc @@ -1,8 +1,10 @@ [[rec-4]] [recommendation] +.Simplicity of the core ==== [%metadata] +name:: Simplicity of the core identifier:: /rec/core/simple-core -part:: The core _SHOULD_ be as simple as possible. +statement:: The core _SHOULD_ be as simple as possible. ==== diff --git a/sources/recommendations/core/REC005-optional-tests.adoc b/sources/recommendations/core/REC005-optional-tests.adoc index d9ddd78..ae6c69b 100644 --- a/sources/recommendations/core/REC005-optional-tests.adoc +++ b/sources/recommendations/core/REC005-optional-tests.adoc @@ -1,9 +1,13 @@ [[rec-5]] [recommendation] +.Identification of optional tests in imported requirements classes ==== [%metadata] +name:: Identification of optional tests in imported requirements classes identifier:: /rec/core/optional-tests -part:: If a requirements class is from another standard, the current standard _SHOULD_ identify any optional tests -in that conformance class that are required by the current standard's core requirements class. See <>. +statement:: If a requirements class is from another standard, the current standard +_SHOULD_ identify any optional tests in that conformance class that are required +by the current standard's core requirements class. See +xref:/req/core/imported-requirements-class[]. ==== diff --git a/sources/relaton/cache/iso/iso_19105_2022.xml b/sources/relaton/cache/iso/iso_19105_2022.xml deleted file mode 100644 index 07c6f1a..0000000 --- a/sources/relaton/cache/iso/iso_19105_2022.xml +++ /dev/null @@ -1,54 +0,0 @@ - - 2025-01-27 - Geographic information - Conformance and testing - Geographic information - Conformance and testing - Information géographique - Conformité et essais - Information géographique - Conformité et essais - https://www.iso.org/standard/76457.html - https://www.iso.org/obp/ui/en/#!iso:std:76457:en - https://www.iso.org/contents/data/standard/07/64/76457.detail.rss - ISO 19105:2022 - ISO 19105:2022(E) - urn:iso:std:iso:19105:stage-60.60 - 19105 - - 2022-07 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - 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. - 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. - - 60 - 60 - - - 2022 - - - ISO - - - - - - ISO 19105:2000 - ISO 19105:2000 - - - Geneva - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_10000-1.notfound b/sources/relaton/cache/iso/iso_iec_10000-1.notfound deleted file mode 100644 index 8f9d260..0000000 --- a/sources/relaton/cache/iso/iso_iec_10000-1.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-01-27 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_10000-1_1998.notfound b/sources/relaton/cache/iso/iso_iec_10000-1_1998.notfound deleted file mode 100644 index 5ee7ecd..0000000 --- a/sources/relaton/cache/iso/iso_iec_10000-1_1998.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-03-05 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml b/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml deleted file mode 100644 index 2f907ce..0000000 --- a/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml +++ /dev/null @@ -1,72 +0,0 @@ - - 2025-01-27 - Information technology - Database languages - SQL multimedia and application packages -- Part 3: Spatial - Information technology - Database languages - SQL multimedia and application packages -- Part 3: Spatial - Technologies de l'information - Langages de bases de données - Multimédia SQL et paquetages d'application -- Partie 3: Spatial - Technologies de l'information - Langages de bases de données - Multimédia SQL et paquetages d'application -- Partie 3: Spatial - https://www.iso.org/standard/38651.html - https://www.iso.org/contents/data/standard/03/86/38651.detail.rss - ISO/IEC 13249-3:2006 - ISO/IEC 13249-3:2006(E) - urn:iso:std:iso-iec:13249:-3:stage-95.99 - 13249 - - 2006-11 - - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 3 - en - fr - - ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. -Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. - ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. -Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. - - 95 - 99 - - - 2006 - - - ISO/IEC - - - - - - ISO/IEC 13249-3:2003 - ISO/IEC 13249-3:2003 - - - - - ISO/IEC 13249-3:2011 - ISO/IEC 13249-3:2011 - - 2011-04-07 - - - - Geneva - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml b/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml deleted file mode 100644 index e521436..0000000 --- a/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml +++ /dev/null @@ -1,66 +0,0 @@ - - 2025-01-27 - Information technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation — Schematron - Information technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation — Schematron - Technologies de l'information - Langages de définition de schéma de documents (DSDL) - Partie 3: Validation de règles orientées — Schematron - Technologies de l'information - Langages de définition de schéma de documents (DSDL) - Partie 3: Validation de règles orientées — Schematron - https://www.iso.org/standard/40833.html - https://www.iso.org/contents/data/standard/04/08/40833.detail.rss - ISO/IEC 19757-3:2006 - ISO/IEC 19757-3:2006(E) - urn:iso:std:iso-iec:19757:-3:stage-95.99 - 19757 - - 2006-06 - - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 1 - en - fr - - ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) -ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. - ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) -ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. - - 95 - 99 - - - 2006 - - - ISO/IEC - - - - - - ISO/IEC 19757-3:2016 - ISO/IEC 19757-3:2016 - - 2016-01-14 - - - - Geneva - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_9075_2003.notfound b/sources/relaton/cache/iso/iso_iec_9075_2003.notfound deleted file mode 100644 index 8f9d260..0000000 --- a/sources/relaton/cache/iso/iso_iec_9075_2003.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-01-27 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_dir_2.xml b/sources/relaton/cache/iso/iso_iec_dir_2.xml deleted file mode 100644 index d4c1e41..0000000 --- a/sources/relaton/cache/iso/iso_iec_dir_2.xml +++ /dev/null @@ -1,52 +0,0 @@ - - 2025-08-22 - ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents - Directives ISO/CEI, Partie 2 - Principes et règles de structure et de rédaction des documents ISO et IEC - https://www.iso.org/sites/directives/current/part2/index.xhtml - ISO/IEC DIR 2 - 9 - en - - - 2021 - - - International Organization for Standardization - ISO - www.iso.org - - - - - - 2025-08-22 - ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents - Directives ISO/CEI, Partie 2 - Principes et règles de structure et de rédaction des documents ISO et IEC - https://www.iso.org/sites/directives/current/part2/index.xhtml - ISO/IEC DIR 2 - - 2021-05-01 - - 9 - en - - - 2021 - - - International Organization for Standardization - ISO - www.iso.org - - - - - - - directive - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_tr_10000.notfound b/sources/relaton/cache/iso/iso_iec_tr_10000.notfound deleted file mode 100644 index 140858f..0000000 --- a/sources/relaton/cache/iso/iso_iec_tr_10000.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-08-22 \ No newline at end of file diff --git a/sources/relaton/cache/iso/version b/sources/relaton/cache/iso/version deleted file mode 100644 index e4c59dc..0000000 --- a/sources/relaton/cache/iso/version +++ /dev/null @@ -1 +0,0 @@ -d4cbf244102652ea31d565b43af29b3f \ No newline at end of file diff --git a/sources/relaton/cache/ogc/08-131r3.xml b/sources/relaton/cache/ogc/08-131r3.xml deleted file mode 100644 index fde7a25..0000000 --- a/sources/relaton/cache/ogc/08-131r3.xml +++ /dev/null @@ -1,37 +0,0 @@ - - 2025-03-20 - The Specification Model - Standard for Modular specifications - The Specification Model - Standard for Modular specifications - - https://portal.ogc.org/files/?artifact_id=34762&version=2 - 08-131r3 - - 2009-10-19 - - - - - - Policy SWG - - - - - - - Open Geospatial Consortium - - - 3 - en - - This standard contains requirements for writing standards to be used for any document whose -eventual purpose is the specification of requirements for software, services or data structures. - - standard - - technical - - - \ No newline at end of file diff --git a/sources/relaton/cache/ogc/ogc_08-131r3.redirect b/sources/relaton/cache/ogc/ogc_08-131r3.redirect deleted file mode 100644 index 7dbfc5d..0000000 --- a/sources/relaton/cache/ogc/ogc_08-131r3.redirect +++ /dev/null @@ -1 +0,0 @@ -redirection OGC(08-131r3) \ No newline at end of file diff --git a/sources/relaton/cache/ogc/version b/sources/relaton/cache/ogc/version deleted file mode 100644 index 8ada7e3..0000000 --- a/sources/relaton/cache/ogc/version +++ /dev/null @@ -1 +0,0 @@ -b4be7d3992a3f62eee3c0fb4a545190c \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.4.1_superstructure.notfound b/sources/relaton/cache/omg/omg_uml_2.4.1_superstructure.notfound deleted file mode 100644 index 140858f..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.4.1_superstructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-08-22 \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.5_infrastructure.notfound b/sources/relaton/cache/omg/omg_uml_2.5_infrastructure.notfound deleted file mode 100644 index 140858f..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.5_infrastructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2025-08-22 \ No newline at end of file diff --git a/sources/relaton/cache/omg/version b/sources/relaton/cache/omg/version deleted file mode 100644 index 49091a0..0000000 --- a/sources/relaton/cache/omg/version +++ /dev/null @@ -1 +0,0 @@ -819940ce0d14f052770ac65942363e11 \ No newline at end of file diff --git a/sources/relaton/cache/w3c/version b/sources/relaton/cache/w3c/version deleted file mode 100644 index 49091a0..0000000 --- a/sources/relaton/cache/w3c/version +++ /dev/null @@ -1 +0,0 @@ -819940ce0d14f052770ac65942363e11 \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml b/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml deleted file mode 100644 index 880bd50..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml +++ /dev/null @@ -1,105 +0,0 @@ - - 2025-08-22 - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/xmlschema11-1/ - W3C xmlschema11-1 - xmlschema11-1 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/ - W3C REC-xmlschema11-1-20120405 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ - W3C PR-xmlschema11-1-20120119 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2011/CR-xmlschema11-1-20110721/ - W3C CR-xmlschema11-1-20110721 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/ - W3C WD-xmlschema11-1-20091203 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ - W3C CR-xmlschema11-1-20090430 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/ - W3C WD-xmlschema11-1-20090130 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - https://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/ - W3C WD-xmlschema11-1-20080620 - - - - - W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures - https://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ - W3C WD-xmlschema11-1-20070830 - - - - - XML Schema 1.1 Part 1: Structures - https://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ - W3C WD-xmlschema11-1-20060831 - - - - - XML Schema 1.1 Part 1: Structures - https://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ - W3C WD-xmlschema11-1-20060330 - - - - - XML Schema 1.1 Part 1: Structures - https://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ - W3C WD-xmlschema11-1-20050224 - - - - - XML Schema 1.1 Part 1: Structures - https://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/ - W3C WD-xmlschema11-1-20040716 - - - - W3C technicalReport - xmlschema11-1 - - \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml b/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml deleted file mode 100644 index 751b422..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml +++ /dev/null @@ -1,98 +0,0 @@ - - 2025-08-22 - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/xmlschema11-2/ - W3C xmlschema11-2 - xmlschema11-2 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/ - W3C REC-xmlschema11-2-20120405 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ - W3C PR-xmlschema11-2-20120119 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/ - W3C CR-xmlschema11-2-20110721 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/ - W3C WD-xmlschema11-2-20091203 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ - W3C CR-xmlschema11-2-20090430 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2009/WD-xmlschema11-2-20090130/ - W3C WD-xmlschema11-2-20090130 - - - - - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - https://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/ - W3C WD-xmlschema11-2-20080620 - - - - - XML Schema 1.1 Part 2: Datatypes - https://www.w3.org/TR/2006/WD-xmlschema11-2-20060217/ - W3C WD-xmlschema11-2-20060217 - - - - - XML Schema 1.1 Part 2: Datatypes - https://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/ - W3C WD-xmlschema11-2-20060116 - - - - - XML Schema 1.1 Part 2: Datatypes - https://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/ - W3C WD-xmlschema11-2-20050224 - - - - - XML Schema 1.1 Part 2: Datatypes - https://www.w3.org/TR/2004/WD-xmlschema11-2-20040716/ - W3C WD-xmlschema11-2-20040716 - - - - W3C technicalReport - xmlschema11-2 - - \ No newline at end of file diff --git a/sources/requirements/core/REQ001_testable.adoc b/sources/requirements/core/REQ001_testable.adoc index a6b4cfb..2987b93 100644 --- a/sources/requirements/core/REQ001_testable.adoc +++ b/sources/requirements/core/REQ001_testable.adoc @@ -1,13 +1,14 @@ [[reqs-are-testable]] -[[req-1]] [requirement] +.Testable requirements ==== [%metadata] +name:: Testable requirements identifier:: /req/core/reqs-are-testable -part:: All the parts of a requirement _SHALL_ be testable. +part:: All the parts of a requirement _SHALL_ be testable. part:: Failure to pass any part of a requirement _SHALL_ be a failure to pass the associated conformance test. +guidance:: This further means that failure to pass the test specified for a part of requirement is a failure to pass the requirement. ==== -NOTE: This further means that failure to pass the test specified for a part of requirement is a failure to pass the requirement. diff --git a/sources/requirements/core/REQ002_assigned-uri.adoc b/sources/requirements/core/REQ002_assigned-uri.adoc index 8866fca..f38f54d 100644 --- a/sources/requirements/core/REQ002_assigned-uri.adoc +++ b/sources/requirements/core/REQ002_assigned-uri.adoc @@ -1,11 +1,12 @@ -[[req-2]] [requirement] +.Assigned URIs for all components ==== [%metadata] +name:: Assigned URIs for all components identifier:: /req/core/all-components-assigned-uri -part:: Each component of the standard, including requirements, requirements packages, requirements classes, -conformance tests, conformance packages, and conformance test classes _SHALL_ be assigned a unique identifier and/or label. +statement:: Each component of the standard, including requirements, requirements packages, requirements classes, +conformance tests, conformance packages, and conformance test classes _SHALL_ be assigned a unique identifier and/or label. +guidance:: In the OGC, the enforcement of this requirement and its associated recommendation is the purview of the OGC Naming Authority or its equivalent. ==== -NOTE: In the OGC, the enforcement of this requirement and its associated recommendation is the purview of the OGC Naming Authority or its equivalent. diff --git a/sources/requirements/core/REQ028_reqs-are-in-class.adoc b/sources/requirements/core/REQ028_reqs-are-in-class.adoc index 1ef8425..2460252 100644 --- a/sources/requirements/core/REQ028_reqs-are-in-class.adoc +++ b/sources/requirements/core/REQ028_reqs-are-in-class.adoc @@ -1,9 +1,9 @@ -[[req_requirements-are-in-class]] -[[req-28]] [requirement] +.Every requirement is in a requirements class ==== [%metadata] +name:: Every requirement is in a requirements class identifier:: /req/core/reqs-are-in-class -part:: Each requirement in the standard _SHALL_ be associated with exactly one requirements class. +statement:: Each requirement in the standard _SHALL_ be associated with exactly one requirements class. ==== diff --git a/sources/requirements/core/REQ10_all-parameters-expressed.adoc b/sources/requirements/core/REQ10_all-parameters-expressed.adoc index 6d8c91f..1ab004e 100644 --- a/sources/requirements/core/REQ10_all-parameters-expressed.adoc +++ b/sources/requirements/core/REQ10_all-parameters-expressed.adoc @@ -1,9 +1,9 @@ -[[req_all-parameters-expressed]] -[[req-10]] [requirement] +.Parameters fully expressed ==== [%metadata] +name:: Parameters fully expressed identifier:: /req/core/all-parameters-expressed -part:: A certificate of conformance _SHALL_ specify all parameter values used to pass the tests in its conformance test class. +statement:: A certificate of conformance _SHALL_ specify all parameter values used to pass the tests in its conformance test class. ==== diff --git a/sources/requirements/core/REQ11_conf-class-single-req-class.adoc b/sources/requirements/core/REQ11_conf-class-single-req-class.adoc index c2736e1..aa98daa 100644 --- a/sources/requirements/core/REQ11_conf-class-single-req-class.adoc +++ b/sources/requirements/core/REQ11_conf-class-single-req-class.adoc @@ -1,9 +1,9 @@ -[[req_conf-class-single-req-class]] -[[req-11]] [requirement] +.Conformance class only tests a single requirements class ==== [%metadata] +name:: Conformance class only tests a single requirements class identifier:: /req/core/conf-class-single-req-class -part:: A Conformance class _SHALL_ explicitly test only requirements from a single requirements class. +statement:: A Conformance class _SHALL_ explicitly test only requirements from a single requirements class. ==== diff --git a/sources/requirements/core/REQ12_con-class-dependencies.adoc b/sources/requirements/core/REQ12_con-class-dependencies.adoc index 8a3fcd6..8a36a5c 100644 --- a/sources/requirements/core/REQ12_con-class-dependencies.adoc +++ b/sources/requirements/core/REQ12_con-class-dependencies.adoc @@ -1,10 +1,10 @@ -[[req_con-class-dependencies]] -[[req-12]] [requirement] +.Conformance class dependencies are specified ==== [%metadata] +name:: Conformance class dependencies are specified identifier:: /req/core/con-class-dependencies -part:: A Conformance class _SHALL_ specify any other conformance class upon which it is dependent and +part:: A Conformance class _SHALL_ specify any other conformance class upon which it is dependent and part:: That other conformance class _SHALL_ be used to test the specified dependency. ==== diff --git a/sources/requirements/core/REQ13_imported-requirements-class.adoc b/sources/requirements/core/REQ13_imported-requirements-class.adoc index 01dd0a9..791b3d7 100644 --- a/sources/requirements/core/REQ13_imported-requirements-class.adoc +++ b/sources/requirements/core/REQ13_imported-requirements-class.adoc @@ -1,9 +1,10 @@ -[[req_imported-requirements-class]] -[[req-13]] [requirement] +.Imported requirements class that are optional is factored out ==== [%metadata] +name:: Imported requirements class that are optional is factored out identifier:: /req/core/imported-requirements-class part:: 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. part:: Each such used requirements class SHALL be a conformance class of the source standard or a combination of conformance classes of the source standard or standards. +==== \ No newline at end of file diff --git a/sources/requirements/core/REQ14_all-classes-explicitly-named.adoc b/sources/requirements/core/REQ14_all-classes-explicitly-named.adoc index 13b74e7..b7a734c 100644 --- a/sources/requirements/core/REQ14_all-classes-explicitly-named.adoc +++ b/sources/requirements/core/REQ14_all-classes-explicitly-named.adoc @@ -1,9 +1,9 @@ -[[req_all-classes-explicitly-named]] -[[req-14]] [requirement] +.All requirements and conformance test classes explicitly named ==== [%metadata] +name:: All requirements and conformance test classes explicitly named identifier:: /req/core/all-classes-explicitly-named -part:: For the sake of consistency and readability, all requirements classes and all conformance test classes _SHALL_ be explicitly named, with corresponding requirements classes and conformance test classes having similar names. +statement:: For the sake of consistency and readability, all requirements classes and all conformance test classes _SHALL_ be explicitly named, with corresponding requirements classes and conformance test classes having similar names. ==== diff --git a/sources/requirements/core/REQ15_conf-class-test-req-class.adoc b/sources/requirements/core/REQ15_conf-class-test-req-class.adoc index b7acc7e..d0b0dbe 100644 --- a/sources/requirements/core/REQ15_conf-class-test-req-class.adoc +++ b/sources/requirements/core/REQ15_conf-class-test-req-class.adoc @@ -1,9 +1,9 @@ -[[req_conf-class-test-req-class]] -[[req-15]] [requirement] +.Conformance test class comprehensively tests all requirements of associated requirements class ==== [%metadata] +name:: Conformance test class comprehensively tests all requirements of associated requirements class identifier:: /req/core/conf-class-test-req-class -part:: A conformance test class _SHALL_ test all of the requirements of the associated requirements class. +statement:: A conformance test class _SHALL_ test all of the requirements of the associated requirements class. ==== diff --git a/sources/requirements/core/REQ16_co-dependent-requirements.adoc b/sources/requirements/core/REQ16_co-dependent-requirements.adoc index 37a0b6e..4bf903d 100644 --- a/sources/requirements/core/REQ16_co-dependent-requirements.adoc +++ b/sources/requirements/core/REQ16_co-dependent-requirements.adoc @@ -1,9 +1,9 @@ -[[req_co-dependent-requirements]] -[[req-16]] [requirement] +.Co-dependent requirements are in the same requirements class ==== [%metadata] +name:: Co-dependent requirements are in the same requirements class identifier:: /req/core/co-dependent-requirements part:: If any two requirements are co-dependent (each dependent on the other) then they _SHALL_ be in the same requirements class. part:: If any two requirements classes are co-dependent, they _SHALL_ be merged into a single requirements class. diff --git a/sources/requirements/core/REQ17_structure-requirements-classes.adoc b/sources/requirements/core/REQ17_structure-requirements-classes.adoc index 7c8f33a..b2bc215 100644 --- a/sources/requirements/core/REQ17_structure-requirements-classes.adoc +++ b/sources/requirements/core/REQ17_structure-requirements-classes.adoc @@ -1,9 +1,9 @@ -[[req_structure-requirements-classes]] -[[req-17]] [requirement] +.Natural structure to requirements classes ==== [%metadata] +name:: Natural structure to requirements classes identifier:: /req/core/structure-requirements-classes -part:: There _SHALL_ be a natural structure to the requirements classes so that each may be implemented on top of any implementations of its dependencies and independent of its extensions. +statement:: There _SHALL_ be a natural structure to the requirements classes so that each may be implemented on top of any implementations of its dependencies and independent of its extensions. ==== diff --git a/sources/requirements/core/REQ18_requirements-and-dependencies.adoc b/sources/requirements/core/REQ18_requirements-and-dependencies.adoc index 0d513a6..2307419 100644 --- a/sources/requirements/core/REQ18_requirements-and-dependencies.adoc +++ b/sources/requirements/core/REQ18_requirements-and-dependencies.adoc @@ -1,9 +1,9 @@ -[[req_requirements-and-dependencies]] -[[req-18]] [requirement] +.Requirements do not redefine dependencies ==== [%metadata] +name:: Requirements do not redefine dependencies identifier:: /req/core/requirements-and-dependencies -part:: No requirements class _SHALL_ redefine the requirements of its dependencies, unless that redefinition is for an entity derived from but not contained in those dependencies. +statement:: No requirements class _SHALL_ redefine the requirements of its dependencies, unless that redefinition is for an entity derived from but not contained in those dependencies. ==== diff --git a/sources/requirements/core/REQ19_profile-conformance.adoc b/sources/requirements/core/REQ19_profile-conformance.adoc index a8b1d36..917a3fa 100644 --- a/sources/requirements/core/REQ19_profile-conformance.adoc +++ b/sources/requirements/core/REQ19_profile-conformance.adoc @@ -1,9 +1,9 @@ -[[req_profile-conformance]] -[[req-19]] [requirement] +.Profile conformance tests defined as union of conformance classes ==== [%metadata] +name:: Profile conformance tests defined as union of conformance classes identifier:: /req/core/profile-conformance -part:: The conformance tests for a profile of a standard _SHALL_ be defined as the union of a list of conformance classes that are to be satisfied by that profile’s standardization targets. +statement:: The conformance tests for a profile of a standard _SHALL_ be defined as the union of a list of conformance classes that are to be satisfied by that profile’s standardization targets. ==== diff --git a/sources/requirements/core/REQ1_reqs-are-in-class.adoc b/sources/requirements/core/REQ1_reqs-are-in-class.adoc index 40039cb..cf2b7d7 100644 --- a/sources/requirements/core/REQ1_reqs-are-in-class.adoc +++ b/sources/requirements/core/REQ1_reqs-are-in-class.adoc @@ -1,5 +1,3 @@ -[[req_requirements-are-in-class]] -[[req-0]] [requirement] ==== diff --git a/sources/requirements/core/REQ20_core-requirements-separate.adoc b/sources/requirements/core/REQ20_core-requirements-separate.adoc index 7198b20..bf0045f 100644 --- a/sources/requirements/core/REQ20_core-requirements-separate.adoc +++ b/sources/requirements/core/REQ20_core-requirements-separate.adoc @@ -1,9 +1,9 @@ -[[req_core-requirements-separate]] -[[req-20]] [requirement] +.Core requirements are a separate requirements class ==== [%metadata] +name:: Core requirements are a separate requirements class identifier:: /req/core/core-requirements-separate -part:: The standard _SHALL_ define and identify a core set of requirements as a separate requirements class with a corresponding conformance class. +statement:: The standard _SHALL_ define and identify a core set of requirements as a separate requirements class with a corresponding conformance class. ==== diff --git a/sources/requirements/core/REQ21_general-recommendations-core.adoc b/sources/requirements/core/REQ21_general-recommendations-core.adoc index 5210128..1836a07 100644 --- a/sources/requirements/core/REQ21_general-recommendations-core.adoc +++ b/sources/requirements/core/REQ21_general-recommendations-core.adoc @@ -1,9 +1,9 @@ -[[req_general-recommendations-core]] -[[req-21]] [requirement] +.General recommendations for the standard are in the core ==== [%metadata] +name:: General recommendations for the standard are in the core identifier:: /req/core/general-recommendations-core -part:: All general recommendations for the standard _SHALL_ be in the core. +statement:: All general recommendations for the standard _SHALL_ be in the core. ==== diff --git a/sources/requirements/core/REQ22_req-class-not-core-stt-subtype-of-core.adoc b/sources/requirements/core/REQ22_req-class-not-core-stt-subtype-of-core.adoc index 960a71c..e8e79e7 100644 --- a/sources/requirements/core/REQ22_req-class-not-core-stt-subtype-of-core.adoc +++ b/sources/requirements/core/REQ22_req-class-not-core-stt-subtype-of-core.adoc @@ -1,9 +1,9 @@ -[[req_req-class-not-core-stt-subtype-of-core]] -[[req-22]] [requirement] +.Non-core requirements class depends on core and has standardization target type ==== [%metadata] +name:: Non-core requirements class depends on core and has standardization target type identifier:: /req/core/req-class-not-core-stt-subtype-of-core part:: Every requirements class in the standard, with the exception of the core, _SHALL_ have a standardization target type which is a subtype of that of the core. part:: Every requirement class in the standard, with the exception of the core, _SHALL_ have the core as a direct dependency. diff --git a/sources/requirements/core/REQ23_core-and-extensions.adoc b/sources/requirements/core/REQ23_core-and-extensions.adoc index 9354507..9ee5aff 100644 --- a/sources/requirements/core/REQ23_core-and-extensions.adoc +++ b/sources/requirements/core/REQ23_core-and-extensions.adoc @@ -1,9 +1,9 @@ -[[req_core-and-extensions]] -[[req-23]] [requirement] +.Standard specifies core and extensions as separate requirements classes ==== [%metadata] +name:: Standard specifies core and extensions as separate requirements classes identifier:: /req/core/core-and-extensions -part:: The standard _SHALL_ define and identify a core set of requirements as a separate requirements class with a corresponding conformance class. +statement:: The standard _SHALL_ define and identify a core set of requirements as a separate requirements class with a corresponding conformance class. ==== diff --git a/sources/requirements/core/REQ24_extensions-conformant-to-modspec.adoc b/sources/requirements/core/REQ24_extensions-conformant-to-modspec.adoc index 75d36d5..5e3ea7f 100644 --- a/sources/requirements/core/REQ24_extensions-conformant-to-modspec.adoc +++ b/sources/requirements/core/REQ24_extensions-conformant-to-modspec.adoc @@ -1,9 +1,9 @@ -[[req_extensions-conformant-to-the-modspec]] -[[req-24]] [requirement] +.Extensions conformant to the ModSpec ==== [%metadata] +name:: Extensions conformant to the ModSpec identifier:: /req/core/extensions-conformant-to-the-modspec -part:: A standard conformant to the ModSpec _SHALL_ require all conformant extensions to be conformant to the ModSpec. +statement:: A standard conformant to the ModSpec _SHALL_ require all conformant extensions to be conformant to the ModSpec. ==== diff --git a/sources/requirements/core/REQ25_restriction-of-extensions.adoc b/sources/requirements/core/REQ25_restriction-of-extensions.adoc index 57dfd28..0e38413 100644 --- a/sources/requirements/core/REQ25_restriction-of-extensions.adoc +++ b/sources/requirements/core/REQ25_restriction-of-extensions.adoc @@ -1,9 +1,9 @@ -[[req_restriction-of-extensions]] -[[req-25]] [requirement] +.No restriction of future extensions ==== [%metadata] +name:: No restriction of future extensions identifier:: /req/core/restriction-of-extensions -part:: The standard _SHALL_ never restrict in any manner future, logically valid extensions of its standardization target types. +statement:: The standard _SHALL_ never restrict in any manner future, logically valid extensions of its standardization target types. ==== diff --git a/sources/requirements/core/REQ26_optional-requirements.adoc b/sources/requirements/core/REQ26_optional-requirements.adoc index 0990909..b83f758 100644 --- a/sources/requirements/core/REQ26_optional-requirements.adoc +++ b/sources/requirements/core/REQ26_optional-requirements.adoc @@ -1,9 +1,9 @@ -[[req_optional-requirements]] -[[req-26]] [requirement] +.Conditional requirements are expressed as conformance classes ==== [%metadata] +name:: Conditional requirements are expressed as conformance classes identifier:: /req/core/optional-requirements -part:: The only conditional (optional) requirements acceptable in the standard _SHALL_ be expressible as a list of conformance classes to be passed. +statement:: The only conditional (optional) requirements acceptable in the standard _SHALL_ be expressible as a list of conformance classes to be passed. ==== diff --git a/sources/requirements/core/REQ27_req-class-overlap-by-reference.adoc b/sources/requirements/core/REQ27_req-class-overlap-by-reference.adoc index 3a6ea20..0671675 100644 --- a/sources/requirements/core/REQ27_req-class-overlap-by-reference.adoc +++ b/sources/requirements/core/REQ27_req-class-overlap-by-reference.adoc @@ -1,9 +1,9 @@ -[[req_req-class-overlap-by-reference]] -[[req-27]] [requirement] +.Requirements class overlap only by reference ==== [%metadata] +name:: Requirements class overlap only by reference identifier:: /req/core/req-class-overlap-by-reference -part:: The common portion of any two requirements classes _SHALL_ consist only of references to other requirements classes. +statement:: The common portion of any two requirements classes _SHALL_ consist only of references to other requirements classes. ==== diff --git a/sources/requirements/core/REQ3_vocabulary.adoc b/sources/requirements/core/REQ3_vocabulary.adoc index 1a3ec1f..7ec68df 100644 --- a/sources/requirements/core/REQ3_vocabulary.adoc +++ b/sources/requirements/core/REQ3_vocabulary.adoc @@ -1,10 +1,9 @@ -[[req_vocabulary-and-parent-req-class]] - -[[req-3]] [requirement] +.Interpretation of vocabulary described in requirements class ==== [%metadata] +name:: Interpretation of vocabulary described in requirements class identifier:: /req/core/vocabulary-and-parent-req-class -part:: Requirements on the use and interpretation of vocabulary _SHALL_ be in the requirements class where that use or interpretation is used. +statement:: Requirements on the use and interpretation of vocabulary _SHALL_ be in the requirements class where that use or interpretation is used. ==== diff --git a/sources/requirements/core/REQ4_single-standardization-target-type.adoc b/sources/requirements/core/REQ4_single-standardization-target-type.adoc index beb8221..fb049ed 100644 --- a/sources/requirements/core/REQ4_single-standardization-target-type.adoc +++ b/sources/requirements/core/REQ4_single-standardization-target-type.adoc @@ -1,10 +1,10 @@ -[[req_single-standardization-target-type]] -[[req-4]] [requirement] +.Single standardization target type ==== [%metadata] +name:: Single standardization target type identifier:: /req/core/single-standardization-target-type -part:: Each requirement class _SHALL_ have a single standardization target type. +statement:: Each requirement class _SHALL_ have a single standardization target type. ==== diff --git a/sources/requirements/core/REQ5_test-class-single-standardization-target.adoc b/sources/requirements/core/REQ5_test-class-single-standardization-target.adoc index 6c07b6c..acd410d 100644 --- a/sources/requirements/core/REQ5_test-class-single-standardization-target.adoc +++ b/sources/requirements/core/REQ5_test-class-single-standardization-target.adoc @@ -1,10 +1,10 @@ -[[req_test-class-single-standardization-target]] -[[req-5]] [requirement] +.Test class uniform standardization target type ==== [%metadata] +name:: Test class uniform standardization target type identifier:: /req/core/test-class-single-standardization-target-type -part:: All conformance tests in a single conformance test class _SHALL_ have the same standardization target type. +statement:: All conformance tests in a single conformance test class _SHALL_ have the same standardization target type. ==== diff --git a/sources/requirements/core/REQ6_requirements-grouped.adoc b/sources/requirements/core/REQ6_requirements-grouped.adoc index 821b2c8..7aeb3bc 100644 --- a/sources/requirements/core/REQ6_requirements-grouped.adoc +++ b/sources/requirements/core/REQ6_requirements-grouped.adoc @@ -1,10 +1,10 @@ -[[req_requirements-grouped]] -[[req-6]] [requirement] +.Requirements grouped in requirements classes ==== [%metadata] +name:: Requirements grouped in requirements classes identifier:: /req/core/requirements-grouped -part:: Requirements _SHALL_ be grouped together in clauses (numbered sections) of the document in a strictly hierarchical manner, consistent with the requirements classes. +statement:: Requirements _SHALL_ be grouped together in clauses (numbered sections) of the document in a strictly hierarchical manner, consistent with the requirements classes. ==== diff --git a/sources/requirements/core/REQ7_requirements-test-suite-structure.adoc b/sources/requirements/core/REQ7_requirements-test-suite-structure.adoc index 0fa7133..7de0add 100644 --- a/sources/requirements/core/REQ7_requirements-test-suite-structure.adoc +++ b/sources/requirements/core/REQ7_requirements-test-suite-structure.adoc @@ -1,10 +1,10 @@ -[[req_requirements-test-suite-structure]] -[[req-7]] [requirement] +.Logical alignment of requirements and test suite structure ==== [%metadata] +name:: Logical alignment of requirements and test suite structure identifier:: /req/core/requirements-test-suite-structure -part:: The requirements structure of the standard _SHALL_ be in logical correspondence with the test suite structure. +statement:: The requirements structure of the standard _SHALL_ be in logical correspondence with the test suite structure. ==== diff --git a/sources/requirements/core/REQ8_requirements-correspondence.adoc b/sources/requirements/core/REQ8_requirements-correspondence.adoc index b035c85..71f520b 100644 --- a/sources/requirements/core/REQ8_requirements-correspondence.adoc +++ b/sources/requirements/core/REQ8_requirements-correspondence.adoc @@ -1,10 +1,10 @@ -[[req_requirements-class-correspondence-to-conformance-classes]] -[[req-8]] [requirement] +.Requirements class correspondence to conformance classes ==== [%metadata] +name:: Requirements class correspondence to conformance classes identifier:: /req/core/requirements-class-correspondence-to-conformance-classes -part:: The requirements classes _SHALL_ be in a one-to-one correspondence to the conformance test classes, and thus to the various certificate of conformance types possible for a candidate implementation. +statement:: The requirements classes _SHALL_ be in a one-to-one correspondence to the conformance test classes, and thus to the various certificate of conformance types possible for a candidate implementation. ==== diff --git a/sources/requirements/core/REQ9_no-optional-tests.adoc b/sources/requirements/core/REQ9_no-optional-tests.adoc index 9acd5be..035c386 100644 --- a/sources/requirements/core/REQ9_no-optional-tests.adoc +++ b/sources/requirements/core/REQ9_no-optional-tests.adoc @@ -1,10 +1,10 @@ -[[req_no-optional-tests]] -[[req-9]] [requirement] +.No optional conformance tests ==== [%metadata] +name:: No optional conformance tests identifier:: /req/core/no-optional-tests -part:: A conformance class _SHALL_ not contain any optional conformance tests. +statement:: A conformance class _SHALL_ not contain any optional conformance tests. ==== diff --git a/sources/requirements/core/REQ_ogc-compliance.adoc b/sources/requirements/core/REQ_ogc-compliance.adoc index 7ac2bb0..1789660 100644 --- a/sources/requirements/core/REQ_ogc-compliance.adoc +++ b/sources/requirements/core/REQ_ogc-compliance.adoc @@ -1,4 +1,3 @@ -[[req_ogc-compliance]] [requirement] ==== diff --git a/sources/requirements/core/REQ_standardization-goal.adoc b/sources/requirements/core/REQ_standardization-goal.adoc index ad37f77..8629d9a 100644 --- a/sources/requirements/core/REQ_standardization-goal.adoc +++ b/sources/requirements/core/REQ_standardization-goal.adoc @@ -1,4 +1,3 @@ -[[req_standardization-goal]] [requirement] ==== diff --git a/sources/requirements/core/REQ_standardization-target-type.adoc b/sources/requirements/core/REQ_standardization-target-type.adoc index ed6a75f..691ab2f 100644 --- a/sources/requirements/core/REQ_standardization-target-type.adoc +++ b/sources/requirements/core/REQ_standardization-target-type.adoc @@ -1,4 +1,3 @@ -[[req_standardization-target-type]] [requirement] ==== diff --git a/sources/requirements/requirement001.adoc b/sources/requirements/requirement001.adoc index 6780341..85dbe2f 100644 --- a/sources/requirements/requirement001.adoc +++ b/sources/requirements/requirement001.adoc @@ -1,4 +1,3 @@ -[[req_class_a_name_1]] [requirement] ==== diff --git a/sources/requirements/requirement002.adoc b/sources/requirements/requirement002.adoc index fc5c7c7..71ef974 100644 --- a/sources/requirements/requirement002.adoc +++ b/sources/requirements/requirement002.adoc @@ -1,4 +1,3 @@ -[[req_class_a_name_2]] [requirement] ==== diff --git a/sources/requirements/requirements_class.adoc b/sources/requirements/requirements_class.adoc index cbb3da3..fa9bf2b 100644 --- a/sources/requirements/requirements_class.adoc +++ b/sources/requirements/requirements_class.adoc @@ -1,4 +1,3 @@ -[[req_class_a]] [requirements_class] .Requirements Class 'A' diff --git a/sources/requirements/requirements_class_core.adoc b/sources/requirements/requirements_class_core.adoc index 405290e..7c5e4e0 100644 --- a/sources/requirements/requirements_class_core.adoc +++ b/sources/requirements/requirements_class_core.adoc @@ -1,4 +1,3 @@ -[[req_class-core]] [requirements_class] .Requirements Class 'Core' ==== @@ -35,4 +34,3 @@ requirement:: /req/core/req-class-overlap-by-reference requirement:: /req/core/reqs-are-in-class ==== - diff --git a/sources/sections/00-foreword.adoc b/sources/sections/00-foreword.adoc index a3822d9..63cab59 100644 --- a/sources/sections/00-foreword.adoc +++ b/sources/sections/00-foreword.adoc @@ -1,12 +1,14 @@ -[.preface] -== Foreword +[abstract] +== Abstract -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 requirements class and +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 requirements class and the conformance test class, <> and the Conformance Test Suite <>). The first version of the ModSpec was approved by the OGC Membership in 2009. There have been no revisions to the ModSpec since then. This revision is based -on suggestions and issues raised since 2009. A complete list of revisions, other than fixes to spelling and grammatical errors can be found in the +on suggestions and issues raised since 2009. A complete list of revisions, other than fixes to spelling and grammatical errors can be found in the ModSpec Version 1.1 Release Notes [OGC 25-003]. _Attention is drawn to the possibility that some of the elements of this document may diff --git a/sources/sections/00-preface.adoc b/sources/sections/00-preface.adoc index 5d1023b..43f18f8 100644 --- a/sources/sections/00-preface.adoc +++ b/sources/sections/00-preface.adoc @@ -1,64 +1,38 @@ [.preface] == Preface -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 -consistent and verifiable testing of implementations of a standard that claim conformance. The ModSpec is a meta-standard: -A standard specifying requirements for crafting and documenting modular and testable standards. +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 +consistent and verifiable testing of implementations of a standard that claim conformance. The ModSpec is a meta-standard: +A standard specifying requirements for crafting and documenting modular and testable standards. The goals of using the ModSpec are: -- To define characteristics and a structure for the development of modular standards which will minimize the difficulty in writing testable standards while maximizing usability and interoperability. -- To ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable. +* To define characteristics and a structure for the development of modular standards which will minimize the difficulty in writing testable standards while maximizing usability and interoperability. +* To ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable. NOTE: Historically, this document has been known and abbreviated as the "ModSpec". For continuity and ease of understanding this document is also be referred to as the "OGC ModSpec". Suggested additions, changes, and comments on this document are welcome and -encouraged. Such suggestions may be submitted by creating an issue in the +encouraged. Such suggestions may be submitted by creating an issue in the OGC ModSpec GitHub repository (https://github.com/opengeospatial/ogc-modspec). -[.preface] -== 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. +== Submitters -[.preface] -== Document editors +The following OGC Members contributed and particpated in developing the ModSpec Version 1.1. -The following OGC Members participated in editing this document: +All questions regarding this submission should be directed to the editor or the +submitters: -[%unnumbered] -|=== -^h| Person ^h| Organization Represented -| Carl Reed | Carl Reed & Associates -| Chuck Heazel | Charles Heazel |=== +|Name |Affiliation -[.preface] -== Document Contributors - -The following OGC Members contributed and particpated in developing the ModSpec Version 1.1 - -[%unnumbered] -|=== -^h| Person ^h| Organization Represented | Carl Reed | Carl Reed & Associates | Chuck Heazel | Heazeltech | Jeff Yutzler | ImageMatters/Tema -|=== - -[.preface] -== Submitting organizations -The following OGC Members support the ModSpec Version 1.1 submission - -[%unnumbered] - -- Carl Reed & Associates -- Heazeltech -- ImageMatters/Tema -- UK Met Office +|=== [.preface] @@ -69,10 +43,10 @@ This is the second normative version of this document. [.preface] == Future work -This version of the ModSpec restructures the document into a multi-part standard. This document is Part 1 - Core. +This version of the ModSpec restructures the document into a multi-part standard. This document is Part 1 - Core. It provides a technology agnostic model for modular standards. Future "parts" will be specific for different technologies. Planned extensions include: -- ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL. -- ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using JSON. +* ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL. +* ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using JSON. -In addition, improvements to this document will be made based on implementation and changing technical requirements. +In addition, improvements to this document will be made based on implementation and changing technical requirements. diff --git a/sources/sections/01-scope.adoc b/sources/sections/01-scope.adoc index c086479..a0bfd42 100644 --- a/sources/sections/01-scope.adoc +++ b/sources/sections/01-scope.adoc @@ -1,13 +1,13 @@ [[cls-1]] == Scope -This OGC Standard for Designing and Writing Modular Standards, also known as the `ModSpec`: +This OGC Standard for Designing and Writing Modular Standards, also known as the "`ModSpec`": -- Specifies rules for the internal structure and organization of a standard. -- Defines requirements for specifying the structure of a standards document as organized sets of criteria, those that are to be tested ("requirements") and those that are not tested ("recommendations" and "permissions"). -- 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. +* Specifies rules for the internal structure and organization of a standard. +* Defines requirements for specifying the structure of a standards document as organized sets of criteria, those that are to be tested ("requirements") and those that are not tested ("recommendations" and "permissions"). +* 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 modular and testable 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 ultimate goal of this approach is to enable interoperable implementations of a standard that can be tested and deemed _conformant_ or not. @@ -19,7 +19,7 @@ The ModSpec standardization target type is `standards`. Reading the <> clause will help in understanding the content and requirements stated in this document. -The <> clause provides a more detailed introduction to the fundamental concepts used in the creation of this document. +The <> clause provides a more detailed introduction to the fundamental concepts used in the creation of this document. <> of this Standard defines the UML model upon which the ModSpec is based. Annex C also contains informal and non-normative definitions ordered for ease @@ -32,12 +32,12 @@ NOTE: Please note that the ModSpec has been approved by the OGC Membership as a Version 1.1 of the ModSpec is split into a Core standard and multiple Parts. These are: -- Part 1 - Core: contains all the core requirements and informational text that define the model and internal structure of a standard. -- Part 2: UML Model requirements -- Part 3: XML and Schematron Model requirements +* Part 1 - Core: contains all the core requirements and informational text that define the model and internal structure of a standard. +* Part 2: UML Model requirements +* Part 3: XML and Schematron Model requirements Future Parts to the ModSpec Standard may include: -- Part 4: RDF/OWL requirements -- Part 5: JSON Schema +* Part 4: RDF/OWL requirements +* Part 5: JSON Schema diff --git a/sources/sections/02-conformance.adoc b/sources/sections/02-conformance.adoc index 0779a7d..45cef4b 100644 --- a/sources/sections/02-conformance.adoc +++ b/sources/sections/02-conformance.adoc @@ -1,7 +1,7 @@ [[cls-2]] == Conformance -Conformance to the ModSpec by a standard +Conformance to the ModSpec by a standard can be tested by inspection. The test suite is provided in <>. Part 1: Core of the ModSpec (this document) defines one requirements class and one related conformance class: @@ -12,8 +12,10 @@ The ModSpec contains normative language and thus places requirements on conformance, or mechanism for adoption, of candidate standards to which the ModSpec applies. In particular: -* <> specifies the core requirements which shall be met by all +* xref:https://www.opengis.net/spec/modspec-1/1.1/req/req-class-core[] +specifies the core requirements which shall be met by all standards claiming conformance to the ModSpec. + * <> gives information on how the ModSpec is to be applied to extensions to the core model for requirements and conformance clauses. diff --git a/sources/sections/03-norm-refs.adoc b/sources/sections/03-norm-refs.adoc index 2e8edbc..3e6798c 100644 --- a/sources/sections/03-norm-refs.adoc +++ b/sources/sections/03-norm-refs.adoc @@ -2,6 +2,8 @@ [bibliography] == Normative references +[.boilerplate] +-- While the ModSpec references UML, SQL, JSON, and XML, and their technical specifications, no requirements are derived from these documents. While this document may be applied to extensions of those standards, conformance to them is the purview @@ -10,13 +12,20 @@ of those standards, not the ModSpec. The following are normative references for this document in the sense that they supplied definitions used in this document. -* [[[iso10000-1,ISO/IEC 10000-1:1998]]] https://www.iso.org/standard/30726.html[Information technology — Framework and taxonomy of International Standardized Profiles Part 1: General principles and documentation framework] +// The following documents are referred to in the text in such a way that some or +// all of their content constitutes requirements of this document. For dated +// references, only the edition cited applies. For undated references, the latest +// edition of the referenced document (including any amendments) applies. +-- -* [[[iso-dp2,ISO/IEC DIR 2]]], available at https://www.iso.org/sites/directives/current/part2/index.xhtml[ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards] - -* [[[iso19105:2022,ISO 19105:2022]]], Geographic information — Conformance and testing - -* [[[ogc-modspec,OGC 08-131r3]]], https://portal.ogc.org/files/?artifact_id=34762[The Specification Model — A Standard for Modular specifications Version 1] +// TODO: remove, already in bibliography +// * [[[iso10000,ISO/IEC 10000-1:1998]]] https://www.iso.org/standard/30726.htmlInformation technology — Framework and taxonomy of International Standardized Profiles Part 1: General principles and documentation framework +// TODO: move to bibliography +* [[[iso-dp2,ISO/IEC DIR 2]]], available at https://www.iso.org/sites/directives/current/part2/index.xhtml +ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards +* [[[iso19105:2022,ISO 19105:2022]]], Geographic information — Conformance and testing +* [[[ogc-modspec,OGC 08-131r3]]], https://portal.ogc.org/files/?artifact_id=34762 +The Specification Model — A Standard for Modular specifications Version 1 diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc index 88254e4..06737b3 100644 --- a/sources/sections/04-terms-and-defs.adoc +++ b/sources/sections/04-terms-and-defs.adoc @@ -1,315 +1,328 @@ [[cls-4]] -== Terms and definitions by category +== Terms, definitions and abbreviated terms [.boilerplate] +-- +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 document and OGC documents do not use the equivalent phrases in the ISO/IEC +Directives, Part 2. -For the purposes of this document, the following terms and definitions shall apply. -Terms not defined here take their meaning from computer science or from their -Standard English (common US and UK) meanings. The form of the definitions is -defined by ISO Directives. +Many of these definitions depend upon the model given in <> of this +document. -Many of these definitions depend upon the model given in <>. +For the purposes of this document, the following additional terms and +definitions apply. +-- -=== Building Blocks Terms and Definitions +=== Terms and definitions -[[buildingblock-definition]] +==== Terms related to building blocks -==== building block (foundation) +===== building block (foundation) -<> or <> with no direct dependencies on other requirements classes or packages and their associated <> or <> +{{requirements class}} or {{requirements package}} with no direct dependencies on other requirements classes or packages and their associated {{conformance test class}} or {{conformance package}} -[[dependency-definition]] -==== dependency +===== dependency -module (the target) which is used by, produced by, or associated with an implementation of the source module +module (the target) which is used by, produced by, or associated with an implementation of the source module -[[directdependency-definition]] -==== direct dependency +===== direct dependency another requirements class (the dependency) whose requirements are defined to also be requirements of this requirements class -NOTE: A direct dependency (of a requirements class) of the current requirements class will have the same standardization target as the current requirements class. This is another ways of saying that the current requirements class extends, or uses all the aspects of the direct dependency (or a requirements class). Any tests associated with this dependency can be applied to this requirements class. +NOTE: A direct dependency (of a requirements class) of the current requirements class will have the same standardization target as the current requirements class. This is another ways of saying that the current requirements class extends, or uses all the aspects of the direct dependency (or a requirements class). Any tests associated with this dependency can be applied to this requirements class. -NOTE: When testing a direct dependency of a requirements class, the standardization target is directly subject to the test in the specified conformance test class of the direct dependency of a requirements class. +NOTE: When testing a direct dependency of a requirements class, the standardization target is directly subject to the test in the specified conformance test class of the direct dependency of a requirements class. -[[extension-definition]] -==== extension +===== extension -requirements class which has a direct dependency on another requirements class +requirements class which has a direct dependency on another requirements class -NOTE: Here an extension of a requirements class is defined in the model on requirements class so that their implementation -may be software extensions in a manner analogous to the extension relation between the requirements classes. +NOTE: Here an extension of a requirements class is defined in the model on requirements class so that their implementation +may be software extensions in a manner analogous to the extension relation between the requirements classes. -[[indirectdependency-definition]] -==== indirect dependency +===== indirect dependency -requirements class with a different standardization target which is used by, produced by, or associated with the implementation of this requirements class +requirements class with a different standardization target which is used by, produced by, or associated with the implementation of this requirements class -NOTE: In this instance, as opposed to the direct dependency of a requirements class, the test against the consumable or product used or produced by the requirements class does not directly test the requirements class, but tests only its side effects. Hence, a particular type of feature service could be required to produce valid XML documents, but the test of validity for the XML document is not directly testing the service, but only indirectly testing the validity of its output. Direct dependencies test the same standardization target, but indirect dependencies test related but different standardization targets. + -For example, if a DRM-enabled service is required to have an association to a licensing service, then the requirements of a licensing service are indirect requirements for the DRM-enabled service. Such a requirement may be stated as the associated licensing service has a certificate of conformance of a particular kind. +[NOTE] +-- +In this instance, as opposed to the direct dependency of a requirements class, the test against the consumable or product used or produced by the requirements class does not directly test the requirements class, but tests only its side effects. Hence, a particular type of feature service could be required to produce valid XML documents, but the test of validity for the XML document is not directly testing the service, but only indirectly testing the validity of its output. Direct dependencies test the same standardization target, but indirect dependencies test related but different standardization targets. -[[module-definition]] +For example, if a DRM-enabled service is required to have an association to a licensing service, then the requirements of a licensing service are indirect requirements for the DRM-enabled service. Such a requirement may be stated as the associated licensing service has a certificate of conformance of a particular kind. +-- -==== module + +===== module each of a set of standardized parts or independent units that can be used to construct a more complex structure -NOTE: The concept ‘module’ is key to the ModSpec structure and model. Modules have a direct relationship to the concept of building blocks. -The power of the concept is that modules can be reused in different systems (specify once, use many). Modules can be imported from other programs. -Modules can be replaced without affecting the rest of the system. +NOTE: The concept "module" is key to the ModSpec structure and model. Modules have a direct relationship to the concept of building blocks. +The power of the concept is that modules can be reused in different systems (specify once, use many). Modules can be imported from other programs. +Modules can be replaced without affecting the rest of the system. -[[package-definition]] -==== package +===== package -general-purpose mechanism for organizing elements into groups. +general-purpose mechanism for organizing elements into groups -NOTE: This definition is conceptually consistent with both UML `package` and ISO TC 211 `package` and `requirements suite` definitions. +NOTE: This definition is conceptually consistent with both UML "package" and ISO TC 211 "package" and "requirements suite" definitions. -SOURCE: Rumbaugh J, Jacobson I, Booch G, The Unified Modeling Language Reference Manual 1999 +[.source] +<> -[[part-document-definition]] -==== part (standard) +===== part +domain:[standard] document which is one of the many documents which make up a multi-part standard. -NOTE: A multi-part standard is physically structured into a `core` and additional parts where each part is a separate document. These parts may be extensions to the core or have a different standardization target type/subtype. +NOTE: A multi-part standard is physically structured into a "core" and additional parts where each part is a separate document. These parts may be extensions to the core or have a different standardization target type/subtype. -[[part-requirement-definition]] -==== part (requirement) +===== part +domain:[requirement] -normative statement which together with other normative statements constitute a requirement. +normative statement which together with other normative statements constitute a +{{requirement}} -NOTE: The requirement parts are co-dependent. +NOTE: The requirement parts are co-dependent. -[[profile-definition]] -==== profile +===== profile -specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. +specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. -NOTE: In the usage of the ModSpec, a profile is a set of requirements classes or conformance classes (either preexisting or locally defined) of the base standards. +[NOTE] +-- +In the usage of the ModSpec, a profile is a set of requirements classes or conformance classes (either preexisting or locally defined) of the base standards. This means that a standardization target being conformant to a profile implies that the same target is conformant to the standards referenced in the profile. +-- + +[.source] +<> -SOURCE: ISO/IEC TR 10000-1 -=== Document Terms and Definitions +==== Terms related to document -[[bestpractice-definition]] -==== best practice +===== best practice -<> that has been approved by a legitimate Standards Body as a recommendation for implementation. +{{specification}} that has been approved by a legitimate Standards Body as a +recommendation for implementation. -[[certificateofconformance-definition]] -==== certificate of conformance +===== certificate of conformance -evidence of conformance to all or part of a standard, awarded for passing one or more of the conformance test classes specified in that standard +evidence of conformance to all or part of a standard, awarded for passing one or +more of the conformance test classes specified in that standard -NOTE: Certificates do not have to be instantiated documents. Having proof of passing the conformance test class is sufficient. For example, the OGC currently keeps an online list of conformant applications at http://www.opengeospatial.org/resource/products. +NOTE: Certificates do not have to be instantiated documents. Having proof of passing the conformance test class is sufficient. For example, the OGC currently keeps an online list of conformant applications at http://www.opengeospatial.org/resource/products. Each certificate of conformance is awarded to a standardization target. -[[informativestatement-definition]] -==== informative statement +===== informative statement expression in a document conveying non-normative information -NOTE: Includes all statements in a document not part of the normative requirements, recommendations, permissions, or conformance tests. Included for completeness. +NOTE: Includes all statements in a document not part of the normative requirements, recommendations, permissions, or {{conformance test,conformance tests}}. Included for completeness. -[[normativestatement-definition]] -==== normative statement +===== normative statement expression in a document conveying information required to define conformance -NOTE: Includes all normative statements in a document including requirements, recommendations, permissions, and conformance tests. Included for completeness. +NOTE: Includes all normative statements in a document including requirements, recommendations, permissions, and {{conformance test,conformance tests}}. Included for completeness. -[[specification-definition]] -==== specification +===== specification -document containing recommendations, requirements, permissions, and conformance tests +document containing recommendations, requirements, permissions, and {{conformance test,conformance tests}} -NOTE: This definition is included for completeness. +NOTE: This definition is included for completeness. -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. +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]] -==== standard +===== standard -<> that has been approved by a legitimate Standards Body +{{specification}} that has been approved by a legitimate Standards Body -NOTE: This definition is included for completeness. Standard and specification can apply to the same document. While specification is always valid, standard only applies after the adoption of the document by a legitimate standards organization. +NOTE: This definition is included for completeness. Standard and specification can apply to the same document. While specification is always valid, standard only applies after the adoption of the document by a legitimate standards organization. -NOTE: A standard should consist primarily of Normative Statements. The goal should be for the standard to be concise. Supporting information can be provided through a user's guide. +NOTE: A standard should consist primarily of Normative Statements. The goal should be for the standard to be concise. Supporting information can be provided through a user's guide. -[[statement-definition]] -==== statement +===== statement -expression in a document conveying information +expression in a document conveying information -[[usersguide-definition]] -==== users guide +===== users guide -non-normative information that assists in understanding a standard but is not required to implement the standard. +non-normative information that assists in understanding a standard but is not required to implement the standard. -=== Core Terms and Definitions +==== Terms related to core -[[conformanceclass-definition]] -==== conformance class + -conformance test class +===== conformance class +alt:[conformance test class] -set of <> that must be passed to receive a single <> +set of {{conformance test,conformance tests}} that must be passed to receive a single {{certificate of conformance}} -[[conformancepackage-definition]] -==== conformance package +===== conformance package -set (grouping) of related conformance classes and their associated components. +set (grouping) of related conformance classes and their associated components. -[[conformancesuite-definition]] -==== conformance suite +===== conformance suite -set of <> and/or <> that define <> for all <> of a <> +set of {{conformance class,conformance classes}} and/or {{conformance +package,conformance packages}} that define {{conformance test,conformance +tests}} for all {{requirement,requirements}} of a {{standard}} -NOTE: The *conformance suite* is the union of all *conformance classes* and their associated <>. It is by definition the *conformance class* of the entire *standard* or *abstract specification*. +NOTE: The *conformance suite* is the union of all *conformance classes* and +their associated {{conformance class,conformance classes}}. It is by definition +the *conformance class* of the entire *standard* or *abstract specification*. -[[conformancetest-definition]] -==== conformance test +===== conformance test -test, abstract or real, of one or more <> contained within a standard, or set of standards +test, abstract or real, of one or more {{requirement,requirements}} contained within a standard, or set of standards -[[conformancetestmethod-definition]] -==== conformance test method +===== conformance test method -process used to test an implementation of the standard for conformance. +process used to test an implementation of the standard for conformance. NOTE: Testing may be automated, manual, or a hybrid. NOTE: Testing by an independent second party is recommended. -[[corerequirementsclass-definition]] -==== core requirements class +===== core requirements class unique requirements class that must be satisfied by any conformant standardization targets associated with the standard -NOTE: The core requirements class is unique because if it were possible to have more than one, then each core would have to be implemented to pass any conformance test class, and thus would have to be contained in any other core. The core may be empty, or all or part of another standard or related set of standards. +NOTE: The core requirements class is unique because if it were possible to have more than one, then each core would have to be implemented to pass any conformance test class, and thus would have to be contained in any other core. The core may be empty, or all or part of another standard or related set of standards. -NOTE: The core can refer to this requirements class, its associated conformance test class, or the software module that implements that requirements class. +NOTE: The core can refer to this requirements class, its associated conformance test class, or the software module that implements that requirements class. -[[model-definition]] -==== model +===== model representation of those aspects of the standardization target type which are to be governed by a standard. The model captures both the conceptual and logical properties of the standardization target type. The requirements promulgated by a standard should be expressed in terms of those conceptual and logical properties. -In short, the model provides the vocabulary for expressing requirements. +In short, the model provides the vocabulary for expressing requirements. -[[permission-definition]] -==== permission +===== permission -expression, in the content of a <>, that conveys consent or liberty (or opportunity) to do something +expression, in the content of a {{standard}}, that conveys consent or liberty (or opportunity) to do something -SOURCE: ISO Directives Part 2 +[.source] +<> -NOTE:: uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more of a “statement of fact” rather than a “normative” condition. +NOTE: uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more of a “statement of fact” rather than a “normative” condition. -[[recommendation-definition]] -==== recommendation +===== recommendation -expression, in the content of a <>, that conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others. +expression, in the content of a {{standard}}, that conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others. -NOTE:: In the negative form, a recommendation is the expression that a suggested possible choice or course of action is not preferred but it is not prohibited. +NOTE: In the negative form, a recommendation is the expression that a suggested possible choice or course of action is not preferred but it is not prohibited. -SOURCE: ISO Directives Part 2 +[.source] +<> -NOTE: Although using normative language, a recommendation is not a requirement. The usual form replaces the `shall` (imperative or command) of a requirement with a `should` (suggestive or conditional). +NOTE: Although using normative language, a recommendation is not a requirement. The usual form replaces the "shall" (imperative or command) of a requirement with a "should" (suggestive or conditional). -NOTE: Recommendations are not tested and therefore have no related conformance test. +NOTE: Recommendations are not tested and therefore have no related conformance test. -[[requirement-definition]] -==== requirement +===== requirement -expression, in the content of a <>, that conveys objectively verifiable criteria to be fulfilled and +expression, in the content of a {{standard}}, that conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed. -SOURCE: ISO Directives Part 2 +[.source] +<> -NOTE: Each requirement is a normative criterion for a single type of <>. -In the ModSpec, requirements are associated to <> that can be used to prove compliance -to the underlying criteria by the standardization target. The implementation of a requirement is dependent on the type of standard -being written. A data standard requires data structures, but a procedural standard requires software implementations. The view of +NOTE: Each requirement is a normative criterion for a single type of {{standardization target}}. +In the ModSpec, requirements are associated to {{conformance test,conformance tests}} that can be used to prove compliance +to the underlying criteria by the standardization target. The implementation of a requirement is dependent on the type of standard +being written. A data standard requires data structures, but a procedural standard requires software implementations. The view of a standard in terms of a set of testable requirements supports using set descriptions of both the standard and its implementations. -The specification of a requirement is usually expressed in terms of a model of the standardization target type, such as a UML model, -or an XML, JSON or SQL schema. Anything without a defined test is a-priori not testable and thus would be better expressed as a recommendation. -Requirements use normative language and in particular are commands and use the imperative "shall" or similar imperative constructs. Statements in -standards which are not requirements and need to be either conditional or future tense normally use "will" and should not be confused -with requirements that use "shall" imperatively +The specification of a requirement is usually expressed in terms of a model of the standardization target type, such as a UML model, +or an XML, JSON or SQL schema. Anything without a defined test is a-priori not testable and thus would be better expressed as a recommendation. +Requirements use normative language and in particular are commands and use the imperative "shall" or similar imperative constructs. Statements in +standards which are not requirements and need to be either conditional or future tense normally use "will" and should not be confused +with requirements that use "shall" imperatively. -[[requirementsclass-definition]] -==== requirements class +===== requirements class -aggregate of <> with a single <> that must all be satisfied to pass a <>. +aggregate of {{requirement,requirements}} with a single {{standardization target type}} that +must all be satisfied to pass a {{conformance test class}}. -NOTE: There is some confusion possible here, since the testing of <> seems -to violate this definition. But the existence of an indirect dependency implies that the test is actually a test of the existence -of the relationship from the original target to something that has a property (satisfies a condition or requirement from another requirements class). +NOTE: There is some confusion possible here, since the testing of {{indirect +dependency,indirect dependencies}} seems to violate this definition. But the +existence of an indirect dependency implies that the test is actually a test of +the existence of the relationship from the original target to something that has +a property (satisfies a condition or requirement from another requirements +class). -[[requirementspackage-definition]] -==== requirements package +===== requirements package -set (grouping) of related requirement classes and their associated components. +set (grouping) of related requirement classes and their associated components. -[[standardizationgoal-definition]] -==== standardization goal +===== standardization goal -concise statement of the problem that the standard helps address and the strategy envisioned for achieving a solution. +concise statement of the problem that the standard helps address and the strategy envisioned for achieving a solution. -NOTE: This strategy typically identifies real-world entities that need to be modified or constrained. At the abstract level, those entities are the <>. +NOTE: This strategy typically identifies real-world entities that need to be modified or constrained. At the abstract level, those entities are the {{standardization target type,standardization target types}}. -[[standardizationtarget-definition]] -==== standardization target +===== standardization target -entity to which some <> of a <> apply +entity to which some {{requirement,requirements}} of a {{standard}} apply -NOTE: The standardization target is the entity which may receive a certificate of conformance for a requirements class. +NOTE: The standardization target is the entity which may receive a certificate of conformance for a requirements class. -[[standardizationtargettype-definition]] -==== standardization target type +===== standardization target type -type of entity or set of entities to which the <> of a <> apply +type of entity or set of entities to which the {{requirement}} of a {{standard}} apply -NOTE: For example, the standardization target type for The OGC API – Features Standard are Web APIs. The standardization target type for the CDB Standard is “datastore”. It is important to understand that a standard’s root standardization target type can have sub-types, and that there can be a hierarchy of target types. For example, a Web API can have sub types of client, server, security, and so forth. As such, each requirements class can have a standardization target type that is a sub-type of the root. +NOTE: For example, the standardization target type for The OGC API – Features Standard are Web APIs. The standardization target type for the CDB Standard is “datastore”. It is important to understand that a standard’s root standardization target type can have sub-types, and that there can be a hierarchy of target types. For example, a Web API can have sub types of client, server, security, and so forth. As such, each requirements class can have a standardization target type that is a sub-type of the root. -[[will-definition]] -==== will +===== will In informative sections, the word "will" implies that something is an implication of a requirement. The "will" statements are not requirements, but explain the consequence of requirements. + +==== Abbreviated terms + +In this document the following abbreviations and acronyms are used or introduced: + +ERA:: Entity, Relation, Attribute (pre-object modeling technique) +ISO:: International Organization for Standardization (from Greek for "same") +OGC:: Open Geospatial Consortium (http://www.opengeospatial.org/) +SQL:: ISO/IEC 9075 query language for relational databases, not originally an acronym, but now often cited as "Structured Query Language" +TC:: Technical Committee (usually either in ISO or OGC) +UML:: Unified Modeling Language (an object modeling language) +XML:: eXtensible Markup Language +OMG:: Object Management Group (http://www.omg.org/) diff --git a/sources/sections/05-conventions.adoc b/sources/sections/05-conventions.adoc index 9af05f8..301e268 100644 --- a/sources/sections/05-conventions.adoc +++ b/sources/sections/05-conventions.adoc @@ -13,49 +13,37 @@ 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.1/ +identifier:[https://www.opengis.net/spec/modspec-1/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.1/ +identifier:[https://www.opengis.net/spec/modspec-1/1.1/] An example might be: -/req/core/crs +identifier:[/req/core/crs] All conformance tests 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 “conf” in a requirement URI denotes: -https://www.opengis.net/spec/modspec-1/1.1/ +identifier:[https://www.opengis.net/spec/modspec-1/1.1/] -The same convention is used for permissions (per) and recommendations (rec). +The same convention is used for permissions (`per`) and recommendations (`rec`). -=== Abbreviations - -In this document the following abbreviations and acronyms are used or introduced: - -ERA:: Entity, Relation, Attribute (pre-object modeling technique) -ISO:: International Organization for Standardization (from Greek for "same") -OGC:: Open Geospatial Consortium (http://www.opengeospatial.org/) -SQL:: ISO/IEC 9075 query language for relational databases, not originally an acronym, but now often cited as "Structured Query Language" -TC:: Technical Committee (usually either in ISO or OGC) -UML:: Unified Modeling Language (an object modeling language) -XML:: eXtensible Markup Language -OMG:: Object Management Group (http://www.omg.org/) [[cls-6-3]] === Finding requirements and recommendations Each normative statement in the ModSpec is stated in one and only one place, -in a standard format, with a unique label, such as REQ001, REC001, or PER001. A requirement, recommendation, or permission may be repeated for clarification. -The statement with the unique label is considered the official statement of the normative requirement or recommendation. +in a standard format, with a unique label, such as REQ001, REC001, or PER001. A requirement, recommendation, or permission may be repeated for clarification. +The statement with the unique label is considered the official statement of the normative requirement or recommendation. In this document, all requirements are associated with tests specified in the test suite in <>. The reference to the requirement in the conformance test is done by a -requirements label and/or unique identifier. Recommendations and permissions are not tested although +requirements label and/or unique identifier. Recommendations and permissions are not tested although they should still be documented using a standard template and have unique labels and/or identifiers. Requirements classes are separated into their own clauses and named and specified diff --git a/sources/sections/06-fundamentals.adoc b/sources/sections/06-fundamentals.adoc index 4e6af18..374c8ed 100644 --- a/sources/sections/06-fundamentals.adoc +++ b/sources/sections/06-fundamentals.adoc @@ -20,10 +20,10 @@ These characteristics are slightly modified from the Open Group definitions to a === Standardization Context - Goals, Target Types, and Targets -Every standards document should include a Standardization Goal. This is a concise statement of the problem that the -standard helps address and the strategy envisioned for achieving a solution. This strategy typically identifies real-world -entities that need to be modified or constrained. At the abstract level, those entities are the Standardization Target Types. -These are the classes of entities to be standardized. A Standard defines the requirements levied on one or more Standardization Target Types. +Every standards document should include a Standardization Goal. This is a concise statement of the problem that the +standard helps address and the strategy envisioned for achieving a solution. This strategy typically identifies real-world +entities that need to be modified or constrained. At the abstract level, those entities are the Standardization Target Types. +These are the classes of entities to be standardized. A Standard defines the requirements levied on one or more Standardization Target Types. Instances of a Standardization Target Type are the Standardization Targets. These are the real-world manifestations of the Standardization Target Type. In summary: @@ -45,8 +45,8 @@ The following are two examples of Target Types and Targets as used in the OGC AP .. Standardization target type: JSON documents (or JSON objects) .. Standardization target: Any JSON document (or object) that implements the Core requirements class of JSON-FG. The document can be a created by an API as a response document representing a features collection or by a tool like GDAL, FME, QGIS, etc. -The Standardization Target Types, Standardization Targets, and Standardization Goal provide a well-defined context for the standard. -This will help users of standards to quickly understand the scope of a standard and to select those standards appropriate for their needs. +The Standardization Target Types, Standardization Targets, and Standardization Goal provide a well-defined context for the standard. +This will help users of standards to quickly understand the scope of a standard and to select those standards appropriate for their needs. It also will help keep standards developers focused on the intended use of their standards, avoiding standards which are overly broad and/or unfocused. === Conformance, Requirements, and key information @@ -64,12 +64,15 @@ Conformance tests are aggregated into conformance classes that specify how certa the requirements. The issue that blocks this approach is that some requirements are optional while others are mandatory. To achieve a cleaner separation of requirements, the ModSpec separates them into sets (called "requirements classes"), each of which -has no optional components. Since the normative statement of each requirement is only +has no optional components. Since the normative statement of each requirement is only declared once and is uniquely identified as such, each requirement will be in a clause associated to its requirements class. -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 -<>). 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. +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 {{conformance class}}). 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. @@ -90,18 +93,20 @@ single requirements class but included in others by reference to its "home" requirements class). In the ModSpec, each conformance requirement is separated in its own labeled -paragraph, such as seen in <> below. +paragraph, such as seen in xref:/req/core/reqs-are-testable[] below. The distribution of the information in a standard is not restricted. The only requirement is that requirements be grouped in a manner -consistent with the conformance test classes, see <> and <>. +consistent with the conformance test classes, see +xref:/req/core/requirements-grouped[] and +xref:/req/core/requirements-test-suite-structure[]. === Documenting the Standard -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. +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 +NOTE: OGC Standards are written using an OGC Member approved template that is conformant with the requirements stated in the ModSpec. This template should be specified by the following descriptions: @@ -113,7 +118,7 @@ logical type of Clause), one of which is the Conformance Test Suite (which may b abstract description of the test suites to be implemented separately). In OGC Documents, this is Annex A – Abstract Test Suite. . All requirements, recommendations, permissions, and models are introduced and defined first in the numbered Clauses. -. All requirements are identifiable as requirements. +. All requirements are identifiable as requirements. . All requirements in a document are uniquely numbered and/or labeled. . All tests for conformance to those requirements are defined in the Conformance Test Suite. . Tests are grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test packages. @@ -126,7 +131,5 @@ does not do this, it is has by default only one "conformance class". . Examples and notes are informative, and do not use "normative" language. -A UML representation of important properties of this model is given in <>. - - +A UML representation of important properties of this model is given in <>. diff --git a/sources/sections/06-req-class.adoc b/sources/sections/06-req-class.adoc index c788221..60757e8 100644 --- a/sources/sections/06-req-class.adoc +++ b/sources/sections/06-req-class.adoc @@ -2,9 +2,9 @@ == ModSpec Requirements Class: Core -This clause specifies the requirements, recommendations, and permissions for the content and structure of a modular standard. -This collection of requirements, recommendations, and permissions are also known as the `core` of the ModSpec. -All the requirements specified in this ModSpec core comprise the ModSpec Core Requirements Class. +This clause specifies the requirements, recommendations, and permissions for the content and structure of a modular standard. +This collection of requirements, recommendations, and permissions are also known as the `core` of the ModSpec. +All the requirements specified in this ModSpec core comprise the ModSpec Core Requirements Class. include::../requirements/requirements_class_core.adoc[] @@ -18,28 +18,26 @@ The following requirement states that every requirement in a standards document |*Requirement 28* |/req/core/reqs-are-in-class + Each requirement in a standard SHALL be associated with exactly one requirements class. -|=== +|=== //// Temporarily remove until metanorma numering issue fixed include::../requirements/core/REQ028_reqs-are-in-class.adoc[] //// -There may be one or more requirements in a requirements class. +There may be one or more requirements in a requirements class. The following requirement states that every requirement is testable. -[[req-1]] include::../requirements/core/REQ001_testable.adoc[] Therefore, by definition, any requirements class that contains the requirement that failed to pass also fails to pass. The following requirement states that every component of a standard will have a unique identifier -[[req-2]] include::../requirements/core/REQ002_assigned-uri.adoc[] -The following recommendation encourages the consistent use of these unique identifiers/labels in the standard +The following recommendation encourages the consistent use of these unique identifiers/labels in the standard as well as any external documentation referencing that standard. [[rec-1]] @@ -56,7 +54,6 @@ include::../permissions/core/PER001_informational-content.adoc[] The following states how and where vocabularies are specified in relation to a requirements class. -[[req-3]] include::../requirements/core/REQ3_vocabulary.adoc[] @@ -88,11 +85,10 @@ The assumption is that each standard has a single (root) standardization target type from which all extensions inherit. If this is not true, then the standard can be logically factored into parts each corresponding to a "root" standardization target type, and that the standard addresses each -such part separately (see the definition of -<>). In this sense, the next requirement divides the +such part separately (see the definition of +{{requirements class}}). In this sense, the next requirement divides the standard into parts more than restricting their content. -[[req-4]] include::../requirements/core/REQ4_single-standardization-target-type.adoc[] In practice, the standardization target type of the core requirements class is the root @@ -100,12 +96,11 @@ of an inheritance tree where extensions all have the core's target type as an an and thus can be considered as belonging to the same "class" or type as the core's target type. -[[req-5]] include::../requirements/core/REQ5_test-class-single-standardization-target.adoc[] This means that all requirements are considered as targeting the same entity being tested for a particular certificate of conformance. The test may specify other types -as intermediaries or indirect dependencies (see <> of-a-requirements-class). +as intermediaries or indirect dependencies (see {{indirect dependency}} of-a-requirements-class). include::../permissions/core/PER003_repeated-requirements.adoc[] @@ -118,7 +113,7 @@ targets types (except in some special circumstances), they will have different conformance test classes. One solution is to state the requirement twice, once for each target. An -alternative is to introduce a new "superclass". +alternative is to introduce a new "superclass". include::../permissions/core/PER004_abstract-superclass.adoc[] @@ -131,16 +126,14 @@ image::../images/img01.png[] [[cls-8-3]] === The "standards" document -Each standards document is comprised of a set of requirements and their associated conformance tests. +Each standards document is comprised of a set of requirements and their associated conformance tests. Requirements are grouped into requirements classes. Each requirements class is contained within one section/clause in a standards document. -[[req-6]] include::../requirements/core/REQ6_requirements-grouped.adoc[] -The following requirement states that the sequence of requirements and requirements classes +The following requirement states that the sequence of requirements and requirements classes is the same as the sequence of conformance tests and conformance classes in the conformance suite. -[[req-7]] include::../requirements/core/REQ7_requirements-test-suite-structure.adoc[] If two requirements are in the same requirements class, they should be tested in the same conformance @@ -167,7 +160,6 @@ performed to pass conformance, but it specifies no requirements in any other sen The requirements are specified in the body of the standard. The test suite only describes in detail how those requirements should be tested. -[[req-8]] include::../requirements/core/REQ8_requirements-correspondence.adoc[] Strict parallelism of implementation and governance is the essence of this standard. @@ -178,7 +170,6 @@ Strict parallelism of implementation and governance is the essence of this stand [[cls-6-5-1]] The following states that each conformance class tests a complete requirements class -[[req-9]] include::../requirements/core/REQ9_no-optional-tests.adoc[] This requirement stops @@ -192,7 +183,7 @@ include::../permissions/core/PER005_conf-class-paramterized.adoc[] This means that the class's tests depend on some parameter that must be defined before the tests can be executed. This can -be thought of as an "if-then-else" decision tree. +be thought of as an "if-then-else" decision tree. For example, if a conformance class needs to apply tests against a specific data format, such as GML or KML, then XYZ(GML) is XYZ using GML, and XYZ(KML) is XYZ using KML. @@ -205,12 +196,10 @@ if a service uses or produces feature data, the format of that data may be a parameter, such as GML, KML or GeoJSON. When reading a certificate of conformance, the values of such parameters are very important. -[[req-10]] include::../requirements/core/REQ10_all-parameters-expressed.adoc[] Conformance to a particular conformance class means exactly the same thing everywhere. -[[req-11]] include::../requirements/core/REQ11_conf-class-single-req-class.adoc[] This means that there is a strict correspondence between the requirements classes @@ -218,7 +207,6 @@ and the conformance test classes in the test suite. Recall that a conformance te class may specify dependencies causing other conformance test classes to be used, but this is a result of an explicit requirement in the "home" requirements class. -[[req-12]] include::../requirements/core/REQ12_con-class-dependencies.adoc[] Such referenced conformance classes may be in the same standard or may be a @@ -232,27 +220,26 @@ compliant to a particular profile of GML, then that profile of GML will be used validate that output. This means that the service is indirectly tested using the GML standard. In other words, GML is an indirect dependency of the original service. -Requirements classes may be optional as a whole, but not piecemeal. This means that -every implementation that passed a particular conformance class satisfies exactly -the same requirements and passes exactly the same conformance tests. Differences -between implementations will be determined by which conformance test classes are -passed, not by a listing of which options within a class were tested. If a -standard's authors wish to make a particular requirement optional, <> -forces them to include it in a separate requirements class (and therefore in a -separate conformance test class) which can be left untested. +Requirements classes may be optional as a whole, but not piecemeal. This means +that every implementation that passed a particular conformance class satisfies +exactly the same requirements and passes exactly the same conformance tests. +Differences between implementations will be determined by which conformance test +classes are passed, not by a listing of which options within a class were +tested. If a standard's authors wish to make a particular requirement optional, +xref:/req/core/no-optional-tests[] forces them to include it in a separate +requirements class (and therefore in a separate conformance test class) which +can be left untested. NOTE: Standards developed outside the OGC may not follow a strict parallelism between requirement specification and testing, so for use within a standard compliant to the ModSpec, special care must be taken in importing conformance test classes from other standards. -[[req-13]] include::../requirements/core/REQ13_imported-requirements-class.adoc[] The tracking of the parallelism between requirements and tests should be easy if the standards document is non-ambiguous. To ensure this, by utilizing the names of the two types of classes, the following requirement places a default mapping between the two. -[[req-14]] include::../requirements/core/REQ14_all-classes-explicitly-named.adoc[] Logically, a requirements class (set of requirements) and a conformance class (set @@ -265,7 +252,6 @@ both are related (as described) to the same set of requirements. [[cls-6-5-2]] The following states that requirements classes contain all requirements tested by a conformance test case -[[req-15]] include::../requirements/core/REQ15_conf-class-test-req-class.adoc[] Unless a requirement is referenced in a conformance test and thus in a conformance @@ -274,24 +260,23 @@ class, it cannot be considered a requirement since no test has been defined for [[rec-2]] include::../recommendations/core/REC002-parallel-structure.adoc[] -The above requirement in conjunction with <> means that all requirements in a conformant -standard will be tested in some conformance class. In the best example, a -requirement should be contained explicitly in one and only one requirements class -and tested in one and only one conformance class. This is not really a requirement -here, since a single requirement can be stated twice in different requirements -classes with different standardization target types. +The above requirement in conjunction with xref:/req/core/no-optional-tests[] +means that all requirements in a conformant standard will be tested in some +conformance class. In the best example, a requirement should be contained +explicitly in one and only one requirements class and tested in one and only one +conformance class. This is not really a requirement here, since a single +requirement can be stated twice in different requirements classes with different +standardization target types. -[[req-16]] include::../requirements/core/REQ16_co-dependent-requirements.adoc[] Normally, circular dependencies between implementation components are signs of a poor design, but they often cannot be avoided because of other considerations (code -ownership for example). +ownership for example). [[rec-3]] include::../recommendations/core/REC003-circular-dependencies.adoc[] -[[req-17]] include::../requirements/core/REQ17_structure-requirements-classes.adoc[] NOTE: The only certain manner to test this requirement maybe to create a reference implementation. @@ -306,7 +291,6 @@ the software requirements classes are properly separated, they can be implemente a plug and play fashion. -[[req-18]] include::../requirements/core/REQ18_requirements-and-dependencies.adoc[] This means, for example, that a UML classifier cannot be redefined in a new @@ -332,7 +316,6 @@ of all conformance classes) for defining profiles as defined in ISO/IEC 10000 (s <>). The base for creating a profile can be defined as the union of all requirements classes. -[[req-19]] include::../requirements/core/REQ19_profile-conformance.adoc[] [[cls-6-5-4]] @@ -340,17 +323,14 @@ include::../requirements/core/REQ19_profile-conformance.adoc[] The following requirements define the content of the core. -[[req-20]] include::../requirements/core/REQ20_core-requirements-separate.adoc[] The following states that any recommendations applicable to the entire standard are in the core document. -[[req-21]] include::../requirements/core/REQ21_general-recommendations-core.adoc[] The following states that all non-core requirements classes have a standardization target type that is a sub-type of the core. -[[req-22]] include::../requirements/core/REQ22_req-class-not-core-stt-subtype-of-core.adoc[] The following recommendation is guidance to the group developing a standard to keep the core as simple as possible. @@ -363,7 +343,7 @@ Typically, an abstract standard cannot be directly implemented. include::../permissions/core/PER006_core-type.adoc[] -The following enables the ability of the standard being developed and then implemented to reference, as normative, conformance classes from another standard. +The following enables the ability of the standard being developed and then implemented to reference, as normative, conformance classes from another standard. An example in the OGC would be OGC API - Records Standard core referencing conformance classes defined in the OGC API - Common Standard. By definition these externally defined conformance classes need to be passed in order to claim compliance. @@ -374,7 +354,7 @@ include::../recommendations/core/REC005-optional-tests.adoc[] Since the core requirements class is contained (as a direct dependency) in each other requirements class with a similar standardization target type, the general -recommendations are thus universal to all requirements classes. +recommendations are thus universal to all requirements classes. include::../permissions/core/PER008_core-maybe-recommendations.adoc[] @@ -388,14 +368,12 @@ Features." === Extensions are requirements classes A common mechanism to extend the functionality of a standard is to define -extensions, which may be either local or encompass other standards. +extensions, which may be either local or encompass other standards. Standards should use extensions as required and feasible, but should never hinder them. -[[req-23]] include::../requirements/core/REQ23_core-and-extensions.adoc[] -[[req-24]] include::../requirements/core/REQ24_extensions-conformant-to-modspec.adoc[] Since software is evolutionary at its best, it would not be wise to restrict that @@ -404,7 +382,6 @@ good standard will thus list the things a standardization target has to do, but will never list things that a standardization target might want to do above and beyond the current design requirements. -[[req-25]] include::../requirements/core/REQ25_restriction-of-extensions.adoc[] The above requirement should not be interpreted as a restriction on quality @@ -422,7 +399,6 @@ the fundamental intent of the standard. [[cls-6-5-6]] === Optional requirements are organized as optional requirements classes -[[req-26]] include::../requirements/core/REQ26_optional-requirements.adoc[] A standard and implementations of that standard are restricted by this requirement. @@ -433,14 +409,13 @@ are considered to be options and should be in a separate requirements class. [[cls-6-5-7]] ==== Requirements classes intersect overlap only by reference -[[req-27]] include::../requirements/core/REQ27_req-class-overlap-by-reference.adoc[] This implies that each requirement is directly in exactly one requirements class and all references to that requirement from another requirements class must include its -complete "home" requirements class. This means that requirements for dependencies will often result in +complete "home" requirements class. This means that requirements for dependencies will often result in conformance test cases which require the execution of the dependency conformance class. For example, -using the ModSpec as an example: An implementation passing the UML conformance test class _SHALL_ first +using the ModSpec as an example: An implementation passing the UML conformance test class _SHALL_ first pass the ModSpec core conformance test class. NOTE: All general recommendations are in the core requirements class. The core diff --git a/sources/sections/07-mapping.adoc b/sources/sections/07-mapping.adoc index 2fff99d..13bd955 100644 --- a/sources/sections/07-mapping.adoc +++ b/sources/sections/07-mapping.adoc @@ -13,14 +13,14 @@ alternate mechanism. Standards are often structured and documented using some form of modeling language, or implementation paradigm. Additional Parts to the ModSpec -define a mechanism to map parts of the model (language, schema, etc.) to the conformance classes +define a mechanism to map parts of the model (language, schema, etc.) to the conformance classes used in the ModSpec model as defined in the core ModSpec Requirements Class. -As suggested in Clause <>, the structure of the normative clauses in a -standard should parallel the structure of the conformance test classes in -that standard. The structure of the normative clauses in a well written -standard will follow the structure of its model. This means that all three are -parallel. +As suggested in xref:/req/core/req-class-not-core-stt-subtype-of-core[], the +structure of the normative clauses in a standard should parallel the structure +of the conformance test classes in that standard. The structure of the normative +clauses in a well written standard will follow the structure of its model. This +means that all three are parallel. === A Note on Data Models diff --git a/sources/sections/aa-abstract-conformance.adoc b/sources/sections/aa-abstract-conformance.adoc index c5cf5a5..ffb41cb 100644 --- a/sources/sections/aa-abstract-conformance.adoc +++ b/sources/sections/aa-abstract-conformance.adoc @@ -7,116 +7,59 @@ include::../abstract_tests/ATS_class_core.adoc[] -==== Requirements are testable - include::../abstract_tests/core/ATS1_testable.adoc[] -==== All components have an assigned URI - include::../abstract_tests/core/ATS2_assigned-uri.adoc[] -==== Requirements on vocabulary are appropriately placed - include::../abstract_tests/core/ATS3_vocabulary.adoc[] -==== Requirements have a single target type - include::../abstract_tests/core/ATS4_single-standardization-target-type.adoc[] -==== Conformance test classes have a single target type - include::../abstract_tests/core/ATS5_test-class-single-standardization-target.adoc[] -==== Requirements are organized by clauses - include::../abstract_tests/core/ATS6_requirements-grouped.adoc[] -==== Conformance test classes are consistent with requirements classes - include::../abstract_tests/core/ATS7_requirements-test-suite-structure.adoc[] -==== Requirement classes and the Conformance Test classes in correspondence - include::../abstract_tests/core/ATS8_requirements-correspondence.adoc[] -==== No Optional Elements in Requirements classes - include::../abstract_tests/core/ATS9_no-optional-tests.adoc[] -==== Certificate of conformance specifies all parameters used - include::../abstract_tests/core/ATS10_all-parameters-expressed.adoc[] -==== Conformance class tests only one requirements class - include::../abstract_tests/core/ATS11_conf-class-single-req-class.adoc[] -==== Conformance class specifies all dependencies - include::../abstract_tests/core/ATS12_con-class-dependencies.adoc[] -==== Imported Conformance class tests are consistent with the specification - include::../abstract_tests/core/ATS13_imported-requirements-class.adoc[] -==== Naming consistency - include::../abstract_tests/core/ATS14_all-classes-explicitly-named.adoc[] -==== Requirements in one and only one requirements class - include::../abstract_tests/core/ATS15_req-in-only-one-req-class.adoc[] -==== Co-dependent Requirements are in the same requirements class - include::../abstract_tests/core/ATS16_co-dependent-requirements.adoc[] -==== Modularity in implementation is possible - include::../abstract_tests/core/ATS17_structure-requirements-classes.adoc[] -==== Requirements follow rules of inheritance - include::../abstract_tests/core/ATS18_requirements-and-dependencies.adoc[] -==== Profiles are expressed as sets of conformance classes - include::../abstract_tests/core/ATS19_profile-conformance.adoc[] -==== There is a named Core requirements class - include::../abstract_tests/core/ATS20_core-requirements-separate.adoc[] -==== General conditions are in the core - include::../abstract_tests/core/ATS21_general-recommendations-core.adoc[] -==== Every extension has a consistent target type - include::../abstract_tests/core/ATS22_req-class-not-core-stt-subtype-of-core.adoc[] -==== A standard is a core plus some number of extensions - include::../abstract_tests/core/ATS23_core-and-extensions.adoc[] -==== Conformance to this ModSpec is required for any extensions - include::../abstract_tests/core/ATS24_extensions-conformant-to-modspec.adoc[] -==== Future extensions cannot be restricted - include::../abstract_tests/core/ATS25_restriction-of-extensions.adoc[] -==== Optional requirements are organized as requirements classes - include::../abstract_tests/core/ATS26_optional-requirements.adoc[] -==== Requirements classes intersect overlap only by reference - include::../abstract_tests/core/ATS27_req-class-overlap-by-reference.adoc[] -==== Requirements are in class - include::../abstract_tests/core/ATS28_reqs-are-in-class.adoc[] - diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc index a115581..52db75e 100644 --- a/sources/sections/ac-definitions.adoc +++ b/sources/sections/ac-definitions.adoc @@ -4,61 +4,63 @@ === Semantically ordered definitions -<> formally defines the terms used in the conformance tests in alphabetical +<> formally defines the terms used in the conformance tests in alphabetical order. It may be easier to understand the more significant terms in the following less formal definitions arranged in a bottom-up order: -. a <> is a type of entity about which a standard -is written. An instance of a <> is a -<>. A standard may address multiple targets in separate -<>. +. a {{standardization target type}} is a type of entity about which a standard +is written. An instance of a {{standardization target type}} is a +{{standardization target}}. A standard may address multiple targets in separate +{{conformance class,conformance classes}}. -. a <> is a statement of a condition to be satisfied by a single -<>, and it must be stated in "normative" language. +. a {{requirement}} is a statement of a condition to be satisfied by a single +{{standardization target type}}, and it must be stated in "normative" language. -. a <> checks if a -<> including its parts are met (*pass*) or not met (*fail*) by a -<>. +. a {{conformance test}} checks if a +{{requirement}} including its parts are met (*pass*) or not met (*fail*) by a +{{standardization target}}. -. all <> are graded as *pass* or *fail* -against each instance of the <>. +. all {{conformance test,conformance tests}} are graded as *pass* or *fail* +against each instance of the {{standardization target type}}. -. a <> is associated to one <>. +. a {{requirement}} is associated to one {{conformance test}}. -. a <> is a suggestion and is not associated to any -<>. +. a {{recommendation}} is a suggestion and is not associated to any +{{conformance test}}. -. a <> is a set of one or more <> -all with the same <>. +. a {{requirements class}} is a set of one or more {{requirement,requirements}} +all with the same {{standardization target type}}. -. a <> is a collection of -<> that are associated to and only to the -requirements in a corresponding <>. +. a {{conformance class}} (conformance test class) is a collection of +{{conformance test,conformance tests}} that are associated to and only to the +requirements in a corresponding {{requirements class}}. -. a <> is a reusable collection of related <>. +. a {{conformance package}} (conformance test package) is a reusable collection +of related {{conformance class,conformance classes}}. -. a *conformant implementation* is a <> that has -successfully passed all tests in a specified <> and received a <>. +. a *conformant implementation* is a {{standardization target}} that has +successfully passed all tests in a specified {{conformance class}} and received +a {{certificate of conformance}}. -. the <> of a standard is the minimal set of -<> which must be supported by all *conformant -implementations*. If a standard addresses multiple <>, it may have a *core* for each *target +. the {{core requirements class}} of a standard is the minimal set of +{{requirement,requirements}} which must be supported by all *conformant +implementations*. If a standard addresses multiple {{standardization target +type,standardization target types}}, it may have a *core* for each *target type*. -. an *extension* of a <> is an additional <> -(the extension) that adds additional <> to the first -<> (the *base requirements class* being extended). The -extension is said to be dependent on the *base*. Any <> +. an *extension* of a {{requirements class}} is an additional {{requirements class}} +(the extension) that adds additional {{requirement,requirements}} to the first +{{requirements class}} (the *base requirements class* being extended). The +extension is said to be dependent on the *base*. Any {{conformance class}} must identify all its dependencies during the execution of conformance tests -against a candidate <>. +against a candidate {{standardization target}}. [[annex-C-2]] === UML Model [[fig-C-1]] - image::img02.png[] -<> represents a UML model consistent with the model described -in <> of this document. +<> represents a UML model consistent with the model described +in <> of this document. diff --git a/sources/sections/ad-bibliography.adoc b/sources/sections/ad-bibliography.adoc index a426618..cbac59d 100644 --- a/sources/sections/ad-bibliography.adoc +++ b/sources/sections/ad-bibliography.adoc @@ -1,11 +1,6 @@ -[[annex-D]] [bibliography] == Bibliography -To preserve a unique numeric identifier for all documents listed as references in -this standard, the numbering of references in this annex is continued from the list -of normative reference in <>. - * [[[iso9075,ISO/IEC 9075:2003]]], ISO/IEC JTC 1, ISO/IEC 9075:2003 -- Information Technology -- Database Languages - SQL. * [[[iso13249-3,ISO/IEC 13249-3:2006]]] @@ -14,6 +9,17 @@ of normative reference in <>. * [[[w3c-xml-part2,W3C xmlschema11-2]]], XML Schema 1.1 Part 2: Datatypes, April 2012, available from W3C at http://www.w3.org/TR/xmlschema11-2/ -* [[[iso10000,ISO/IEC TR 10000]]], ISO/IEC TR 10000: Information Technology -- Framework and taxonomy of International Standardized Profiles +* [[[iso10000,ISO/IEC TR 10000-1]]], ISO/IEC TR 10000-2: Information Technology -- Framework and taxonomy of International Standardized Profiles + +* [[[dict_computing,1(isbn:9780199234004)]]] + +// span:surname[Pyle] span:initials[I. C.] +// span:title[Dictionary of Computing] +// span:edition[4] +// span:publisher[Oxford University Press]. +// span:place[Oxford, UK] +// Current edition 8th 2008 + +* [[[uml_manual,1(isbn:9780201309980)]]] -* Pyle, I. C., Dictionary of Computing, 4th Edition, Oxford: Oxford University Press. Current edition 8th 2008 +// SOURCE: Rumbaugh J, Jacobson I, Booch G, The Unified Modeling Language Reference Manual 1999