From f882be0ec298febb2805a78d91d19c95716940c9 Mon Sep 17 00:00:00 2001 From: "C. Reed" Date: Fri, 13 Dec 2024 12:00:36 -0700 Subject: [PATCH 01/43] Remove redundent clauses that are now in fundamentals --- sources/sections/01-scope.adoc | 60 +++------------------------------- 1 file changed, 4 insertions(+), 56 deletions(-) diff --git a/sources/sections/01-scope.adoc b/sources/sections/01-scope.adoc index 78d67f6..ba30c42 100644 --- a/sources/sections/01-scope.adoc +++ b/sources/sections/01-scope.adoc @@ -43,44 +43,12 @@ A standard that follows the rules specified in the ModSpec presents requirements There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the https://docs.ogc.org/is/19-072/19-072.html[OGC API - Common Part 1: Core Standard] and in the https://github.com/opengeospatial/cdbswg/blob/master/cdb-2.0/cdb-core-crs-requirements-class.adoc[CDB 2.0 Standard CRS Requirements Module]. By formally implementing the requirements specified in the ModSpec, reusable, modular standards can be developed. -==== The ModSpec and the "Form" of a standard - -NOTE: This content is duplicated in fundamentals - -NOTE: For OGC Standards, the assumptions is that documents are in a commonly used -logical form (template). - -This form should be specified by the following descriptions: - -. A standards document contains Clauses (corresponding to numbered sections as they might -appear in a table of contents) which describe its standardization target and its requirements. -. A standard contains Annexes or is associated to other documents (both a -logical type of Clause), one of which is the Conformance Test Suite (which may be an -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 in a document are uniquely numbered. -. All tests for conformance to those requirements are defined in the Conformance Test Suite. -. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules. -. The tests, if conducted, determine to some degree of certainty whether an -implementation meets the requirements which the tests reference. -. The tests are organized into some number of conformance "classes" where each conformance class has a one to one relationship with a requirements class. If a standard -does not do this, it is has by default only one "conformance class". -. Certificates of conformance (see <>) are -awarded by a testing entity based on these conformance classes. -. There is a clear distinction between normative and informative parts of the text. -. Examples and notes are informative, and do not use "normative" -language. +NOTE: The approach modelled in the ModSpec has been referred to as the "core and extension model" due to its +insistence on a modular structure throughout all parts of a standard and its implementation. 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. -The ModSpec defines a "requirement" of a standard as an atomic testable -criterion. See the formal definition of requirement in <> - -A UML representation of important properties of this model is given in <>. - ==== ModSpec document structure Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are: @@ -91,26 +59,6 @@ Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. The Future Parts to the ModSpec Standard may include: -- Part 5: RDF/OWL requirements - -==== Building Blocks - -NOTE: This content is covered in Fundamentals. +- Part 3: RDF/OWL requirements +- Part 4: JSON Schema -In software development technology, there is a concept called _building block_. In software development, building blocks are used to support the software build process where source code files/libraries can be accessed from multiple sources, converted into executable code, and linked together in the proper order until a complete set of executable files is generated. The same concept can be applied to OGC Standards development: Requirements classes and/or modules can be linked together from one or more standards to create a new standard not originally envisioned when the requirements were originally defined. - -The https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap32.html[Open Group] suggests that building blocks have the following characteristics: - -. A building block is a package of functionality defined to meet business or domain needs. -. A building block may interoperate with other, inter-dependent, building blocks. -. A good building block has the following characteristics: -.. Considers implementation and usage, and evolves to exploit technology and standards. -.. May be assembled from other building blocks. -.. May be a subassembly of other building blocks. -.. Ideally a building block is re-usable and replaceable, and well specified. -. A building block may have multiple implementations but with different inter-dependent building blocks. - -These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work. - -NOTE: The approach modelled in the ModSpec has been referred to as the "core and extension model" due to its -insistence on a modular structure throughout all parts of a standard and its implementation. From 251fe6769ec9f9f3efba1d03be10292ffad8b558 Mon Sep 17 00:00:00 2001 From: "C. Reed" Date: Fri, 13 Dec 2024 12:03:37 -0700 Subject: [PATCH 02/43] Shorten for Part 2 --- sources/part2/00-preface.adoc | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/sources/part2/00-preface.adoc b/sources/part2/00-preface.adoc index a665a42..4955daa 100644 --- a/sources/part2/00-preface.adoc +++ b/sources/part2/00-preface.adoc @@ -31,7 +31,7 @@ The following OGC Members participated in editing this document: |=== ^h| Person ^h| Organization Represented | Carl Reed | Carl Reed & Associates -| Chuck Heazel | Heazeltech +| John Herring | Oracle |=== [.preface] @@ -48,26 +48,6 @@ The following OGC Members contributed and particpated in developing Version 2 of | Jeff Yutzler | ImageMatters |=== -[.preface] -== Acknowledgements - -The following OGC Members were key contributors to Version 1 of the ModSpec - -[%unnumbered] -|=== -^h| Person ^h| Organization Represented -| Simon Cox | CSIRO -| David Danko | ESRI -| James Greenwood | SeiCorp, Inc. -| John R. Herring | Oracle USA -| Andreas Matheus | University of the Bundeswehr -- ITS -| Richard Pearsall | US National Geospatial-Intelligence Agency (NGA) -| Clemens Portele | interactive instruments GmbH -| Barry Reff | US Department of Homeland Security (DHS) -| Paul Scarponcini | Bentley Systems, Inc. -| Arliss Whiteside | BAE Systems - C3I Systems -|=== - [.preface] == Revision history From b57ba2c2fc19d213b5b421f6be0a2477ed8d14bf Mon Sep 17 00:00:00 2001 From: "C. Reed" Date: Fri, 13 Dec 2024 14:18:29 -0700 Subject: [PATCH 03/43] Delete sources/document.err.html --- sources/document.err.html | 1403 ------------------------------------- 1 file changed, 1403 deletions(-) delete mode 100644 sources/document.err.html diff --git a/sources/document.err.html b/sources/document.err.html deleted file mode 100644 index 8f9b8dd..0000000 --- a/sources/document.err.html +++ /dev/null @@ -1,1403 +0,0 @@ -./document.err.html errors - - -

./document.err.html errors

-

AsciiDoc Input

- - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
_moduleterm reference not in expected format:​Cambridge Dictionary
#<Asciidoctor::Block@582420 {context: :paragraph, content_model: :simple, style: nil, lines: 1}>
1
000585_20a6a496-83c5-47c0-8f2d-7e5da3da99c8Error: Term reference to conformance-tests missing: "conformance-tests" is not defined in document -
<refterm>conformance tests</refterm>
1
000859_7679502b-736a-4fe7-b8c0-d0d0fb3525adError: Term reference to requirements missing: "requirements" is not defined in document -
<refterm>requirements</refterm>
1
000874_2f719dcc-01b6-42c2-9af5-38b6cd165491Error: Term reference to requirement-class missing: "requirement-class" is not defined in document -
<refterm>requirement class</refterm>
1
003177_e6034837-6d6f-42e9-863b-f16b711cf0b8Error: Term reference to conformance-test-classes missing: "conformance-test-classes" is not defined in document -
<refterm>conformance test classes</refterm>
1
-

Anchors

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
000123_98dba55f-513e-396f-31a4-f8b75c176929Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000141_33fd6022-bfb3-74da-0b67-ed92735b6984Crossreference target Annex-B is undefined
<xref target="Annex-B"/>
1
000277_18d5c15f-e17f-7bab-5940-615e16e6cf3dCrossreference target annex-B-2 is undefined
<xref target="annex-B-2"/>
1
000343_0571d906-4b96-4bd7-b6ac-49811ab9028fCrossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000364_c4293c1d-7706-525f-19ee-a1736f47d61dCrossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000375_2888779d-9df0-c76b-e036-a6f2df607f40Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000508_24a00bc9-3781-2e6c-bbae-ae9e108a1c5eCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
001093_ee968187-ef65-ded4-d8c0-b58d2c04bb6bCrossreference target annex-B-2 is undefined
<xref target="annex-B-2"/>
1
001377_f44d3819-58e4-4af9-92b6-2b1f510c9983normalised identifier in ​ from term-indirect-dependency-(of-a-requirements-class)
<xref target="term-indirect-dependency-_of-a-requirements-class_"/>
2
001883_bb9616d0-bb2a-d054-cc18-50af6930264eCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
003204_c61630e4-cc0b-6003-6593-fb89389ef95dCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
-

Style

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
--Abstract is missing!
2
--Keywords are missing!
2
--Submitters is missing!
2
000047_ed57b9c2-82df-23fc-12d0-57ad12904248Table should have title
<table id="_ed57b9c2-82df-23fc-12d0-57ad12904248" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
-<th valign="middle" align="center">Organization Represented</th>
-</tr> <tr> <td valign="middle" align="left">Carl Reed</td>
-<td valign="middle" align="left">Carl Reed &amp; Associates</td>
-</tr> <tr> <td valign="middle" align="left">Chuck Heazel</td>
2
000061_efd73240-fcac-8f47-ef08-891532957519Table should have title
<table id="_efd73240-fcac-8f47-ef08-891532957519" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
-<th valign="middle" align="center">Organization Represented</th>
-</tr> <tr> <td valign="middle" align="left">Simon Cox</td>
-<td valign="middle" align="left">CSIRO and OGC Fellow</td>
-</tr> <tr> <td valign="middle" align="left">Chuck Heazel</td>
2
000079_6a5f074f-211b-4669-fcde-be09c07472efTable should have title
<table id="_6a5f074f-211b-4669-fcde-be09c07472ef" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
-<th valign="middle" align="center">Organization Represented</th>
-</tr> <tr> <td valign="middle" align="left">Simon Cox</td>
-<td valign="middle" align="left">CSIRO</td>
-</tr> <tr> <td valign="middle" align="left">David Danko</td>
2
000147introduxtionHanging paragraph in clause
<clause id="introduxtion" obligation="normative">
-<title>Introduction</title>
-<note id="_8cf4e52e-4329-70cb-698d-c18f0aa17568"> <p id="_e867988d-2e03-d0cc-133e-2ccb31bdf375">Reading the Terms and Definitions clause and Clause &lt;TBD&gt; will help understanding the content and
-requirements stated in this document.</p>
-</note>
2
000948_​conventionsHanging paragraph in clause
<clause id="_conventions" obligation="normative">
-<title>Conventions</title>
-<clause id="_symbols_and_abbreviated_terms" obligation="normative">
-<title>Symbols (and abbreviated terms)</title>
-<p id="_ee09a638-5ac9-58aa-094f-73806db6e2f3">All symbols used in this document are either:</p>
2
001229_​requirements_class_​coreHanging paragraph in clause
<clause id="_requirements_class_core" obligation="normative">
-<title>Requirements Class: Core</title>
-<p id="_ced39dde-b4ce-fb73-acd8-f98f615573c3">The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the <tt>core</tt> of the ModSpec.</p>
-
-<table id="req-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ001</strong> </td>
2
001233req-1Table should have title
<table id="req-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ001</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/reqs-are-testable</strong> <br/>
-All the parts of a requirement, a requirements module, or requirements class <em>SHALL</em> be
-testable. Failure to pass any part of any requirement shall be a failure to pass the
-associated conformance test class.</td>
2
001245req-2Table should have title
<table id="req-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ002</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/all-components-assigned-uri</strong> <br/>
-Each component of the standard, including requirements, requirements modules,
-requirements classes, conformance test cases, conformance modules and conformance
-classes <em>SHALL</em> be assigned a URI.
2
001258rec-1Table should have title
<table id="rec-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC001</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uri-external-use</strong> <br/>
-These URI identities <em>SHOULD</em> be used in any external documentation that reference
-these component elements in a normative manner, including but not limited to other
-standards, implementations of the conformance test suite, or certificates of
2
001272per-1Table should have title
<table id="per-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER001</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/informational-content-in-core</strong> <br/>
-The informational and structural universals of the standard <em>MAY</em> be included in the
-core text and its associated models without violations of the ModSpec. This is
-true if the requirements of the extension are not implicit in what is
2
001286per-2Table should have title
<table id="per-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER002</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/core-may-contain-schema-terms</strong> <br/>
-The core <em>MAY</em> contain the definition and schema of commonly used terms and data
-structures for use in other structures throughout the standard.</td>
-</tr> </tbody>
2
001293per-3Table should have title
<table id="per-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER003</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/core-names-of-operations</strong> <br/>
-This may include the list of the names of all operations and operation parameters
-to be used in any request-response pairs defined in any conformance class of the
-standard. If a service receives a request that is not supported in its
2
001305req-3Table should have title
<table id="req-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ003</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/vocabulary-and-parent-req-class</strong> <br/>
-Requirements on the use and interpretation of vocabulary <em>SHALL</em> be in the
-requirements class where that use or interpretation is used.</td>
-</tr> </tbody>
2
001312per-4Table should have title
<table id="per-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER004</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/external-vocabs-core</strong> <br/>
-Importation of external vocabularies and schemas <em>MAY</em> be in the core.</td>
-</tr> </tbody>
-</table>
2
001355req-4Table should have title
<table id="req-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ004</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/single-standardization-target</strong> <br/>
-Each requirement in a conformant standard <em>SHALL</em> have a single standardization
-target type.</td>
-</tr> </tbody>
2
001367req-5Table should have title
<table id="req-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ005</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/modspec/test-class-single-standardization-target</strong> <br/>
-All conformance tests in a single conformance test class in a conformant
-standard <em>SHALL</em> have the same standardization target.</td>
-</tr> </tbody>
2
001379per-5Table should have title
<table id="per-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER005</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/repeated-requirements</strong> <br/>
-If needed, a requirement <em>MAY</em> be repeated word for word in another requirement up
-to but not including the identification of the standardization target type.</td>
-</tr> </tbody>
2
001397per-6Table should have title
<table id="per-6" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER006</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/abstract-superclass</strong> <br/>
-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. This is
-diagrammed in <xref target="fig-6-1"/>.</td>
2
001418req-6Table should have title
<table id="req-6" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ006</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-grouped</strong> <br/>
-Requirements SHALL be grouped together in clauses (numbered sections) of the
-document in a strictly hierarchical manner, consistent with
-requirements classes.</td>
2
001426req-7Table should have title
<table id="req-7" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ007</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-test-suite-structure</strong> <br/>
-The requirements structure of the document SHALL be in a logical correspondence to
-the test suite structure.</td>
-</tr> </tbody>
2
001463req-8Table should have title
<table id="req-8" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ008</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-class-correspondence-to-conformance-classes</strong> <br/>
-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.</td>
-</tr> </tbody>
2
001477req-9Table should have title
<table id="req-9" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ009</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/no-optional-tests</strong> <br/>
-A Conformance class SHALL not contain any optional conformance tests.</td>
-</tr> </tbody>
-</table>
2
001490per-7Table should have title
<table id="per-7" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER007</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/conf-class-paramterized</strong> <br/>
-A Conformance class may be parameterized.</td>
-</tr> </tbody>
-</table>
2
001511req-10Table should have title
<table id="req-10" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ010</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/all-parameters-expressed</strong> <br/>
-A certificate of conformance SHALL specify all parameter values used to pass the
-tests in its conformance test class.</td>
-</tr> </tbody>
2
001520req-11Table should have title
<table id="req-11" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ011</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/conf-class-single-req-class</strong> <br/>
-A Conformance class SHALL explicitly test only requirements from a single
-requirements class.</td>
-</tr> </tbody>
2
001532req-12Table should have title
<table id="req-12" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ012</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/con-class-dependencies</strong> <br/>
-A Conformance class SHALL specify any other conformance class upon which it is
-dependent and that other conformance class shall be used to test the specified
-dependency.</td>
2
001568req-13Table should have title
<table id="req-13" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ013</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/imported-requirements-class</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">If a requirements class is imported from another standard for use within a
-standard conformant to the ModSpec, and if any imported requirement is
2
001585req-14Table should have title
<table id="req-14" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ014</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/all-classes-explicitly-named</strong> <br/>
-For the sake of consistency and readability, all requirements classes and all
-conformance test classes <em>SHALL</em> be explicitly named, with corresponding requirements
-classes and conformance test classes having similar names.</td>
2
001602req-15Table should have title
<table id="req-15" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ015</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/req-in-only-one-rec-class</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">Each requirement in the standard <em>SHALL</em> be contained in one and only one
-requirements class.</td>
2
001617rec-2Table should have title
<table id="rec-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC002</strong> </td>
-<td valign="middle" align="left"> <strong>/rec/core/parallel-structure</strong> <br/>
-If possible, the structure of the normative clauses of the standard <em>SHOULD</em>
-parallel the structure of the conformance classes in the conformance clause.</td>
-</tr> </tbody>
2
001631req-16Table should have title
<table id="req-16" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ016</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/co-dependent-requirements</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">If any two requirements are co-dependent (each
-dependent on the other) then they shall be in the same requirements class.</td>
2
001646rec-3Table should have title
<table id="rec-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC003</strong> </td>
-<td valign="middle" align="left"> <strong>/rec/core/circular-dependencies</strong> <br/>
-Circular dependencies of all types should be avoided whenever possible.</td>
-</tr> </tbody>
-</table>
2
001652req-17Table should have title
<table id="req-17" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ017</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/structure-requirements-classes</strong> <br/>
-There <em>SHALL</em> 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.</td>
2
001673req-18Table should have title
<table id="req-18" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ018</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/>
-No requirements class <em>SHALL</em> redefine the requirements of its dependencies, unless
-that redefinition is for an entity derived from but not contained in those
-dependencies.#</td>
2
001703req-19Table should have title
<table id="req-19" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ019</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/profile-conformance</strong> <br/>
-The conformance tests for a profile of a standard <em>SHALL</em> be defined as the
-union of a list of conformance classes that are to be satisfied by that profile’s
-standardization targets.</td>
2
001714req-20Table should have title
<table id="req-20" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ020</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/core-requirements-separate</strong> <br/>
-Every standard <em>SHALL</em> define and identify a core set of requirements as a
-separate conformance class.</td>
-</tr> </tbody>
2
001721req-21Table should have title
<table id="req-21" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ021</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/>
-All general recommendations <em>SHALL</em> be in the core.</td>
-</tr> </tbody>
-</table>
2
001727req-22Table should have title
<table id="req-22" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ022</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">Every other requirements class in a standard <em>SHALL</em> a standardization
-target type which is a subtype of that of the core</td>
2
001737rec-4Table should have title
<table id="rec-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC004</strong> </td>
-<td valign="middle" align="left"> <strong>/rec/core/simple-core</strong> <br/>
-The core <em>SHOULD</em> be as simple as possible.</td>
-</tr> </tbody>
-</table>
2
001743per-8Table should have title
<table id="per-8" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER008</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/core-type</strong> <br/>
-The core <em>MAY</em> be partially or totally abstract.</td>
-</tr> </tbody>
-</table>
2
001749per-9Table should have title
<table id="per-9" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER009</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/req-class-another-standard</strong> <br/>
-The core requirements class <em>MAY</em> be a conformance class in another standard.</td>
-</tr> </tbody>
-</table>
2
001755rec-5Table should have title
<table id="rec-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC005</strong> </td>
-<td valign="middle" align="left"> <strong>/rec/core/optional-tests</strong> <br/>
-If a requirements class is from another standard, the current standard <em>SHOULD</em> identify any optional tests
-in that conformance class that are required by the current standard’s core requirements class. See <xref target="req-13"/>.</td>
-</tr> </tbody>
2
001766per-10Table should have title
<table id="per-10" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER010</strong> </td>
-<td valign="middle" align="left"> <strong>/per/core/core-maybe-recommendations</strong> <br/>
-Since the basic concept of some standards is mechanism not implementation, the core <em>MAY</em> contain only
-recommendations, and include no requirements.</td>
-</tr> </tbody>
2
001788req-23Table should have title
<table id="req-23" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ023</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/core-and-extensions</strong> <br/>
-Each standard conformant to the ModSpec <em>SHALL</em> consist of the core and some
-number of requirements classes defined as extensions to that core.</td>
-</tr> </tbody>
2
001795req-24Table should have title
<table id="req-24" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ024</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/extensions-conformant-to-the-modspec</strong> <br/>
-A standard conformant to the ModSpec <em>SHALL</em> require all conformant extensions
-to itself to be conformant to the ModSpec.</td>
-</tr> </tbody>
2
001808req-25Table should have title
<table id="req-25" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ025</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/restriction-of-extensions</strong> <br/>
-A standard conformant to the ModSpec <em>SHALL</em> never restrict in any manner
-future, logically valid extensions of its standardization targets.</td>
-</tr> </tbody>
2
001830req-26Table should have title
<table id="req-26" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ026</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/optional requirements</strong> <br/>
-The only conditional requirements acceptable in a standard conformant with the ModSpec <em>SHALL</em> be expressible as a list of conformance classes to be passed.</td>
-</tr> </tbody>
-<note id="_5afcd57b-b114-e6af-83c5-da5810ad1f34"> <p id="_c7fd3ee9-2839-9469-a0a4-5296b655abde">Standards and implementations are restricted by this, but not instances of
2
001848req-27Table should have title
<table id="req-27" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ027</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/req-class-overlap-by-reference</strong> <br/>
-The common portion of any two requirements classes <em>SHALL</em> consist only of references
-to other requirements classes.</td>
-</tr> </tbody>
2
001921_c7a3c7b9-c356-dda5-8492-9b971b352211Table should have title
<table id="_c7a3c7b9-c356-dda5-8492-9b971b352211" width="90%"> <colgroup> <col width="20%"/> <col width="80%"/> </colgroup> <tbody> <tr> <td colspan="2" valign="middle" align="left"> <strong>Requirements Class — UML extension to the core</strong> </td>
-</tr> <tr> <td colspan="2" valign="middle" align="left">/req/core/data-representation</td>
-</tr> <tr> <td valign="middle" align="left">Target</td>
-<td valign="middle" align="left">ModSpec Conformant UML Model</td>
-</tr> <tr> <td valign="middle" align="left">Dependency</td>
2
001954req-28Table should have title
<table id="req-28" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ028</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/conformance-with-core</strong> <br/>
-An implementation passing the UML conformance test class <em>SHALL</em> first pass the core
-conformance test class</td>
-</tr> </tbody>
2
001970req-29Table should have title
<table id="req-29" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ029</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/object-model</strong> <br/>
-To be conformant to this UML requirements class, UML <em>SHALL</em> be used to express the
-object model, either as the core mechanism of the standard or as a normative adjunct
-to formally explain the standard in a model</td>
2
001978req-30Table should have title
<table id="req-30" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ030</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/dependency-graph</strong> <br/>
-A UML model <em>SHALL</em> have an explicit dependency graph for the leaf packages and
-external packages used by the standard consistent with the way their classifiers use
-those of other packages</td>
2
002000req-31Table should have title
<table id="req-31" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ031</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/leaf-model</strong> <br/>
-A UML leaf package <em>SHALL</em> be associated directly to only one requirements class.</td>
-</tr> </tbody>
-</table>
2
002006req-32Table should have title
<table id="req-32" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ032</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/class-package</strong> <br/>
-Each requirements class shall be associated to a unique package in the model and
-include either directly or by a dependency any requirement associated to any of its
-subpackages.</td>
2
002018req-33Table should have title
<table id="req-33" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ033</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/to-leaf</strong> <br/>
-A requirements class <em>SHALL</em> be associated to some number of complete leaf packages
-and all classes and constraints in those packages.</td>
-</tr> </tbody>
2
002030req-34Table should have title
<table id="req-34" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ034</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/common-req-classe</strong> <br/>
-Classes that are common to all requirements classes <em>SHALL</em> be in a package
-associated to the core requirements class.</td>
-</tr> </tbody>
2
002047req-35Table should have title
<table id="req-35" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ035</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/source-target</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">In the UML model, if a “source” package is dependent on a “target” package then
-their requirements class <em>SHALL</em> be equal or</td>
2
003116annex-BHanging paragraph in clause
<annex id="annex-B" obligation="normative">
-<title>OGC Only: Changes required in the OGC Standards</title>
-<note id="_b37e62e1-9150-ac84-bf8a-eed002ecf6da"> <p id="_26a1a2db-74fd-baf5-c5e0-85ca8d2b73eb">The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards</p>
-</note>
-
2

-
Requirements

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
002065req-36Requirement req-36 has no corresponding Conformance test
-
<requirement id="req-36" model="ogc" type="general"> <description> <p id="_3eca5317-106b-f03e-fbdb-2ee04fe0216a"> <hi>If one leaf package is dependent on another leaf package, then the requirements class of the first <em>SHALL</em> be the same or an extension of the requirements class of the second.</hi> </p> </description>
-</requirement>
2
002068req-37Requirement req-37 has no corresponding Conformance test
-
<requirement id="req-37" model="ogc" type="general"> <description> <p id="_a15d47f2-a15c-4fea-3d3f-86f2536475da"> <hi>If two packages have a two-way dependency (a “co-dependency”), they <em>SHALL</em> be associated to the same requirements class.</hi> </p> </description>
-</requirement>
2
002083req-38Requirement req-38 has no corresponding Conformance test
-
<requirement id="req-38" model="ogc" type="general"> <description> <p id="_5facddbd-f891-892c-861e-f4a48ac43274"> <hi>The UML model <em>SHALL</em> segregate all classes into leaf packages.</hi> </p> </description>
-</requirement>
2
002096req-39Requirement req-39 has no corresponding Conformance test
-
<requirement id="req-39" model="ogc" type="general"> <description> <p id="_e554fa9f-8832-fbb9-169e-c93a151e1b2b"> <hi>An implementation passing the XML schema conformance test class shall first pass the ModSpec core conformance test class.</hi> </p> </description>
-</requirement>
2
002099req-40Requirement req-40 has no corresponding Conformance test
-
<requirement id="req-40" model="ogc" type="general"> <description> <p id="_a4787978-0fbd-8951-3a03-32f34a5b10b4"> <hi>An implementation passing the XML schema conformance test class shall first pass the W3C Recommendation for XML schema.</hi> </p> </description>
-</requirement>
2
002127req-41Requirement req-41 has no corresponding Conformance test
-
<requirement id="req-41" model="ogc" type="general"> <description> <p id="_b83111ee-ce7e-e00d-5923-a180877f057b"> <hi>If a standard conformant to the XML schema conformance class defines a set of data schemas, all components (e.g. elements, attributes, types …​) associated with a single conformance test class shall be scoped to a single XML namespace.</hi> </p> </description>
-</requirement>
2
002130req-42Requirement req-42 has no corresponding Conformance test
-
<requirement id="req-42" model="ogc" type="general"> <description> <p id="_ee155a55-5598-d30c-ba9e-838cc68d8830"> <hi>The all-components schema document for an XML Schema shall indicate the URI of the associated conformance test class in the schema/annotation/appinfo element.</hi> </p> </description>
-</requirement>
2
002146req-43Requirement req-43 has no corresponding Conformance test
-
<requirement id="req-43" model="ogc" type="general"> <description> <p id="_c1e9f905-ffba-9594-3ae6-7805a3cec304"> <hi>If a standard conformant to the XML schema conformance class defines a direct dependency from one requirement class to another, then a standardization target of the corresponding conformance test class shall import a schema that has passed the associated conformance test class (dependency) or shall itself pass the associated conformance test class.</hi> </p> </description>
-</requirement>
2
002164req-44Requirement req-44 has no corresponding Conformance test
-
<requirement id="req-44" model="ogc" type="general"> <description> <p id="_1db32dca-2a3b-f245-6025-f28c0857e986"> <hi>No requirements class in a specification conformant to the XML schema conformance class shall modify elements, types or any other requirement from a namespace to which it is not associated.</hi> </p> </description>
-</requirement>
2
002194req-45Requirement req-45 has no corresponding Conformance test
-
<requirement id="req-45" model="ogc" type="general"> <description> <p id="_d1b4993a-ace1-3a1c-4576-f3ac788f04be"> <hi>A standard passing the Schematron conformance test class shall also define or reference an XML schema that shall pass the XML schema conformance class from this standard.</hi> </p> </description>
-</requirement>
2
002200req-46Requirement req-46 has no corresponding Conformance test
-
<requirement id="req-46" model="ogc" type="general"> <description> <p id="_d4f5631f-f95d-3f9d-b6ec-25b05ee56633"> <hi>Each sch:pattern element shall implement constraints described in no more than one requirement. Each requirement shall be implemented by no more than one sch:pattern.</hi> </p> </description>
-</requirement>
2
002203req-47Requirement req-47 has no corresponding Conformance test
-
<requirement id="req-47" model="ogc" type="general"> <description> <p id="_65f3807e-76dc-93b9-6cf6-c0cfeba8034c"> <hi>Each sch:pattern element shall be contained within one sch:schema element.</hi> </p> </description>
-</requirement>
2
002206req-48Requirement req-48 has no corresponding Conformance test
-
<requirement id="req-48" model="ogc" type="general"> <description> <p id="_71425625-5fcd-7372-9a4b-635f2f3cc439"> <hi>The value of the sch:schema/@fpi attribute shall be a URI that identifies this implementation</hi> </p> </description>
-</requirement>
2
002209req-49Requirement req-49 has no corresponding Conformance test
-
<requirement id="req-49" model="ogc" type="general"> <description> <p id="_ee31488d-0108-d53d-f485-e9ea2913e76d"> <hi>The value of the sch:schema/@see attribute shall be the identifier for the requirements class that contains the requirement(s) implemented by the schema</hi> </p> </description>
-</requirement>
2
002212req-50Requirement req-50 has no corresponding Conformance test
-
<requirement id="req-50" model="ogc" type="general"> <description> <p id="_abdedbe5-08f9-55ac-6792-6ad60c3a1e1b"> <hi>The value of the sch:schema/@fpi attribute shall be used on only one Schematron schema.</hi> </p> </description>
-</requirement>
2
002226req-51Requirement req-51 has no corresponding Conformance test
-
<requirement id="req-51" model="ogc" type="general"> <description> <p id="_3d6dd4b3-18ae-25b5-d894-7e7c701d565b"> <hi>A standard passing the XML meta-schema conformance test class shall first pass the core specification conformance test class.</hi> </p> </description>
-</requirement>
2
002232req-52Requirement req-52 has no corresponding Conformance test
-
<requirement id="req-52" model="ogc" type="general"> <description> <p id="_9b323efa-94af-df98-0f58-8ed1584b7f0c"> <hi>A standard passing the XML meta-schema conformance test class shall require that its specification targets (XML schema) pass the XML schema conformance class from the ModSpec.</hi> </p> </description>
-</requirement>
2

-
Document Attributes

-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
--Draft is not a recognised status
2

-
Metanorma XML Syntax

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
XML Line 000004:42attribute "format" not allowed here; expected attribute "locale",​ "script" or "type"
2
XML Line 000017:144character content of element "subdoctype" invalid; must be equal to "conceptual-model", "conceptual-model-and-encoding", "conceptual-model-and-implementation", "encoding", "extension", "general", "implementation", "profile" or "profile-with-extension"
2
XML Line 000071:82element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000078:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000090:71element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000106:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000109:61element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000118:58element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000127:76element "acknowledgements" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000127:76found attribute "id", but no attributes allowed here
2
XML Line 000127:76found attribute "obligation", but no attributes allowed here
2
XML Line 000129:47found attribute "id", but no attributes allowed here
2
XML Line 000131:115found attribute "align", but no attributes allowed here
2
XML Line 000131:115found attribute "valign",​ but no attributes allowed here
2
XML Line 000131:69found attribute "id", but no attributes allowed here
2
XML Line 000131:69found attribute "unnumbered", but no attributes allowed here
2
XML Line 000132:36found attribute "align", but no attributes allowed here
2
XML Line 000132:36found attribute "valign",​ but no attributes allowed here
2
XML Line 000133:43found attribute "align", but no attributes allowed here
2
XML Line 000133:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000134:34found attribute "align", but no attributes allowed here
2
XML Line 000134:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000135:43found attribute "align", but no attributes allowed here
2
XML Line 000135:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000136:34found attribute "align", but no attributes allowed here
2
XML Line 000136:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000137:43found attribute "align", but no attributes allowed here
2
XML Line 000137:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000138:34found attribute "align", but no attributes allowed here
2
XML Line 000138:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000139:43found attribute "align", but no attributes allowed here
2
XML Line 000139:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000140:34found attribute "align", but no attributes allowed here
2
XML Line 000140:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000141:43found attribute "align", but no attributes allowed here
2
XML Line 000141:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000142:34found attribute "align", but no attributes allowed here
2
XML Line 000142:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000143:43found attribute "align", but no attributes allowed here
2
XML Line 000143:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000144:34found attribute "align", but no attributes allowed here
2
XML Line 000144:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000145:43found attribute "align", but no attributes allowed here
2
XML Line 000145:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000146:34found attribute "align", but no attributes allowed here
2
XML Line 000146:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000147:43found attribute "align", but no attributes allowed here
2
XML Line 000147:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000148:34found attribute "align", but no attributes allowed here
2
XML Line 000148:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000149:43found attribute "align", but no attributes allowed here
2
XML Line 000149:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000150:34found attribute "align", but no attributes allowed here
2
XML Line 000150:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000151:43found attribute "align", but no attributes allowed here
2
XML Line 000151:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000152:34found attribute "align", but no attributes allowed here
2
XML Line 000152:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000155:112element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000506:102element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000506:234element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000780:112element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000780:229element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000795:109element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000795:245element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 001320:11element "example" incomplete; expected element "dl", "figure",​ "formula", "ol", "p", "quote", "sourcecode" or "ul"
2
XML Line 003139:129element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 003139:18element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 003540:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003542:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003546:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003548:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003554:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003556:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003558:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003563:146found attribute "format",​ but no attributes allowed here
2
XML Line 003565:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003567:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003569:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003572:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003574:170found attribute "format",​ but no attributes allowed here
2
XML Line 003578:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003580:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003582:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003584:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003592:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003594:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003596:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003598:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003603:292attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003607:217element "link" missing required attribute "target"
2
XML Line 003607:82found attribute "format",​ but no attributes allowed here
2
XML Line 003608:217element "link" missing required attribute "target"
2
XML Line 003608:82found attribute "format",​ but no attributes allowed here
2
XML Line 003610:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003612:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003614:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003616:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003621:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003623:144found attribute "format",​ but no attributes allowed here
2
XML Line 003626:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003629:295found attribute "format",​ but no attributes allowed here
2
XML Line 003630:97found attribute "format",​ but no attributes allowed here
2
XML Line 003632:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003635:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003638:295found attribute "format",​ but no attributes allowed here
2
XML Line 003639:97found attribute "format",​ but no attributes allowed here
2
XML Line 003641:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003647:102attribute "unnumbered" not allowed here; expected attribute "id", "normative" or "obligation"
2
XML Line 003648:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003654:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003660:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003662:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003664:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003666:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003671:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003673:146found attribute "format",​ but no attributes allowed here
2
XML Line 003674:110found attribute "format",​ but no attributes allowed here
2
XML Line 003676:207element "link" missing required attribute "target"
2
XML Line 003676:51found attribute "format",​ but no attributes allowed here
2
XML Line 003680:206element "link" missing required attribute "target"
2
XML Line 003680:51found attribute "format",​ but no attributes allowed here
2
XML Line 003684:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003687:294found attribute "format",​ but no attributes allowed here
2
XML Line 003688:97found attribute "format",​ but no attributes allowed here
2
XML Line 003689:97found attribute "format",​ but no attributes allowed here
2
XML Line 003690:97found attribute "format",​ but no attributes allowed here
2
XML Line 003691:97found attribute "format",​ but no attributes allowed here
2
XML Line 003692:97found attribute "format",​ but no attributes allowed here
2
XML Line 003693:97found attribute "format",​ but no attributes allowed here
2
XML Line 003694:97found attribute "format",​ but no attributes allowed here
2
XML Line 003695:97found attribute "format",​ but no attributes allowed here
2
XML Line 003696:97found attribute "format",​ but no attributes allowed here
2
XML Line 003697:97found attribute "format",​ but no attributes allowed here
2
XML Line 003699:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003701:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003704:294found attribute "format",​ but no attributes allowed here
2
XML Line 003705:97found attribute "format",​ but no attributes allowed here
2
XML Line 003706:97found attribute "format",​ but no attributes allowed here
2
XML Line 003707:97found attribute "format",​ but no attributes allowed here
2
XML Line 003708:97found attribute "format",​ but no attributes allowed here
2
XML Line 003709:97found attribute "format",​ but no attributes allowed here
2
XML Line 003710:97found attribute "format",​ but no attributes allowed here
2
XML Line 003711:97found attribute "format",​ but no attributes allowed here
2
XML Line 003712:97found attribute "format",​ but no attributes allowed here
2
XML Line 003714:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003730:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003732:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003737:144attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003738:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003740:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003742:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003747:144found attribute "format",​ but no attributes allowed here
2
XML Line 003749:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003751:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003753:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003756:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003758:168found attribute "format",​ but no attributes allowed here
2
XML Line 003761:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003763:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003765:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003770:146found attribute "format",​ but no attributes allowed here
2
XML Line 003772:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003774:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003776:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003779:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003781:170found attribute "format",​ but no attributes allowed here
2
XML Line 003784:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003786:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003788:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003793:146found attribute "format",​ but no attributes allowed here
2
XML Line 003794:112found attribute "format",​ but no attributes allowed here
2
XML Line 003795:112found attribute "format",​ but no attributes allowed here
2
XML Line 003796:110found attribute "format",​ but no attributes allowed here
2
XML Line 003797:110found attribute "format",​ but no attributes allowed here
2
XML Line 003799:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003801:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003803:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003806:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003808:170found attribute "format",​ but no attributes allowed here
2
XML Line 003809:128found attribute "format",​ but no attributes allowed here
2
XML Line 003810:128found attribute "format",​ but no attributes allowed here
2
XML Line 003811:126found attribute "format",​ but no attributes allowed here
2
XML Line 003812:126found attribute "format",​ but no attributes allowed here
2
XML Line 003815:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003817:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003819:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003824:146found attribute "format",​ but no attributes allowed here
2
XML Line 003825:112found attribute "format",​ but no attributes allowed here
2
XML Line 003827:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003829:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003831:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003834:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003836:170found attribute "format",​ but no attributes allowed here
2
XML Line 003837:128found attribute "format",​ but no attributes allowed here
2
XML Line 003840:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003844:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003846:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003848:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003850:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003856:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003858:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003860:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003862:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003865:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003869:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003871:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003873:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003878:144found attribute "format",​ but no attributes allowed here
2
XML Line 003880:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003882:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003884:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003887:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003889:168found attribute "format",​ but no attributes allowed here
2
XML Line 003892:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003894:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003896:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003902:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003904:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003906:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003909:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003913:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003915:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003917:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003923:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003925:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003927:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003930:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003934:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003936:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003938:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003944:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003946:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003948:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003951:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003955:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003957:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003959:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003964:146found attribute "format",​ but no attributes allowed here
2
XML Line 003966:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003968:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003970:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003973:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003975:170found attribute "format",​ but no attributes allowed here
2
XML Line 003978:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003980:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003982:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003984:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003990:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003992:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003994:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003996:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003999:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004003:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004005:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004011:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004013:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004016:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004020:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004022:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004024:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004029:146found attribute "format",​ but no attributes allowed here
2
XML Line 004031:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004033:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004035:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004038:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 004040:170found attribute "format",​ but no attributes allowed here
2

-

From 4109cf155711fb5924b8fb680af892c573a2b0b8 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 14:21:55 -0700
Subject: [PATCH 04/43] Create ae-acknowledgements.adoc

---
 sources/sections/ae-acknowledgements.adoc | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 sources/sections/ae-acknowledgements.adoc

diff --git a/sources/sections/ae-acknowledgements.adoc b/sources/sections/ae-acknowledgements.adoc
new file mode 100644
index 0000000..a3043f1
--- /dev/null
+++ b/sources/sections/ae-acknowledgements.adoc
@@ -0,0 +1,20 @@
+[[annex-E]]
+[appendix,obligation=normative]
+== Acknowledgements
+
+The following OGC Members were key contributors to Version 1 of the ModSpec
+
+[%unnumbered]
+|===
+^h| Person ^h| Organization Represented
+| Simon Cox | CSIRO
+| David Danko | Eesi
+| James Greenwood | SeiCorp, Inc.
+| John R. Herring | Oracle USA
+| Andreas Matheus | University of the Bundeswehr -- ITS
+| Richard Pearsall | US National Geospatial-Intelligence Agency (NGA)
+| Clemens Portele | interactive instruments GmbH
+| Barry Reff | US Department of Homeland Security (DHS)
+| Paul Scarponcini | Bentley Systems, Inc.
+| Arliss Whiteside | BAE Systems - C3I Systems
+|===

From 0ef7c7be052803435320e3f65d89d9655cfb2142 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 14:22:13 -0700
Subject: [PATCH 05/43] Move acknowledgements to annex E

---
 sources/sections/00-preface.adoc | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/sources/sections/00-preface.adoc b/sources/sections/00-preface.adoc
index a665a42..082980e 100644
--- a/sources/sections/00-preface.adoc
+++ b/sources/sections/00-preface.adoc
@@ -48,26 +48,6 @@ The following OGC Members contributed and particpated in developing Version 2 of
 | Jeff Yutzler | ImageMatters
 |===
 
-[.preface]
-== Acknowledgements
-
-The following OGC Members were key contributors to Version 1 of the ModSpec
-
-[%unnumbered]
-|===
-^h| Person ^h| Organization Represented
-| Simon Cox | CSIRO
-| David Danko | ESRI
-| James Greenwood | SeiCorp, Inc.
-| John R. Herring | Oracle USA
-| Andreas Matheus | University of the Bundeswehr -- ITS
-| Richard Pearsall | US National Geospatial-Intelligence Agency (NGA)
-| Clemens Portele | interactive instruments GmbH
-| Barry Reff | US Department of Homeland Security (DHS)
-| Paul Scarponcini | Bentley Systems, Inc.
-| Arliss Whiteside | BAE Systems - C3I Systems
-|===
-
 [.preface]
 == Revision history
 

From 651b35f8dd42f880ead27af4d628dd47ebf3069f Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 14:30:53 -0700
Subject: [PATCH 06/43] Add acknowledgements annex

---
 sources/document.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sources/document.adoc b/sources/document.adoc
index 56bb5ba..a5fe0cd 100644
--- a/sources/document.adoc
+++ b/sources/document.adoc
@@ -51,3 +51,4 @@ include::sections/ac-definitions.adoc[]
 
 include::sections/ad-bibliography.adoc[]
 
+include::sections/ae-acknowledgements.adoc[]

From affff177cee9930ba3bdd76aebfc4af71f33ae2c Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 15:45:35 -0700
Subject: [PATCH 07/43] Update ae-acknowledgements.adocAnnex D not E

---
 sources/sections/ae-acknowledgements.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/sections/ae-acknowledgements.adoc b/sources/sections/ae-acknowledgements.adoc
index a3043f1..24a2972 100644
--- a/sources/sections/ae-acknowledgements.adoc
+++ b/sources/sections/ae-acknowledgements.adoc
@@ -1,4 +1,4 @@
-[[annex-E]]
+[[annex-d]]
 [appendix,obligation=normative]
 == Acknowledgements
 

From 53d9cf58b3c27887d4df76b1b61ffd67897e8ede Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 15:50:53 -0700
Subject: [PATCH 08/43] Fix bookmarks and Standardization goal wording.

---
 sources/sections/01-scope.adoc | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

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

From b083ad9bd93a33a0788042514294b10f356e8740 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 15:55:04 -0700
Subject: [PATCH 09/43] Fix bookmarks, chnage Policy to ModSpec

---
 sources/sections/04-terms-and-defs.adoc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index 13a4aca..f993dd2 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -9,7 +9,7 @@ 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 <>.
+Many of these definitions depend upon the model given in <>.
 
 === building block
 
@@ -89,7 +89,7 @@ set of <> that define tests for all {{r
 The {{conformance suite}} is the union of all <>. It is by definition the
 <> of the entire standard or abstract specification.
 
-In this Policy, each {{requirement}} is mandatory within its <> and each {{requirement}} is tested in at least one {{conformance test}}.
+In theModSpec, each {{requirement}} is mandatory within its <> and each {{requirement}} is tested in at least one {{conformance test}}.
 ====
 
 === core requirements class

From eb7204f1da060a17b0582b40ea9cc864ae778891 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:08:45 -0700
Subject: [PATCH 10/43] Fixing bookmarks and Note

---
 sources/sections/06-fundamentals.adoc | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/sources/sections/06-fundamentals.adoc b/sources/sections/06-fundamentals.adoc
index 550cc44..9a63457 100644
--- a/sources/sections/06-fundamentals.adoc
+++ b/sources/sections/06-fundamentals.adoc
@@ -84,7 +84,7 @@ 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 <> above.
+paragraph, such as <> below.
 
 The distribution of the information in a standard is not restricted. The only
 requirement is that requirements be grouped in a manner
@@ -92,8 +92,9 @@ consistent with the conformance test classes, see <> and <>.
 
 === Documenting the Standard
 
-NOTE: For OGC Standards, the assumptions is that documents are in a commonly used
-logical form (template). 
+NOTE: OGC Standards are written using an OGC Member approved template that is conformant with the 
+requirements stated in the ModSpec
+ 
 
 This form should be specified by the following descriptions:
 

From c69dc121c8acaf78a588760ce93fb8b952cdf3f2 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:11:23 -0700
Subject: [PATCH 11/43] Add note to requirement 0

---
 sources/sections/06-req-class.adoc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sources/sections/06-req-class.adoc b/sources/sections/06-req-class.adoc
index d729d03..98a13da 100644
--- a/sources/sections/06-req-class.adoc
+++ b/sources/sections/06-req-class.adoc
@@ -3,6 +3,7 @@
 
 The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the `core` of the ModSpec.
 
+NOTE: The following requirement is for OGC work only and will be moved to the OGC Policy statement regarding the use of the ModSpec. This move will happen once the policy is removed.
 [[req-0]]
 [requirement,model=ogc,type="general"]
 [width="90%",cols="2,6"]
@@ -11,6 +12,8 @@ The following requirements specify the rules for the content and structure of a
 Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard _SHALL_ comply with the requirements stated in this document.
 |===
 
+The following requirement states that every requirement is testable.
+
 [[req-1]]
 [requirement,model=ogc,type="general"]
 [width="90%",cols="2,6"]

From 3fc454ad3c398b046972a395c650cc25aee8f6b6 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:13:01 -0700
Subject: [PATCH 12/43] Add confromance suite back in.

---
 sources/sections/ac-definitions.adoc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc
index 42a0e55..a96f163 100644
--- a/sources/sections/ac-definitions.adoc
+++ b/sources/sections/ac-definitions.adoc
@@ -71,9 +71,10 @@ class diagram.
 
 === Standard
 
-[lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Specification, skip]
+[lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Standard, skip]
 
 === Conformance Suite
+[lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceSuite, skip]
 
 [[conformance-class]]
 === Conformance Class

From 6ea7506134c804773ae434285be83e52b2a15653 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:13:56 -0700
Subject: [PATCH 13/43] Change class name specification to standard.

---
 sources/models/ogc-modspec.lutaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/models/ogc-modspec.lutaml b/sources/models/ogc-modspec.lutaml
index 9942d32..fecd6b1 100644
--- a/sources/models/ogc-modspec.lutaml
+++ b/sources/models/ogc-modspec.lutaml
@@ -1,7 +1,7 @@
 diagram OGCModSpec {
   title "OGC 08-131r3 ModSpec"
 
-  class Specification {
+  class Standard {
     definition {
       For a draft standard (aka specification) to become an international standard, the document must be approved by an authority, 
       such as ISO or the OGC. The attributes of a standard describe its local name, its authority, the date of publication 

From 0a2b1d5bfbeb1c0fdb6a8ad19ac73555602a9510 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:45:21 -0700
Subject: [PATCH 14/43] More bookmarks

---
 sources/sections/ac-definitions.adoc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc
index a96f163..5220f75 100644
--- a/sources/sections/ac-definitions.adoc
+++ b/sources/sections/ac-definitions.adoc
@@ -65,14 +65,14 @@ against a candidate {{standardization target}}.
 
 image::img02.png[]
 
-<
> represents a UML model consistent with the model described
-in <> of this document. The following subclauses describe the classes shown in this UML
+<> represents a UML model consistent with the model described
+in <> of this document. The following subclauses describe the classes shown in this UML
 class diagram.
 
 === Standard
-
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Standard, skip]
 
+[[conformance-suite]]
 === Conformance Suite
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceSuite, skip]
 

From 9c423b2f73c0df0354adb037db8fe83ce0768423 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:57:52 -0700
Subject: [PATCH 15/43] Fix a bookmark

---
 sources/sections/06-req-class.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sources/sections/06-req-class.adoc b/sources/sections/06-req-class.adoc
index 98a13da..f6e00e2 100644
--- a/sources/sections/06-req-class.adoc
+++ b/sources/sections/06-req-class.adoc
@@ -1,4 +1,5 @@
 [[cls-6]]
+[[cls-8-1]]
 == ModSpec Requirements Class: Core
 
 The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the `core` of the ModSpec.

From 1ba0767c9248d51abc4ced0e2d15ffc621535b84 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Fri, 13 Dec 2024 16:58:38 -0700
Subject: [PATCH 16/43] Fix bookmark

---
 sources/sections/ac-definitions.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc
index 5220f75..0657719 100644
--- a/sources/sections/ac-definitions.adoc
+++ b/sources/sections/ac-definitions.adoc
@@ -66,7 +66,7 @@ against a candidate {{standardization target}}.
 image::img02.png[]
 
 <> represents a UML model consistent with the model described
-in <> of this document. The following subclauses describe the classes shown in this UML
+in <> of this document. The following subclauses describe the classes shown in this UML
 class diagram.
 
 === Standard

From cdd82aa3cfa95bc3b3fd7d80ec7465c57970dad2 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 15:31:55 -0700
Subject: [PATCH 17/43] Test

---
 sources/sections/ac-definitions.adoc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc
index 0657719..1002606 100644
--- a/sources/sections/ac-definitions.adoc
+++ b/sources/sections/ac-definitions.adoc
@@ -69,11 +69,11 @@ image::img02.png[]
 in <> of this document. The following subclauses describe the classes shown in this UML
 class diagram.
 
-=== Standard
+[[Standard]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Standard, skip]
 
 [[conformance-suite]]
-=== Conformance Suite
+
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceSuite, skip]
 
 [[conformance-class]]

From 3df51f48aae8065f1b195c8e106ced753d28f266 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 15:46:58 -0700
Subject: [PATCH 18/43] Rewrite first two sentences

---
 sources/sections/00-foreword.adoc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sources/sections/00-foreword.adoc b/sources/sections/00-foreword.adoc
index 2327514..b64087a 100644
--- a/sources/sections/00-foreword.adoc
+++ b/sources/sections/00-foreword.adoc
@@ -1,8 +1,7 @@
 [.preface]
 == Foreword
 
-The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a formal structure for standards documents but does not supply
-specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <>
+The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a model for a formal structure and requirements for writing standards documents. However, the ModSpec does not supply specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <>
 and the Conformance Test Suite <>).
 
 _Attention is drawn to the possibility that some of the elements of this document may

From 74f64b883e7eae89b8f8d30e6a64cf9d28bcf7d1 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 15:47:50 -0700
Subject: [PATCH 19/43] A bit more wordsmithing

---
 sources/sections/00-foreword.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/sections/00-foreword.adoc b/sources/sections/00-foreword.adoc
index b64087a..0952ed8 100644
--- a/sources/sections/00-foreword.adoc
+++ b/sources/sections/00-foreword.adoc
@@ -1,7 +1,7 @@
 [.preface]
 == Foreword
 
-The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a model for a formal structure and requirements for writing standards documents. However, the ModSpec does not supply specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <>
+The OGC ModSpec - A Standard for Designing and Writing Modular Standards specifies a formal structure and requirements for writing modular standards documents. However, the ModSpec does not supply specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, <>
 and the Conformance Test Suite <>).
 
 _Attention is drawn to the possibility that some of the elements of this document may

From 8a608a2275f9d305e5e653d498aa82cd2e4c2ed7 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 15:51:50 -0700
Subject: [PATCH 20/43] Word smithing and remove one note.

---
 sources/sections/00-preface.adoc | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sources/sections/00-preface.adoc b/sources/sections/00-preface.adoc
index 082980e..631ed07 100644
--- a/sources/sections/00-preface.adoc
+++ b/sources/sections/00-preface.adoc
@@ -1,17 +1,19 @@
 [.preface]
 == Preface
 
-This OGC member developed and approved document defines a model and related requirements and recommendations for writing and structuring modular standards documents. Further, this model is designed to enable the consistent and verifiable testing of implementations of a standard that claim conformance.
+This OGC member developed and approved document, referred to as the `ModSpec`, defines a model and related requirements and recommendations for writing and structuring modular standards documents. Further, this model is designed to enable the consistent and verifiable testing of implementations of a standard that claim conformance.
 
 The goal is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
 
+///
 NOTE: For OGC only: Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard shall comply with the requirements stated in this document.
+///
 
 NOTE: Historically, this document has been known and abbreviated as the "ModSpec". For continuity and ease of understanding this document may also be refered to as the "OGC ModSpec".
 
 Suggested additions, changes, and comments on this this document are welcome and
 encouraged. Such suggestions may be submitted through the OGC Change Request System
-(http://www.opengeospatial.org/standards/cr) or by creating an issue in the GitHub repository for this document (https://github.com/opengeospatial/ogc-modspec).
+(http://ogc.standardstracker.org/) or by creating an issue in the OGC ModSpec GitHub repository (https://github.com/opengeospatial/ogc-modspec).
 
 [.preface]
 == Document terms and definitions
@@ -20,7 +22,7 @@ This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008],
 is based on the ISO/IEC Directives, Part 2. Rules for the structure and drafting of
 International Standards. In particular, the word "shall" (not "must") is the
 imperative verb form used to indicate a requirement to be strictly followed to
-conform to this standard.
+conform to the ModSpec.
 
 [.preface]
 == Document editors

From 990f4f1a773aca2a7c6069c098801027c6048df3 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 15:52:10 -0700
Subject: [PATCH 21/43] Update 00-preface.adoc

---
 sources/sections/00-preface.adoc | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/sources/sections/00-preface.adoc b/sources/sections/00-preface.adoc
index 631ed07..06d2ea3 100644
--- a/sources/sections/00-preface.adoc
+++ b/sources/sections/00-preface.adoc
@@ -5,10 +5,6 @@ This OGC member developed and approved document, referred to as the `ModSpec`, d
 
 The goal is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
 
-///
-NOTE: For OGC only: Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard shall comply with the requirements stated in this document.
-///
-
 NOTE: Historically, this document has been known and abbreviated as the "ModSpec". For continuity and ease of understanding this document may also be refered to as the "OGC ModSpec".
 
 Suggested additions, changes, and comments on this this document are welcome and

From 89a293e3706e3a2c6977fd687dd465376f77d27f Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 16:02:14 -0700
Subject: [PATCH 22/43] Word smithing and remove duplicate content.

---
 sources/sections/01-scope.adoc | 39 +++++++++++-----------------------
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/sources/sections/01-scope.adoc b/sources/sections/01-scope.adoc
index dd6168c..a117613 100644
--- a/sources/sections/01-scope.adoc
+++ b/sources/sections/01-scope.adoc
@@ -1,6 +1,6 @@
 [[cls-1]]
 == Scope
-The 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"). 
@@ -10,43 +10,28 @@ The OGC Standard for Designing and Writing Modular Standards, also known as the
 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 to be tested and deemed _conformant_ or not.
+interoperability. The ultimate goal of this approach is to enable interoperable implementations of a standard to be tested and deemed _conformant_ or not.
 
-NOTE: For OGC Standards work, the word “standard” in the ModSpec applies to all OGC draft standards, approved standards, draft Abstract Specifications, and approved Abstract Specifications. The exceptions are OGC Abstract Specifications that originate in ISO or Community Standards that are developed external to the OGC and then submitted to the OGC.
-
-Therefore, a standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. 
+Therefore, a standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. The approach modelled in the ModSpec has been referred to as the "core and extension model" due to its insistence on a modular structure throughout all parts of a standard and its implementation.
 
-<> defines the UML model upon which the ModSpec is
-based. Annex C also contains informal and non-normative definitions ordered for ease
-of understanding. These two sections can be read first to aid in the understanding of
-the rest of the document.
-
-NOTE: Please note that the ModSpec has been approved by the OGC Membership as a policy directive for the development and revision of any OGC Standard or Abstract Specification that has requirements. However, the ModSpec is written to be non-OGC specific and can be used by any Standards Development Organization (SDO) as a formal guide for structuring a standards document.
+There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the https://docs.ogc.org/is/19-072/19-072.html[OGC API - Common Part 1: Core Standard] and in the https://github.com/opengeospatial/cdbswg/blob/master/cdb-2.0/cdb-core-crs-requirements-class.adoc[CDB 2.0 Standard CRS Requirements Module]. By formally implementing the requirements specified in the ModSpec, reusable, testable, modular standards can be developed.
 
 [[things-to-know]]
-=== Things to know
+=== Understanding the ModSpec
 
-NOTE: Reading the Terms and Definitions clause and Clause <> will help understanding the content and
+Reading the Terms and Definitions clause and Clause <> will help understanding the content and
 requirements stated in this document.
 
-This OGC document, 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"). 
-- 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. 
+<> defines the UML model upon which the ModSpec is
+based. Annex C also contains informal and non-normative definitions ordered for ease
+of understanding. These two sections can be read first to aid in the understanding of
+the rest of the document.
 
-The goal of this approach is to enable implementations of a standard to be tested and deemed _conformant_ or not.
+NOTE: For OGC Standards work, the word “standard” in the ModSpec applies to all OGC draft standards, approved standards, draft Abstract Specifications, and approved Abstract Specifications. The exceptions are OGC Abstract Specifications that originate in ISO or Community Standards that are developed external to the OGC and then submitted to the OGC.
 
 NOTE: Please note that the ModSpec has been approved by the OGC Membership as a policy directive for the development and revision of any OGC Standard or Abstract Specification that has requirements. However, the ModSpec is written to be non-OGC specific and can be used by any Standards Development Organization (SDO) as a formal guide for structuring a standards document.
 
-A standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. 
-
-There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the https://docs.ogc.org/is/19-072/19-072.html[OGC API - Common Part 1: Core Standard] and in the https://github.com/opengeospatial/cdbswg/blob/master/cdb-2.0/cdb-core-crs-requirements-class.adoc[CDB 2.0 Standard CRS Requirements Module]. By formally implementing the requirements specified in the ModSpec, reusable, testable, modular standards can be developed.
-
-NOTE: The approach modelled in the ModSpec has been referred to as the "core and extension model" due to its
-insistence on a modular structure throughout all parts of a standard and its implementation.
-
-In informative sections, the word "will" implies that something is an implication of a requirement. The "will" statements are
+NOTE: 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.
 
 ==== ModSpec document structure

From 2d8eaf6ecbb62fda94253658e94bd3bb4a8ae6f8 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 16:03:15 -0700
Subject: [PATCH 23/43] Update 01-scope.adoc

---
 sources/sections/01-scope.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/sections/01-scope.adoc b/sources/sections/01-scope.adoc
index a117613..7ecd3dc 100644
--- a/sources/sections/01-scope.adoc
+++ b/sources/sections/01-scope.adoc
@@ -34,7 +34,7 @@ NOTE: Please note that the ModSpec has been approved by the OGC Membership as a
 NOTE: 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.
 
-==== ModSpec document structure
+=== ModSpec document structure
 
 Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are:
 

From 7b0a3fd3989043fe59546975cc77a0020e7b9e94 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 17:20:48 -0700
Subject: [PATCH 24/43] CLean up - remove a few dozen cross references - too
 messy.

---
 sources/sections/04-terms-and-defs.adoc | 79 ++++++++++---------------
 1 file changed, 30 insertions(+), 49 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index f993dd2..316c370 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -40,8 +40,7 @@ within a standard, or set of standards
 test for a particular requirement or a set of related requirements
 
 NOTE: When no ambiguity, the word "case" may be omitted. i.e.
-{{conformance test}} is the same as
-{{conformance test case}}.
+conformance test is the same as conformance test case.
 
 === conformance test module
 
@@ -49,8 +48,8 @@ set of related tests for a given requirements module all with the same standardi
 
 [NOTE]
 ====
-When there is no ambiguity, the word "test" may be omitted. i.e. {{conformance test module}}
-is the same as *conformance module*. Conformance modules may be nested in a hierarchical way.
+When there is no ambiguity, the word "test" may be omitted. i.e. conformance test module
+is the same as conformance module. Conformance modules may be nested in a hierarchical way.
 ====
 
 === conformance test class
@@ -60,36 +59,34 @@ set of {{conformance tests,conformance test}} that must be passed to receive a s
 
 [NOTE]
 ====
-When no ambiguity is possible, the word "test" may be left out, so {{conformance test class}}
-maybe called a <>.
+When no ambiguity is possible, the word "test" may be left out, so conformance test class
+maybe called a conformance class.
 
 In the ModSpec, the set of {{requirement,requirements}} tested by the
 conformance tests within a <> is a
-{{requirements class}} and its dependencies. Optional {{requirement,requirements}} will
-be in a separate {{requirements class}} with other {{requirement,requirements}}
+requirements class and its dependencies. Optional {{requirement,requirements}} will
+be in a separate {{requirements class}} with other requirements
 that are part of the same option. Each {{requirements class}} corresponds to a
-separate <>
+separate {{conformance class}}
 
 Each requirements class will be in a 1 to 1 correspondence to a similarly named
-<> that tests all of the
-{{requirements class,requirements class's}} {{requirement,requirements}}.
+{{conformance class}} that tests all of the requirements in a requirements class.
 
-All {{requirement,requirements}} in a <>
-will have the same {{standardization target}}.
+All {{requirement,requirements}} in a conformance class will have the same {{standardization target}}.
 ====
 
 === conformance suite
 alt:[conformance test suite]
 alt:[abstract test suite]
 
-set of <> that define tests for all {{requirement,requirements}} of a standard or abstract specification
+set of conformance classes that define tests for all requirements of a standard or abstract specification
 
 [NOTE]
 ====
-The {{conformance suite}} is the union of all <>. It is by definition the
-<> of the entire standard or abstract specification.
+The conformance suite is the union of all conformance classes. It is by definition the
+conformance class of the entire standard or abstract specification.
 
-In theModSpec, each {{requirement}} is mandatory within its <> and each {{requirement}} is tested in at least one {{conformance test}}.
+In theModSpec, each {{requirement}} is mandatory within its conformance class and each {{requirement}} is tested in at least one {{conformance test}}.
 ====
 
 === core requirements class
@@ -106,7 +103,7 @@ more than one, then each *core* would have to be implemented to pass any
 *core*. The *core* may be empty, or all or part of another standard or related
 set of standards.
 
-The "*core*" can refer to this {{requirements class}}, its associated
+The "*core*" can refer to this requirements class, its associated
 {{conformance test class}} or the software module that implements that
 requirements class.
 ====
@@ -114,25 +111,18 @@ requirements class.
 === direct dependency (of a requirements class)
 
 another {{requirements class}} (the dependency) whose {{requirement,requirements}} are defined to also be
-{{requirement,requirements}} of this
-{{requirements class}}
+requirement(s) of this requirements class
 
 [NOTE]
 ====
-A {{direct dependency (of a requirements class), direct dependency}}
-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 (of a requirements class), direct dependency}}.
-Any tests associated with this
-{{direct dependency (of a requirements class),dependency}} can be applied to this
-{{requirements class}}.
+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 way of saying that the current
+requirements class extends, or uses all the aspects of the direct dependency (of a requirements class).
+Any tests associated with this direct dependency (of a requirements class) can be applied to this requirements class.
 
 When testing a
-{{direct dependency (of a requirements class), direct dependency}}, the
-{{standardization target}} is directly subject to the test in the specified
-{{conformance test class}} of the {{direct dependency (of a requirements class), direct dependency}}.
+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.
 ====
 
 === indirect dependency (of a requirements class)
@@ -144,17 +134,14 @@ implementation of this {{requirements class}}
 [NOTE]
 ====
 In this instance, as opposed to the
-{{direct dependency (of a requirements class),direct dependency}},
-the test against the consumable or product used
+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 dependency (of a requirements class), Direct dependencies}}
-test the same {{standardization target}}, but
-{{indirect dependency (of a requirements class), indirect dependencies}}
-test related but different {{standardization target,standardization targets}}.
+Direct dependencies test the same {{standardization target}}, but
+indirect dependencies}} test related but different {{standardization target,standardization targets}}.
 
 For example, if a DRM-enabled service is required
 to have an association to a licensing service, then the requirements of a
@@ -165,12 +152,9 @@ requirement may be stated as the associated licensing service has a
 
 === extension (of a requirements class)
 
-{{requirements class}} which has a
-{{direct dependency (of a requirements class), direct dependency}} on another
-{{requirements class}}
+{{requirements class}} which has a direct dependency}} on another {{requirements class}}
 
-NOTE: Here {{extension (of a requirements class),extension}} is
-defined on {{requirements class}} so that their implementation may be
+NOTE: Here an extension of a requirements class is defined on {{requirements class}} so that their implementation may be
 software extensions in a manner analogous to the extension relation between the
 {{requirements class,requirements classes}}.
 
@@ -265,8 +249,7 @@ compliance with the standard is to be claimed and from which no deviation is per
 
 [NOTE]
 ====
-Each {{requirement}} is a normative criterion for a single
-*type of standardization target*. In the ModSpec, requirements are
+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}}.
 
@@ -276,8 +259,7 @@ a procedural standard requires software implementations. The view of a
 standard in terms of a set of testable {{requirement,requirements}} allows us to
 use set descriptions of both the standard and its implementations.
 
-{{requirement,Requirements}} use normative language and are
-commands and use the imperative "shall" or similar imperative constructs.
+Requirements use normative language and 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.
@@ -340,8 +322,7 @@ NOTE: Need to add examples! The standardization target of the CDB version 2.0 CR
 
 === standardization target type
 
-type of entity or set of entities to which the {{requirement,requirements}} of a
-{{standard}} apply
+type of entity or set of entities to which the {{requirement,requirements}} 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 and 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.
 

From 5c96365922e7c676fbf7c67e67b6b800c5f1c007 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sat, 14 Dec 2024 18:11:02 -0700
Subject: [PATCH 25/43] Fix some cross references.

---
 sources/sections/04-terms-and-defs.adoc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index 316c370..35d7e46 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -63,11 +63,11 @@ When no ambiguity is possible, the word "test" may be left out, so conformance t
 maybe called a conformance class.
 
 In the ModSpec, the set of {{requirement,requirements}} tested by the
-conformance tests within a <> is a
-requirements class and its dependencies. Optional {{requirement,requirements}} will
+conformance tests within a conformance class is a
+requirements class and its dependencies. Optional requirements will
 be in a separate {{requirements class}} with other requirements
-that are part of the same option. Each {{requirements class}} corresponds to a
-separate {{conformance class}}
+that are part of the same option. Each requirements class corresponds to a
+separate conformance test class.
 
 Each requirements class will be in a 1 to 1 correspondence to a similarly named
 {{conformance class}} that tests all of the requirements in a requirements class.

From 6f55ad974ab0ea95629b5619b287a8b0d4795f1a Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sun, 15 Dec 2024 15:15:53 -0700
Subject: [PATCH 26/43] Update 04-terms-and-defs.adoc

---
 sources/sections/04-terms-and-defs.adoc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index 35d7e46..e7ffd56 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -55,7 +55,7 @@ is the same as conformance module. Conformance modules may be nested in a hierar
 === conformance test class
 alt:[conformance test level]
 
-set of {{conformance tests,conformance test}} that must be passed to receive a single {{certificate of conformance}}
+set of conformance tests that must be passed to receive a single {{certificate of conformance}}
 
 [NOTE]
 ====
@@ -70,7 +70,7 @@ that are part of the same option. Each requirements class corresponds to a
 separate conformance test class.
 
 Each requirements class will be in a 1 to 1 correspondence to a similarly named
-{{conformance class}} that tests all of the requirements in a requirements class.
+{{conformance test class}} that tests all of the requirements in a requirements class.
 
 All {{requirement,requirements}} in a conformance class will have the same {{standardization target}}.
 ====

From e41bfe61a4eaf0981020f3f3d33632e07235f7bc Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Sun, 15 Dec 2024 15:17:06 -0700
Subject: [PATCH 27/43] Fixing cross references

---
 sources/sections/04-terms-and-defs.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index e7ffd56..9afc9d5 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -53,7 +53,7 @@ is the same as conformance module. Conformance modules may be nested in a hierar
 ====
 
 === conformance test class
-alt:[conformance test level]
+alt:[conformance class]
 
 set of conformance tests that must be passed to receive a single {{certificate of conformance}}
 

From 944c666ce34dffaace5902fa6346e95369444402 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 10:42:20 -0700
Subject: [PATCH 28/43] Fix some cross references and add more wording to
 specification

---
 sources/sections/04-terms-and-defs.adoc | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index 9afc9d5..5356226 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -232,7 +232,7 @@ excluding others, or that a certain course of action is preferred but not
 necessarily required, or that (in the negative form) a certain possibility or
 course of action is deprecated but not prohibited
 
-NOTE: Although using normative language, a {{recommendation}} is not
+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).
@@ -253,11 +253,11 @@ Each requirement is a normative criterion for a single *type of standardization
 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
+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 {{requirement,requirements}} allows us to
-use set descriptions of both the standard and its implementations.
+standard in terms of a set of testable requirements allows for
+using set descriptions of both the standard and its implementations.
 
 Requirements use normative language and are commands and use the imperative "shall" or similar imperative constructs.
 Statements in standards which are not requirements and need to be either
@@ -293,10 +293,14 @@ those {{requirement,requirements}}
 
 [NOTE]
 ====
-This definition is included for completeness. See <>.
+This definition is included for completeness.
+====
 
-This does not restrict what else a standard may contain, as long as it does
-contain the three types of element cited.
+[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.
+Implementatins Standards are always testable and contain a {{conformance test suite}}.
 ====
 
 === standard
@@ -318,8 +322,6 @@ 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: Need to add examples! The standardization target of the CDB version 2.0 CRS Requirements Classes is to ensure that an implementation clearly defines (with metadata) the CRS for a CDB compliant datastore. 
-
 === standardization target type
 
 type of entity or set of entities to which the {{requirement,requirements}} of a {{standard}} apply
@@ -331,8 +333,7 @@ NOTE: For example, the standardization target type for The OGC API – Features
 expression in a document conveying information
 
 NOTE: Includes all statements in a document not part of the normative
-{{requirement,requirements}},
-{{recommendation,recommendations}} or
+{{requirement,requirements}}, {{recommendation,recommendations}} or
 {{conformance test, conformance tests}}. Included for completeness.
 
 [.source]

From 82c3087eced966dc21db06d95f9f56354763a8ec Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 10:50:18 -0700
Subject: [PATCH 29/43] Edit Standrdization goal.

---
 sources/sections/06-fundamentals.adoc | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/sources/sections/06-fundamentals.adoc b/sources/sections/06-fundamentals.adoc
index 9a63457..fa0c941 100644
--- a/sources/sections/06-fundamentals.adoc
+++ b/sources/sections/06-fundamentals.adoc
@@ -20,9 +20,7 @@ These characteristics are slightly modified from the Open Group definitions to a
 
 === Standardization Context - Goals and Targets
 
-NOTE: Don't forget to add the requirements cited.
-
-Every OGC Standard document shall include a Standardization Goal (see requirement TBD). 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:
 
@@ -30,9 +28,9 @@ Instances of a Standardization Target Type are the Standardization Targets.  The
 * Standardization Target Type – An abstract representation of one of the actors or entities identified in the Standardization Goal
 * Standardization Target – an implementation of a Standardization Target Type. These are the real-world entities which can be tested for conformance with the requirements documented in the Standard.
 
-Standardization Target Types can be hierarchical.  The Conceptual, Logical, Physical hierarchy is one example where the Standardization Target Types are information models. Another example would be implementations of OGC API - Features Part 2 which support XML data exchange.
+Standardization Target Types can be hierarchical. The Conceptual, Logical, Physical hierarchy is one example where the Standardization Target Types are information models. Another example would be implementations of OGC API - Features Part 2 which support XML data exchange.
 
-Notice that the Standardization Targets and Standardization Target Types no longer form a simple taxonomy. 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.
+Notice that the Standardization Targets and Standardization Target Types no longer form a simple taxonomy. 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
 

From 64d84ac9a1bd8e6b8946babda8e0a44ab016eee7 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 15:36:53 -0700
Subject: [PATCH 30/43] And hopefully final cleanup of bookmarks

---
 sources/sections/04-terms-and-defs.adoc | 28 ++++++++++++-------------
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc
index 5356226..7947c02 100644
--- a/sources/sections/04-terms-and-defs.adoc
+++ b/sources/sections/04-terms-and-defs.adoc
@@ -86,7 +86,7 @@ set of conformance classes that define tests for all requirements of a standard
 The conformance suite is the union of all conformance classes. It is by definition the
 conformance class of the entire standard or abstract specification.
 
-In theModSpec, each {{requirement}} is mandatory within its conformance class and each {{requirement}} is tested in at least one {{conformance test}}.
+In the ModSpec, each {{requirement}} is mandatory within its conformance class and each {{requirement}} is tested in at least one {{conformance test}}.
 ====
 
 === core requirements class
@@ -97,7 +97,7 @@ standard
 
 [NOTE]
 ====
-The core {{requirements class}} is unique because if it were possible to have
+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
@@ -120,8 +120,7 @@ A direct dependency (of a requirements class) of the current {{requirements clas
 requirements class extends, or uses all the aspects of the direct dependency (of a requirements class).
 Any tests associated with this direct dependency (of a requirements class) can be applied to this requirements class.
 
-When testing a
-direct dependency of a requirements class, the {{standardization target}} is directly subject to the test in the specified
+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.
 ====
 
@@ -134,14 +133,14 @@ 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
+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
+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 target,standardization targets}}.
+indirect dependencies}} test related but different standardization target,standardization targets.
 
 For example, if a DRM-enabled service is required
 to have an association to a licensing service, then the requirements of a
@@ -152,11 +151,10 @@ requirement may be stated as the associated licensing service has a
 
 === extension (of a requirements class)
 
-{{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 on {{requirements class}} so that their implementation may be
-software extensions in a manner analogous to the extension relation between the
-{{requirements class,requirements classes}}.
+NOTE: Here an extension of a requirements class is defined on requirements class so that their implementation may be
+software extensions in a manner analogous to the extension relation between the requirements classes.
 
 === general recommendation
 
@@ -234,7 +232,7 @@ course of action is deprecated but not prohibited
 
 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
+command) of a requirement with a "should" (suggestive or
 conditional).
 
 NOTE: Recommendations are *not* tested and therefor have no related conformance test.
@@ -310,8 +308,8 @@ document that has been approved by a legitimate Standards Body
 [NOTE]
 ====
 This definition is included for completeness. {{standard,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
+{{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.
 ====
 
@@ -319,7 +317,7 @@ legitimate standards organization.
 
 entity to which some {{requirement,requirements}} of a {{standard}} apply
 
-NOTE: The {{standardization target}} is the entity which may receive a
+NOTE: The standardization target is the entity which may receive a
 {{certificate of conformance}} for a {{requirements class}}.
 
 === standardization target type

From 67ec77c807acc27a04f0f249a6568c44eb6f5031 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 15:42:47 -0700
Subject: [PATCH 31/43] Stop double headings

---
 sources/sections/ac-definitions.adoc | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc
index 1002606..232e362 100644
--- a/sources/sections/ac-definitions.adoc
+++ b/sources/sections/ac-definitions.adoc
@@ -73,33 +73,31 @@ class diagram.
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Standard, skip]
 
 [[conformance-suite]]
-
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceSuite, skip]
 
 [[conformance-class]]
-=== Conformance Class
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceClass, skip]
 
-=== Requirements class
+[[requirements-class]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, RequirementsClass, skip]
 
-=== Requirements module
+[[requirements-module]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, RequirementsModule, skip]
 
-=== Normative Statement
+[[normative-statement]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, NormativeStatement, skip]
 
-=== Requirement
+[[requirement]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Requirement, skip]
 
-=== Recommendation
+[[recommendation]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, Recommendation, skip]
 
-=== Conformance test
+[[conformance-test]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, ConformanceTest, skip]
 
-=== StandardizationTarget
+[[standardization-target]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, StandardizationTarget, skip]
 
-=== StandardizationTargetType
+[[standardization-Target-Type]]
 [lutaml_uml_attributes_table,models/ogc-modspec.lutaml, StandardizationTargetType, skip]

From 16aa2cd93f65c2df0a966e41929ecc11878d0b9c Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 15:52:59 -0700
Subject: [PATCH 32/43] Some additional edits. Make sure requirements module,
 req class hierarchy corrected.

---
 sources/models/ogc-modspec.lutaml | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/sources/models/ogc-modspec.lutaml b/sources/models/ogc-modspec.lutaml
index fecd6b1..dc5a6d6 100644
--- a/sources/models/ogc-modspec.lutaml
+++ b/sources/models/ogc-modspec.lutaml
@@ -36,9 +36,9 @@ diagram OGCModSpec {
 
   class ConformanceSuite {
     definition {
-      The unique conformance suite of a standard lists the tests (grouped
-      into conformance test classes consisting of some number of conformance
-      test modules, containing some number of conformance tests) that allow
+      The unique conformance suite of a standard lists the tests (possibly grouped
+      into conformance test modules consisting of some number of conformance
+      test classes, each containing some number of conformance tests) that allow
       testing of an implementation of the standard for conformance with the
       requirements stated in the standard. Every standard needs one of these suites, or
       conformance cannot be claimed with proof. In ISO and the OGC, the conformance
@@ -64,7 +64,7 @@ diagram OGCModSpec {
     definition {
       The requirements in the requirements classes of a standard must be
       tested and the conformance classes are the containers for these tests’
-      definition. The requirements classes will have interdependencies, and this
+      definition. The requirements classes may have interdependencies, and this
       is reflected in the explicit dependencies between the conformance classes.
       If class "a" is dependent on class "b", then to pass the test for "a" a
       standardization target must also pass the test for "b." The class name is
@@ -112,7 +112,7 @@ diagram OGCModSpec {
     }
     modules: RequirementsModule[1..*] {
       definition {
-        Requirements modules that make up this requirements class.
+        A set of one or more requirement(s) classes, recommendations, and permissions with the same standardization target.
       }
     }
     targetType: StandardizationTargetType {
@@ -124,7 +124,7 @@ diagram OGCModSpec {
 
   class RequirementsModule {
     definition {
-      A requirements modules (usually realized as groups of one or more
+      A requirements module (usually realized as groups of one or more
       requirements classes in the standard) group the
       requirements and recommendations in the standard in a manner consistent with the
       conformance test modules.
@@ -138,7 +138,7 @@ diagram OGCModSpec {
 
     requirements: Requirement[1..*] {
       definition {
-        Requirements classes that this requirements module contains.
+        Requirements classes, recommendations, and permissions that this requirements module contains.
       }
     }
   }

From a909de0d4c268ed24eb7364a035fc27b17a07d73 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 15:57:50 -0700
Subject: [PATCH 33/43] Create ogc-modspec-policy.adoc

---
 sources/ogc-modspec-policy.adoc | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 sources/ogc-modspec-policy.adoc

diff --git a/sources/ogc-modspec-policy.adoc b/sources/ogc-modspec-policy.adoc
new file mode 100644
index 0000000..dfdbb2c
--- /dev/null
+++ b/sources/ogc-modspec-policy.adoc
@@ -0,0 +1,25 @@
+= The ModSpec Model OGC Policy
+:doctype: draft policy
+:docsubtype: logical-model
+:status: Draft
+:committee: technical
+:docnumber: 24-xxx
+:edition: 1.1.0
+:received-date: 2025-01-01
+:issued-date: xxxx-xx-xx
+:published-date: xxxx-xx-xx
+:copyright-year: 2024
+:fullname: Carl Reed
+:role: editor
+:submitting-organizations: Carl Reed
+:imagesdir: images
+:mn-document-class: ogc
+:mn-output-extensions: xml,html,doc,pdf,rxl
+:local-cache-only:
+:data-uri-image:
+
+include::00-preface.adoc[]
+
+include::00-foreword.adoc[]
+
+include::01-scope.adoc[]

From dbda971f8b791aac757cd0b0a29d279e25e79bb9 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 15:59:18 -0700
Subject: [PATCH 34/43] Rename sources/ogc-modspec-policy.adoc to
 sources/ogc-modspec-policy/document.adoc

---
 .../{ogc-modspec-policy.adoc => ogc-modspec-policy/document.adoc} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename sources/{ogc-modspec-policy.adoc => ogc-modspec-policy/document.adoc} (100%)

diff --git a/sources/ogc-modspec-policy.adoc b/sources/ogc-modspec-policy/document.adoc
similarity index 100%
rename from sources/ogc-modspec-policy.adoc
rename to sources/ogc-modspec-policy/document.adoc

From 56f5f0d78c7db8c72157e7ce0d3d6793fdbdd700 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:01:24 -0700
Subject: [PATCH 35/43] Create 00-forward.adoc

---
 sources/ogc-modspec-policy/00-forward.adoc | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 sources/ogc-modspec-policy/00-forward.adoc

diff --git a/sources/ogc-modspec-policy/00-forward.adoc b/sources/ogc-modspec-policy/00-forward.adoc
new file mode 100644
index 0000000..77f6202
--- /dev/null
+++ b/sources/ogc-modspec-policy/00-forward.adoc
@@ -0,0 +1,13 @@
+[.preface]
+== Foreword
+
+This OGC ModSpec Policy specifies requirements and guidance for using the ModSpec as the formal structure for all OGC standards documents.
+
+_Attention is drawn to the possibility that some of the elements of this document may
+be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be
+held responsible for identifying any or all such patent rights._
+
+_Recipients of this document are requested to submit, with their comments,
+notification of any relevant patent claims or other intellectual property rights of
+which they may be aware that might be infringed by any implementation of the standard
+set forth in this document, and to provide supporting documentation._

From fb8662f6ecee92962fd9cf0e8bf8fb5fff665ff7 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:05:35 -0700
Subject: [PATCH 36/43] Create 00-preface.adoc

---
 sources/ogc-modspec-policy/00-preface.adoc | 42 ++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 sources/ogc-modspec-policy/00-preface.adoc

diff --git a/sources/ogc-modspec-policy/00-preface.adoc b/sources/ogc-modspec-policy/00-preface.adoc
new file mode 100644
index 0000000..6bade18
--- /dev/null
+++ b/sources/ogc-modspec-policy/00-preface.adoc
@@ -0,0 +1,42 @@
+[.preface]
+== Preface
+
+This OGC member Policy mandates the use if the ModSpec a model and related requirements and recommendations for writing and structuring modular OGC standards Further, this Policy mandates that every OGC Implementation Standard will provide an ABstract Test Suite (confomrance suite)  designed to enable the consistent and verifiable testing of implementations of an OGC Standard that claim conformance.
+
+The goal of this Policy is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
+
+Suggested additions, changes, and comments on this this document are welcome and
+encouraged. Such suggestions may be submitted through the OGC Change Request System
+(http://www.opengeospatial.org/standards/cr) or by creating an issue in the GitHub repository for this document (https://github.com/opengeospatial/ogc-modspec).
+
+[.preface]
+== Document terms and definitions
+
+This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008], which
+is based on the ISO/IEC Directives, Part 2. Rules for the structure and drafting of
+International Standards. In particular, the word "shall" (not "must") is the
+imperative verb form used to indicate a requirement to be strictly followed to
+conform to this standard.
+
+[.preface]
+== Document editors
+
+The following OGC Members participated in editing this document:
+
+[%unnumbered]
+|===
+^h| Person ^h| Organization Represented
+| Carl Reed | Carl Reed & Associates
+|===
+
+[.preface]
+== Document Contributors
+
+The following OGC Members contributed and particpated in developing Version 2 of the ModSpec.
+
+[%unnumbered]
+|===
+^h| Person ^h| Organization Represented
+| Chuck Heazel | Heazeltech
+| Jeff Yutzler | ImageMatters
+|===

From 84a09c56863c2cd0ca2740f64e7c624813b96a09 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:07:00 -0700
Subject: [PATCH 37/43] Update document.adoc

---
 sources/ogc-modspec-policy/document.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sources/ogc-modspec-policy/document.adoc b/sources/ogc-modspec-policy/document.adoc
index dfdbb2c..1e8cc0b 100644
--- a/sources/ogc-modspec-policy/document.adoc
+++ b/sources/ogc-modspec-policy/document.adoc
@@ -22,4 +22,4 @@ include::00-preface.adoc[]
 
 include::00-foreword.adoc[]
 
-include::01-scope.adoc[]
+include::01-policy.adoc[]

From af20b79b40f752c848601850bf258b25f0f5fdc6 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:13:18 -0700
Subject: [PATCH 38/43] Create 06-policy.adoc

---
 sources/ogc-modspec-policy/06-policy.adoc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 sources/ogc-modspec-policy/06-policy.adoc

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

From 865a95eb2058698492fc4af866fc57dec25c34c1 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:17:25 -0700
Subject: [PATCH 39/43] Create 01-scope.adoc

---
 sources/ogc-modspec-policy/01-scope.adoc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 sources/ogc-modspec-policy/01-scope.adoc

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

From 36323f45c88e8c8b52b9fe28c250c9ae769d04e6 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:20:44 -0700
Subject: [PATCH 40/43] Create 02-conformance.adoc

---
 sources/ogc-modspec-policy/02-conformance.adoc | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100644 sources/ogc-modspec-policy/02-conformance.adoc

diff --git a/sources/ogc-modspec-policy/02-conformance.adoc b/sources/ogc-modspec-policy/02-conformance.adoc
new file mode 100644
index 0000000..5dc7c16
--- /dev/null
+++ b/sources/ogc-modspec-policy/02-conformance.adoc
@@ -0,0 +1,6 @@
+[[cls-2]]
+== Conformance
+
+Conformance to the ModSpec by technical implementation standards 
+can be tested by inspection. The ModSpec test suite is specified in annex-A of the ModSpec.
+

From 883ad260325e4ab91749b775ad388e4bdd1ee182 Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:22:31 -0700
Subject: [PATCH 41/43] Update document.adoc

---
 sources/ogc-modspec-policy/document.adoc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sources/ogc-modspec-policy/document.adoc b/sources/ogc-modspec-policy/document.adoc
index 1e8cc0b..c149b7f 100644
--- a/sources/ogc-modspec-policy/document.adoc
+++ b/sources/ogc-modspec-policy/document.adoc
@@ -22,4 +22,8 @@ include::00-preface.adoc[]
 
 include::00-foreword.adoc[]
 
-include::01-policy.adoc[]
+include::01-scope.adoc[]
+
+include::02-conformance.adoc[]
+
+include::06-policy.adoc[]

From 2687d902c7683caa6f940da31a2aa443989e19ed Mon Sep 17 00:00:00 2001
From: "C. Reed" 
Date: Mon, 16 Dec 2024 16:27:31 -0700
Subject: [PATCH 42/43] remove unnecessary entries

---
 sources/sections/ad-bibliography.adoc | 37 ---------------------------
 1 file changed, 37 deletions(-)

diff --git a/sources/sections/ad-bibliography.adoc b/sources/sections/ad-bibliography.adoc
index 57023cb..e0a20a3 100644
--- a/sources/sections/ad-bibliography.adoc
+++ b/sources/sections/ad-bibliography.adoc
@@ -21,40 +21,3 @@ of normative reference in <>.
 * [[[w3c-xml-part2,W3C xmlschema11-2]]], XML Schema 1.1 Part 2: Datatypes, 17 February 2006, 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
-
-[bibliography]
-=== Bibliography for examples
-
-The following documents are either standards or draft standards that in general
-follow the general rules of ISO for conformance test suites. The first two (GeoREL
-and the OWS5 discussion of WFS) meet most of the requirements of this standard.
-
-* [[[ogc08-079,OGC 08-079]]]
-
-* [[[iso19101,ISO 19101]]]
-
-* [[[iso19107,ISO 19107]]]
-
-* [[[iso19111,ISO 19111]]]
-
-* [[[iso19119,ISO 19119]]]
-
-* [[[iso19125,ISO 19125]]], Geographic information -- Simple features
-
-* [[[iso19133,ISO 19133]]]
-
-* [[[iso19136,ISO 19136]]]
-
-* [[[iso19141,ISO 19141]]]
-
-* [[[iso19142,ISO 19142]]]
-
-* [[[iso19143,ISO 19143]]]
-
-* [[[iso19148,ISO 19148]]]
-
-* [[[iso19149,ISO 19149]]]
-
-* [[[iso19153,ISO 19153]]]
-
-* [[[iso19156,ISO 19156]]]

From b3a52b1f1e40f96e8e1069aa7f553deeab280051 Mon Sep 17 00:00:00 2001
From: Chuck Heazel 
Date: Mon, 16 Dec 2024 22:14:50 -0500
Subject: [PATCH 43/43] Duplicate Citations

OMG and ISO 19105 citations appeared in both the normative referenced and bibliography.  Duplicate citations prevented Metanorma from building.
---
 sources/document.err.html                     |  721 ++
 sources/document.html                         | 2385 ++----
 sources/document.pdf                          |  Bin 3332504 -> 2489685 bytes
 sources/document.presentation.xml             | 7233 ++++++-----------
 sources/document.xml                          | 2585 ++----
 sources/document.xml.abort                    | 2676 ++++++
 sources/relaton/cache/iso/iso_19105_2022.xml  |   54 +
 .../omg/omg_uml_2.4.1_superstructure.notfound |    1 +
 .../omg/omg_uml_2.5_infrastructure.notfound   |    1 +
 sources/sections/00-preface.adoc              |    4 +-
 sources/sections/ad-bibliography.adoc         |    6 -
 11 files changed, 7141 insertions(+), 8525 deletions(-)
 create mode 100644 sources/document.err.html
 create mode 100644 sources/document.xml.abort
 create mode 100644 sources/relaton/cache/iso/iso_19105_2022.xml
 create mode 100644 sources/relaton/cache/omg/omg_uml_2.4.1_superstructure.notfound
 create mode 100644 sources/relaton/cache/omg/omg_uml_2.5_infrastructure.notfound

diff --git a/sources/document.err.html b/sources/document.err.html
new file mode 100644
index 0000000..916ed2f
--- /dev/null
+++ b/sources/document.err.html
@@ -0,0 +1,721 @@
+./document.err.html errors
+
+
+
./document.err.html errors

+
AsciiDoc Input

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
_moduleterm reference not in expected format:​Cambridge Dictionary
#<Asciidoctor::Block@592500 {context: :paragraph, content_model: :simple, style: nil, lines: 1}>
1
000606_2b43404f-7def-4d0b-a2e5-1fcde57fa9d4Error: Term reference to requirements missing: "requirements" is not defined in document
+
<refterm>requirements</refterm>
1
000621_8132d980-0554-4a2b-960a-6bd4bff3a809Error: Term reference to requirement-class missing: "requirement-class" is not defined in document
+
<refterm>requirement class</refterm>
1
002156_d4097bf0-eaa5-4d48-b13f-bf413b743940Error: Term reference to conformance-test-classes missing: "conformance-test-classes" is not defined in document
+
<refterm>conformance test classes</refterm>
1

+
Anchors

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
000090_5127019d-9703-94b2-2151-d392c6830cc0Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000123_5664038a-c90f-41ab-bfbf-6669c629144fnormalised identifier in  from Terms and Definitions
<xref target="Terms_and_Definitions">cls-4</xref>
2
000123_c2c40101-dda5-399c-4569-ddfd58d282a6Crossreference target Terms_​and_​Definitions is undefined
<xref target="Terms_and_Definitions">cls-4</xref>
1
000126_67dd03fd-3dc2-a6f9-b5ac-8f17ccce22c5Crossreference target Annex_C is undefined
<xref target="Annex_C">annex-C</xref>
1
000126_ba9a7b3d-d7a7-41e0-85f6-ae8c066b507enormalised identifier in  from Annex C
<xref target="Annex_C">annex-C</xref>
2
000171_81795308-85a8-d659-b8f2-ab49abbba286Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000179_63225180-37d8-b5d0-dcbe-58b8788328c2Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000220iso19105_​2022normalised identifier in  from iso19105:​2022
<bibitem id="iso19105_2022" type="standard" schema-version="v1.2.8">  <fetched>2024-12-17</fetched>  
+<title type="title-intro" format="text/plain" language="en" script="Latn">Geographic information</title>
+  
+<title type="title-main" format="text/plain" language="en" script="Latn">Conformance and testing</title>
+  
2
000278_5e083bae-1002-419d-acbe-adbede48ae92normalised identifier in  from Annex C
<xref target="Annex_C">annex-C</xref>
2
000278_def69548-3806-45ca-3bba-5c1da0e82ee3Crossreference target Annex_C is undefined
<xref target="Annex_C">annex-C</xref>
1
000886_828c1575-f6ae-33c9-5055-82586b512f69Crossreference target Requirement_1 is undefined
<xref target="Requirement_1">req-1</xref>
1
000886_c3b1d058-4622-4109-a358-37146f281fc1normalised identifier in  from Requirement 1
<xref target="Requirement_1">req-1</xref>
2
000925_875f9b1a-e635-e726-a40f-00bce22dcd56Crossreference target term-all-components-schema-document is undefined
<xref target="term-all-components-schema-document"/>
1
000941_72703e4f-47cf-189e-d14a-1116985cd140Crossreference target annex-B-2 is undefined
<xref target="annex-B-2"/>
1
001104_5966d231-3b63-4c29-abbd-1bf1c62df1e7normalised identifier in ​ from term-indirect-dependency-(of-a-requirements-class)
<xref target="term-indirect-dependency-_of-a-requirements-class_"/>
2
001587_58cd33a2-4eb2-8484-d837-a183158c43e9Crossreference target annex-A-2-1 is undefined
<xref target="annex-A-2-1"/>
1
001610_8b2d1036-30ea-4bb4-9f29-c7e41d664618normalised identifier in  from Clause 6.1
<xref target="Clause_6.1">cls-6-1</xref>
2
001610_c9d15222-d5a6-8439-754b-15b0689d81d3Crossreference target Clause_6.​1 is undefined
<xref target="Clause_6.1">cls-6-1</xref>
1

+
Style

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
--Abstract is missing!
2
--Keywords are missing!
2
--Submitters is missing!
2
000044_f5d8b18c-48bc-39d4-765e-c315cfc653e3Table should have title
<table id="_f5d8b18c-48bc-39d4-765e-c315cfc653e3" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
+<th valign="middle" align="center">Organization Represented</th>
+</tr> <tr> <td valign="middle" align="left">Carl Reed</td>
+<td valign="middle" align="left">Carl Reed &amp; Associates</td>
+</tr> <tr> <td valign="middle" align="left">Chuck Heazel</td>
2
000058_18f1cff9-c268-fc8f-944c-0d82334b6180Table should have title
<table id="_18f1cff9-c268-fc8f-944c-0d82334b6180" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
+<th valign="middle" align="center">Organization Represented</th>
+</tr> <tr> <td valign="middle" align="left">Simon Cox</td>
+<td valign="middle" align="left">CSIRO and OGC Fellow</td>
+</tr> <tr> <td valign="middle" align="left">Chuck Heazel</td>
2
000098cls-1Hanging paragraph in clause
<clause id="cls-1" type="scope" obligation="normative">
+<title>Scope</title>
+<p id="_ab28fb11-e5bd-ffbc-2e46-207f6c65db0f">This OGC Standard for Designing and Writing Modular Standards, also known as the <tt>ModSpec</tt>:</p>
+
+<ul id="_c8c40b5a-3342-c347-9470-9934f13b73a6"> <li> <p id="_901e1445-2ed9-5758-1b98-ff4dfb370bc0">Specifies rules for the internal structure and organization of a standard.</p>
2
000692cls-5Hanging paragraph in clause
<clause id="cls-5" obligation="normative">
+<title>Conventions</title>
+<clause id="_symbols_and_abbreviated_terms" obligation="normative">
+<title>Symbols (and abbreviated terms)</title>
+<p id="_189b05f8-d8bd-86ff-6cae-0a71bf9b4a45">All symbols used in this document are either:</p>
2
000945cls-8-1Hanging paragraph in clause
<clause id="cls-8-1" obligation="normative">
+<title>ModSpec Requirements Class: Core</title>
+<p id="_f2e2c084-296f-e1fe-c944-85f274700eaf">The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the <tt>core</tt> of the ModSpec.<note id="_70b49cf5-fe90-d2d5-3348-c645fb3cdb10"> <p id="_54e20bb1-972d-13e9-e471-ab01380d3772">The following requirement is for OGC work only and will be moved to the OGC Policy statement regarding the use of the ModSpec. This move will happen once the policy is removed.</p>
+</note> </p>
+
2
000952req-0Table should have title
<table id="req-0" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ000</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/ogc-compliance</strong> <br/>
+Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard <em>SHALL</em> comply with the requirements stated in this document.</td>
+</tr> </tbody>
+</table>
2
000960req-1Table should have title
<table id="req-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ001</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/reqs-are-testable</strong> <br/>
+All the parts of a requirement, a requirements module, or requirements class <em>SHALL</em> be
+testable. Failure to pass any part of any requirement shall be a failure to pass the
+associated conformance test class.</td>
2
000972req-2Table should have title
<table id="req-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ002</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/all-components-assigned-uri</strong> <br/>
+Each component of the standard, including requirements, requirements modules,
+requirements classes, conformance test cases, conformance modules and conformance
+classes <em>SHALL</em> be assigned a URI.
2
000985rec-1Table should have title
<table id="rec-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC001</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/uri-external-use</strong> <br/>
+These URI identities <em>SHOULD</em> be used in any external documentation that reference
+these component elements in a normative manner, including but not limited to other
+standards, implementations of the conformance test suite, or certificates of
2
000999per-1Table should have title
<table id="per-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER001</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/informational-content-in-core</strong> <br/>
+The informational and structural universals of the standard <em>MAY</em> be included in the
+core text and its associated models without violations of the ModSpec. This is
+true if the requirements of the extension are not implicit in what is
2
001013per-2Table should have title
<table id="per-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER002</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/core-may-contain-schema-terms</strong> <br/>
+The core <em>MAY</em> contain the definition and schema of commonly used terms and data
+structures for use in other structures throughout the standard.</td>
+</tr> </tbody>
2
001020per-3Table should have title
<table id="per-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER003</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/core-names-of-operations</strong> <br/>
+This may include the list of the names of all operations and operation parameters
+to be used in any request-response pairs defined in any conformance class of the
+standard. If a service receives a request that is not supported in its
2
001032req-3Table should have title
<table id="req-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ003</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/vocabulary-and-parent-req-class</strong> <br/>
+Requirements on the use and interpretation of vocabulary <em>SHALL</em> be in the
+requirements class where that use or interpretation is used.</td>
+</tr> </tbody>
2
001039per-4Table should have title
<table id="per-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER004</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/external-vocabs-core</strong> <br/>
+Importation of external vocabularies and schemas <em>MAY</em> be in the core.</td>
+</tr> </tbody>
+</table>
2
001082req-4Table should have title
<table id="req-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ004</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/single-standardization-target</strong> <br/>
+Each requirement in a conformant standard <em>SHALL</em> have a single standardization
+target type.</td>
+</tr> </tbody>
2
001094req-5Table should have title
<table id="req-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ005</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/modspec/test-class-single-standardization-target</strong> <br/>
+All conformance tests in a single conformance test class in a conformant
+standard <em>SHALL</em> have the same standardization target.</td>
+</tr> </tbody>
2
001106per-5Table should have title
<table id="per-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER005</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/repeated-requirements</strong> <br/>
+If needed, a requirement <em>MAY</em> be repeated word for word in another requirement up
+to but not including the identification of the standardization target type.</td>
+</tr> </tbody>
2
001124per-6Table should have title
<table id="per-6" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER006</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/abstract-superclass</strong> <br/>
+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. This is
+diagrammed in <xref target="fig-6-1"/>.</td>
2
001145req-6Table should have title
<table id="req-6" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ006</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-grouped</strong> <br/>
+Requirements SHALL be grouped together in clauses (numbered sections) of the
+document in a strictly hierarchical manner, consistent with
+requirements classes.</td>
2
001153req-7Table should have title
<table id="req-7" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ007</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-test-suite-structure</strong> <br/>
+The requirements structure of the document SHALL be in a logical correspondence to
+the test suite structure.</td>
+</tr> </tbody>
2
001190req-8Table should have title
<table id="req-8" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ008</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-class-correspondence-to-conformance-classes</strong> <br/>
+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.</td>
+</tr> </tbody>
2
001204req-9Table should have title
<table id="req-9" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ009</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/no-optional-tests</strong> <br/>
+A Conformance class SHALL not contain any optional conformance tests.</td>
+</tr> </tbody>
+</table>
2
001217per-7Table should have title
<table id="per-7" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER007</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/conf-class-paramterized</strong> <br/>
+A Conformance class may be parameterized.</td>
+</tr> </tbody>
+</table>
2
001238req-10Table should have title
<table id="req-10" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ010</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/all-parameters-expressed</strong> <br/>
+A certificate of conformance SHALL specify all parameter values used to pass the
+tests in its conformance test class.</td>
+</tr> </tbody>
2
001247req-11Table should have title
<table id="req-11" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ011</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/conf-class-single-req-class</strong> <br/>
+A Conformance class SHALL explicitly test only requirements from a single
+requirements class.</td>
+</tr> </tbody>
2
001259req-12Table should have title
<table id="req-12" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ012</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/con-class-dependencies</strong> <br/>
+A Conformance class SHALL specify any other conformance class upon which it is
+dependent and that other conformance class shall be used to test the specified
+dependency.</td>
2
001295req-13Table should have title
<table id="req-13" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ013</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/imported-requirements-class</strong> <br/> </td>
+</tr> <tr> <td valign="middle" align="center">A</td>
+<td valign="middle" align="left">If a requirements class is imported from another standard for use within a
+standard conformant to the ModSpec, and if any imported requirement is
2
001312req-14Table should have title
<table id="req-14" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ014</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/all-classes-explicitly-named</strong> <br/>
+For the sake of consistency and readability, all requirements classes and all
+conformance test classes <em>SHALL</em> be explicitly named, with corresponding requirements
+classes and conformance test classes having similar names.</td>
2
001330req-15Table should have title
<table id="req-15" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ015</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/req-in-only-one-rec-class</strong> <br/> </td>
+</tr> <tr> <td valign="middle" align="center">A</td>
+<td valign="middle" align="left">Each requirement in the standard <em>SHALL</em> be contained in one and only one
+requirements class.</td>
2
001345rec-2Table should have title
<table id="rec-2" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC002</strong> </td>
+<td valign="middle" align="left"> <strong>/rec/core/parallel-structure</strong> <br/>
+If possible, the structure of the normative clauses of the standard <em>SHOULD</em>
+parallel the structure of the conformance classes in the conformance clause.</td>
+</tr> </tbody>
2
001359req-16Table should have title
<table id="req-16" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ016</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/co-dependent-requirements</strong> <br/> </td>
+</tr> <tr> <td valign="middle" align="center">A</td>
+<td valign="middle" align="left">If any two requirements are co-dependent (each
+dependent on the other) then they shall be in the same requirements class.</td>
2
001374rec-3Table should have title
<table id="rec-3" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC003</strong> </td>
+<td valign="middle" align="left"> <strong>/rec/core/circular-dependencies</strong> <br/>
+Circular dependencies of all types should be avoided whenever possible.</td>
+</tr> </tbody>
+</table>
2
001380req-17Table should have title
<table id="req-17" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ017</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/structure-requirements-classes</strong> <br/>
+There <em>SHALL</em> 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.</td>
2
001401req-18Table should have title
<table id="req-18" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ018</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/>
+No requirements class <em>SHALL</em> redefine the requirements of its dependencies, unless
+that redefinition is for an entity derived from but not contained in those
+dependencies.#</td>
2
001431req-19Table should have title
<table id="req-19" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ019</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/profile-conformance</strong> <br/>
+The conformance tests for a profile of a standard <em>SHALL</em> be defined as the
+union of a list of conformance classes that are to be satisfied by that profile’s
+standardization targets.</td>
2
001442req-20Table should have title
<table id="req-20" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ020</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/core-requirements-separate</strong> <br/>
+Every standard <em>SHALL</em> define and identify a core set of requirements as a
+separate conformance class.</td>
+</tr> </tbody>
2
001449req-21Table should have title
<table id="req-21" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ021</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/>
+All general recommendations <em>SHALL</em> be in the core.</td>
+</tr> </tbody>
+</table>
2
001455req-22Table should have title
<table id="req-22" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ022</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/requirements-and-dependencies</strong> <br/> </td>
+</tr> <tr> <td valign="middle" align="center">A</td>
+<td valign="middle" align="left">Every other requirements class in a standard <em>SHALL</em> a standardization
+target type which is a subtype of that of the core</td>
2
001465rec-4Table should have title
<table id="rec-4" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC004</strong> </td>
+<td valign="middle" align="left"> <strong>/rec/core/simple-core</strong> <br/>
+The core <em>SHOULD</em> be as simple as possible.</td>
+</tr> </tbody>
+</table>
2
001471per-8Table should have title
<table id="per-8" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER008</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/core-type</strong> <br/>
+The core <em>MAY</em> be partially or totally abstract.</td>
+</tr> </tbody>
+</table>
2
001477per-9Table should have title
<table id="per-9" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER009</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/req-class-another-standard</strong> <br/>
+The core requirements class <em>MAY</em> be a conformance class in another standard.</td>
+</tr> </tbody>
+</table>
2
001483rec-5Table should have title
<table id="rec-5" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REC005</strong> </td>
+<td valign="middle" align="left"> <strong>/rec/core/optional-tests</strong> <br/>
+If a requirements class is from another standard, the current standard <em>SHOULD</em> identify any optional tests
+in that conformance class that are required by the current standard’s core requirements class. See <xref target="req-13"/>.</td>
+</tr> </tbody>
2
001494per-10Table should have title
<table id="per-10" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>PER010</strong> </td>
+<td valign="middle" align="left"> <strong>/per/core/core-maybe-recommendations</strong> <br/>
+Since the basic concept of some standards is mechanism not implementation, the core <em>MAY</em> contain only
+recommendations, and include no requirements.</td>
+</tr> </tbody>
2
001516req-23Table should have title
<table id="req-23" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ023</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/core-and-extensions</strong> <br/>
+Each standard conformant to the ModSpec <em>SHALL</em> consist of the core and some
+number of requirements classes defined as extensions to that core.</td>
+</tr> </tbody>
2
001523req-24Table should have title
<table id="req-24" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ024</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/extensions-conformant-to-the-modspec</strong> <br/>
+A standard conformant to the ModSpec <em>SHALL</em> require all conformant extensions
+to itself to be conformant to the ModSpec.</td>
+</tr> </tbody>
2
001536req-25Table should have title
<table id="req-25" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ025</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/restriction-of-extensions</strong> <br/>
+A standard conformant to the ModSpec <em>SHALL</em> never restrict in any manner
+future, logically valid extensions of its standardization targets.</td>
+</tr> </tbody>
2
001558req-26Table should have title
<table id="req-26" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ026</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/optional requirements</strong> <br/>
+The only conditional requirements acceptable in a standard conformant with the ModSpec <em>SHALL</em> be expressible as a list of conformance classes to be passed.</td>
+</tr> </tbody>
+<note id="_61c51519-40a9-ed25-ac7f-d2adfcfd7889"> <p id="_f4e6c737-d2a3-6ebb-edeb-2251c9e710a5">Standards and implementations are restricted by this, but not instances of
2
001576req-27Table should have title
<table id="req-27" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="center"> <strong>REQ027</strong> </td>
+<td valign="middle" align="left"> <strong>/req/core/req-class-overlap-by-reference</strong> <br/>
+The common portion of any two requirements classes <em>SHALL</em> consist only of references
+to other requirements classes.</td>
+</tr> </tbody>
2
002095annex-BHanging paragraph in clause
<annex id="annex-B" obligation="normative">
+<title>OGC Only: Changes required in the OGC Standards</title>
+<note id="_b37e62e1-9150-ac84-bf8a-eed002ecf6da"> <p id="_26a1a2db-74fd-baf5-c5e0-85ca8d2b73eb">The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards</p>
+</note>
+
2
002178fig-C-1Figure should have title
<figure id="fig-C-1">
+  <image src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAsMAAAMaCAIAAADsqNxGAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAKT2SURBVHhe7f37c9RWtv6P6w/9/pBKCly2yzbl/+BUzUxOCBh7INjBp+o750zOkEDACTGGeObNBAjgQDCYMiRcfMLBXJ37/To5n7UvWlraW+qWutWyLs+rVoFa2lK3tdez9tO71erg/wAAAAAAegVOAgAAAAC9AycBAAAAgN6BkwCgdwJQIvakAwAqBsQJQO+o4e3XrxAlBJwEAJUF4gSgd2rqJH7/5UuKf/38hYnffvrcxK8/fmbilx8+/fn7LRM/fffMxI/fPjXxwzdPKL7/+jHFd189MvHtlw9NfPPFpomvP3/w1Wf/a+LLT++b+GLrExOfP/sfE5893fj0yT0TW4/vmnj26I6Jpw9vU9BrhpMAoLJAnAD0DpwEnAQAAOIEoHfgJOAkAAAQJwC9AycBJwEAgDgB6B04CTgJAECR4iSpg0TsCQKNQ3WuN05XP+AkAAAFUrCTkNUKYQIVsMHAScBJAAAa6yRkrZRVkkukUx+5OMqy6NdEWQ25DnIplEUQFbANwEm0wElsLU/Sk08ub9nHAAAHOAk4CdA7cBL1dRJkELK5g/V5uAgAOgInAScBegdOoiFOgtzCpJp5mF83MxCK+XXaED5UTZ1NHfaKNhHhs3Abs8LbBYDaAicBJwF6Z2A5v7E8ocYYYn7N2ZQn1maCYGZdLUcHVGsyO4lH7wzNXnn205WpIJharY+TMH+nfeARjeEaNbCvz7NxEAO/GeLtnETCpg570SazKtxG/1vLoJsk7AJAbYGTgJMAvTOonA8dwNapkWBiYcvZ2kuszAtTItXRyUk8ODoeBMpJ1GdOgpplbCnGcnYLygAIwnX6/4RNHfYKN8ndpV9IeiIA6gqcBJwE6J1B5bxyEvHZCO0t5udoNeFOM4QtvTXWkYj1c3qNUse9d8kmaF5d1U7i4TGetphY/Pjn7z9aGrMPZw9EcxKr++3KYPT1B0YvKy8Hwcv71Usmdrx9dxuchHluwj7OQKKTSJofsNsSNnXYy3MS0dPppXVMRIAGAScBJwF6Z3A5r2YjDHMrak3kLbQtmFuJpiueLEzyBIYxGeGURrTAcxJmzS9fbi1R4+kbJJBr07SwJjTyZHE4GHvzkZyTCD/d2DwxFAR7ryqx3HxnNAj+/M/QSQT7L5FkzpDNGD2+VqaTUKeof4lFAz+N8+aQhBnreZu3qcNenpMQbcxj/4kAqCtwEnASoHcGnfPaHIwsP5GewH7ksWznJwyqzTqtcT4KSXcS67NBMH78WfzTjbWD9nBpTkJNSIwe2dRiefDWzmD09fvhnMRlJZkbJ0ZKchLmZRL2MQBg+4CTgJMAvTOgnI/mG9TAz04iZU5C7mV8Q2yvLHMSw6cffr5G3uLg+73OSZTnJGiBlwEAVQBOAk4C9M7Acj66smHy1IZaox1A2nUS9hOQlL0SnYS8TmLi5B2lkVWyFPrh+HAQ7LumZHKe3AWR5TqJEpxEIdieqyr2VYIKY7sKCAbjJNQHtyG2xmWJsA7m2CU1+nYSqiYa9l9McRLnXgyCF9/XTuLjN57f9x6cROtQnevl3kAi8gQFhFQHC4Q1ImXiK0WKhfWiJaPMd6L/LspJ8DnnZQBKBrmXyCCchPy+mVq2b4+6h9yx3+jXSVzaHQS7P/hi85PjO4KRv210npO4+Z/qTRycRPsIc37wAScR1xE9NNjHAJQCUi6R4p2E//GtCXU5mCH6AJhna0eWn0QTs2QmkhqPTFKDiYV19WGwXibmFuxeppmYC9m1dE/VSn1d+qtmijYYPrVJJfLj6Ltt+ovyP357c3HUrnllRToJNRsR1cT3XwqCly6parh6fCgYOXo1nJO4cmzI7B1M/fPy0Z12ee8ZOInmozo3zPAaRQOcBKPEBomBskCyJVKSk4iuBQuvF9PmwMxA8LyFnZPo2Nhs5avJ9IIyEHpBPh29BuskzNflL6gL2xdvP14cphH/GtVHcxHZd8/URWTmcvRP3hgL9lwJy+L9hR20r2L6Hx2dRDQn8dHrzwU7/3KLKuCNvwwFfzgLJ9F0VOeGWVejaJKTMCidauzjboQ3hgq/qpnI+jy+nQkcsudYqyjJScjvp9kGek6C7YJ0Eh0bGyehl3mlcBKxyYxwTkJ/V/7OqXHlJK4fDIKxo49EfYyuIFPsPLERlUWqhurTjWDHW3cyOYnze+xRNM8duQEn0XBU5+q0rFc0z0kwSnldW5KPMBaCFzycmz8AYOieXa2keCdhPmIIr42w8w3R8B+bZkh2Eh0bd3ISykboqzWt/0hyEvE5iaGT98WchC6OpiyqCYmRw59QQby4WziJFxY+pmq4TAftMieB6yTagc35ukWDnYSBGndoTy4h9AfOPawFekv6ZtBScuVhexiAk6AQ1yuYoZ0i6dKHZCfRsXHHOQm1RjE5odskOQl5ncT4iVu6PkbXSdjvx6uyGH13Y/T4mq6J1xbILxDD/z7tzEk8Pb1Pb5HXSQS7F+EkGo/qXJ2W9YrGO4nOkJMI/YFYBCADqOeJDMZJVCBkrZRVkkukUx+5OMqy6NdEWQ25DnIplEVwEBUQVA04iZo6ie5zEgAkgXqeCJwEnAToHepcUBr2pPcPXx7BCwBko8g8bBBwElV2ElvLyxnfL0UtqTaGpNdI+6NC2Y8PkqGzLLOuLiHVwQJhjUiZ+EqRYqnpnAQRyiTUCE9TiPkKAHyKzcPGACdRLScRq2PZP8PllnKytmtNzH58kEKlcj57wEkA0BvIw0TgJCrrJGiRdjVvmuwyYYf+aAVtFy3F/hH+Dxyr/9c7HR9kg86YzLq6BJwEAL2BPEwETqIqTiIazDXWFuiBXdgDuyrcEiIf07I4hiLZSXQ6PsgInWWZdXUJOAkAegN5mAicRGXnJKJhXVz6QIReQD5MNgDhRx3dnETS8UEm6HzJrKtLwEkA0BvIw0TgJGrgJJJ9gsG4BdFSGIFwbegoos3enITZDvICJwEnAVoF8jCRgp0ESMSeoLzQCE87q0HeLBmcx9oaRC1jEwyhPwjXTRJxJ2EbuccHGaHzJUfoikd0w7dgZPmxcRJ33126GHMSq9P6Bm5wEgAkgDxMpGAnIcvW9kZN5yRAvUjM+a1TI+Hd4qsUazN8w9nfHy/smlh4Rup4dHzXbNxJYE4CgHSQh4nAScBJgN4pwEmszeibuyt4L548MDePV23mZvS00cjymr0Vvd6kf5gmeqjvHG9uMO+H2BSq4+6742rfiZN3fludnhhXd4OfO6jnJK7uGx+zP5Zvbir/03e37E3l9+89OPrGJpwEaCXIw0TgJOAkQO84Oa9/FCYik59Ym7E/LsMjPU8eyDX+wtyKsCxkKewP03QK9Qs1hvDTDZ6TWJ0OZi8ojZhPN67uMz+Z+/ODo+NjRx5+9+zhiaHxEzeVWC7vDeAkQFtBHiYCJwEnAXonMedzz0nYxivzxiUk/YKdbSMWyEmI6x4I+8P6WeL3Xy4dCmZuxJ3ExMk70kmMv/ORVsr5We0kVg8MLd43n26cxZwEaC3Iw0TgJOAkQO8k5nyfToJ2dz+qSHESUcsMIV/V77/cW57I5yQwJwEAgTxMBE4CTgL0TgE57zkJ5RIMEzPz5jOLFCchr5OIfmE/nNjwQ85hHLoefrpBD2YvdHUSuE4CAAJ5mAicBJwE6J1K5Xz2kOpggbBGpExYKbE5if3vGbHASYC2gTxMBE6iWk6CGudqD7YX1Vle7lU/enASP3137qDJzmBo8RMrFjgJ0DaQh4nASVTFSVCzjC1BaXTtFLXVy73qR09OwipFigVOArQN5GEiRZ6USlXVujgJ2mqwj0E1sL0isBviqPVe7lU/4CQA6A3kYSJFnpRKVdXqOwlan7YJbCOmX9KwjULUGi/3qh9wEgD0BvIwkSJPSqWqamWdBD002MegMtiOyYDdoWI5nz3gJADoDeRhIkWelEpV1Qo6CVrgZVApTNfkxewos25gsbF8St/1MvrKaIawjcN9RXRxEpvHou+WEgfOxZzE5b1jb9/s7iQu7h49dj2Tkzj7p+E3LisFvffHqX/CSYBKgzxMpMiTok5xvGBtY1TKSYAGI7PORL47U2WJJwuT5v7ZuZyECd5XRHcncfC8kcnP3390cmzo5H3hJAqfk9BO4uM3njfnc+j1y3ASoLIgDxOBk8CcBLBdkxezo8w6E3mdRMLvddndzb2q7O2n1EraZH/Ki3/Uw/sRL2qjfxJsnlqeWuF96Vn41pm76LCPF3aNH1c/B5rRSVyZGh9Vv+l1cL+ek/hgz9joTnXoIBhbuKElc+OE/dWRHW/fDeck3n9pZPols3rmvNXOxSn9OAimz4k5iff+GOw5dX5PYKYl4CRANUEeJlLkSVGnWJW2SkQFnYSBHhrsY1AZbMdkwO7g5Tx5CNPAkMlP2LtVJt0bm+96KeYknJ/7Us9opxxW5s1tLvmA5ji8b7hAuxy6nuPTDftboFemgv1nlVguWycRjL7+gPSycXhs5PD9rx7dX9gRzJxRqrn7t9Hpf7CTCIZf21DCWZ4J/v0Saef8i8HUspLPrf8aHvqvO+wkhIJYRHASoGogDxMp8qSoU6wqWiWisk6CofVpm8A2YvolDdsoRK3xcq/nOQn397qSnISziZ4r/OmNjeUJ/SNe3MZxEqoBWQ39b45PN0KlXJnie1zaOYm31rVezhzQTuLyTLD/klANz0kcu6aFs7ow/MLCx7E5iQBOAtQN5GEiRZ4UdYpVwapEVN9JGGirwT4G1cD2isBuiKPWe7mXy0lEViCcZiAH4M5SdHQS/pxEipPQL2xCvTapjqKcxP2FHaMLN5Rq7v5tdORvn6TMSdw9+sL0eS0fzEmAGoI8TKTIk5JYVbcr6uIkGGqWsSUoja6dorZ6uZcvyDcY+Pe6lCcwa2jgD50EPSRD4DmJ5OskHCdB2yK3oeYtlDqyXieR1UlkvU7i/Iv6URAMvTg99OIFOAlQK5CHiRR5UtQpVtWqElE7J2Ggxrnag+1FdZaXexUO6z+kOhKchJCJrxQpFtYLS8ZVTfTphhIOa4flYxRk5AMnAaoP8jAROIlqOQlQL+rkJPTkh5m3gJMAoDeQh4nASWyHk9hanpxc3rIPQI2pVM5nj/KchFYNnARoDMjDROAkSncS6/pDcDiJRlCpnM8ecBIA9AbyMBE4iZKdxNby8jrmJBoDnAScBGgVyMNE4CRKn5Mg4CSaApwEnARoFcjDROAk4CRA7xSa8/zFTj8SfoWre5jvf4aEN7BSEXcSd0+fvJDkJD5aGrP7WkaPbF7eO35C/XwXnARoJ8jDROAk4CRA7yTmfK47U4lIdxLi7lI5IraXvZOEeRhzEo+OT8wmOolwTkLdSULdMNsoRYoFTgK0DeRhInAScBKgd4pwEuGtpeZm5kMnEf9NL9tAH9O7DxXZhWz+g18VH/zQNTUh8e64Wp44eee3n+6c0svE7NUUJ2HmJD7YM7Z/j56w2Hli5bCZudC3yuabUwX7L8JJgAaCPEwETmI7nARoCk7Oq3tXC7L4ich28K9zpd8tW3gU/fMZaiE94k7C3vJSH1ypg+9xGc5JPD05PLF4W8vk9tLYvmsdnUQw+saDrx9/v7In0De4/G7l5WDmjLlhtpbM2tsju1fgJEDjQB4mAicBJwF6JzHnc81JrM/xhw7Rpxvub3qFniBar4g+rUgOb07CTGNEB4k7ibVZu1ozvPSgk5MYe/um+nRjZY/5SXHjJC6HN/7W7HjrDpwEaBrIw0TgJOAkQO8k5nwuJ+HPSfCQnzgnIS+c7BIxJ2F/38scIW1OYm5VaUTKJJeTuL+wY/8lXCcBmgzyMBE4CTgJ0DtF5Lx3nYS+rbWCf9OLPAE9VLYguk4iML/8yW7DD7NXiLUg4uCHxqdvGCdBD5WZiK6TCIIun24kOgl5nUQQ4NMN0ECQh4nAScBJgN6pVM5nD6kOFghrRMrEV4oUC+uFJZOoGjgJ0BiQh4nAScBJgN6Bk6iIk6CtnRsAUAhIs0TgJOAkQO9UKuezR5OcBK3nXrDLAAwMJFgicBJwEqB3KpXz2aMZToLWJJ5/ux6AAYDUSgROAk4C9E6lcj571N1J0HLXM2/bAFAoSKpE4CTgJEDvVCrns0d9nQT9m+uc2/YAFATSKRE4CTgJ0DsDyPkOP9bV0+94eSFubzXy7iMjkDvmR7wiJ3F13/g7H1XNSRDyD8keZl8ACsGKHwjgJOAkQO8k5nyuO1O5EbudVDw6bMoefLdsUsej4+bmVL89PGZuThU5CcxJAAAyAycBJwF6JzHn8zmJ6P5RI8tP5I91RZMH+qZSYpP5BQ21e3iD7dhB9MMOt6uiTbFPN+6eDn/E69fV6YnxYVqePajnJD6cGh8bUtuCYPzELa2Um4uj+vH+Pa+Mvv6gdCdh0K+gS7WxbQAAgwdOAk4C9I6T8+Qh1PAVksVPuDfA5okHPXlg17BdCDc5TsI9SOd4srDLvsDw0w2ek1idDg6+r2RiPt34cCoYO/qQZHL/yPjYkc1vn26eGFL3uCSxqB/x2jYnYTB/Q+xP02HXAwDKAk4CTgL0TmLO5/x0Y2VeDXxEOJ0QfoSR9jteCXMSzkH07h0iVMfFQ4G6YbZ0EubnQNlJ0L9aJudmtZNY3T+0eN+I5b1tnJOQmD/b/F12GQBQLnAScBKgdxJzPqeTCMNMQoR2IZpmSJqTcKcrOHhTSpjXFqrj7rv6pzeyO4lKzUlIaGvnBgCAwQEnAScBeqf/nKehXY2BinBOghbJDZAnMCT8jlc4AzExYpxEwkEchyFC/jT5oWvhpxv0YPZCVydRkeskAACVorFOojqBCthgaprz0mez1Wa3LQ2347ljcxJ//ic7bzgJANpMwU4CJGJPEGgcqnO9cbr60bOT+PHbswdNTgc739nY5rtlAwAqQpPFidIDBo3KMW+crn704SRiHwXCSQAAiMaKk+oOSg8YNCrHvHG6+gEnAQAokIY7CcI+BmAAqATzxunqB5wEAKBAmilObSEsdhUAA0AlmDdOVz/gJAAABdJ8J0HYtQAUjcoub5xGDCIgZAAqSwPFqc1DDLsBgKKxGQZKwZ50AEDFaIWTIOw2AFoP5AAAKJam1RTjG3zsZgDaDeQAACictjgJwrYAoMVYMUAOAIDiaFRBsTUyBdsIgLZilaCxqwAAoG9a5CQI2w6AVmJlEGLXAgBAf7TISdhGALQSKwOB3QAAAP3RtGpia2QStgUArcTKII7dBgAAfdAWJ2E3A9BKrAw87GYAAOiDBpYSWyPj2G0AtBIrgyRsCwAA6JVWOAm7AYBWYmWQgm0EAAC90sw6YmtkiF0LQCuxMkjHtgMAgJ5ovpOwqwBoK1YJKdhGAADQK42tI7ZMolAC0NFM2BYAANArDXcS9gEA7cbIwcduBgCAPmhyKUGhBIAx1sHBbgMAgD6AkwCgFRjrILEbAACgP+AkAGgLxkAwdi0AAPQHnAQAbcEYCINdBQAAfQMnAUCLMDaCsI8BAKBv4CQAaBGwEduCOe0AVAGblIUCJwFAu4Auyked81+/QiC2PeAkcoOKCYAPdFE+cBJFxe+/fMnxr5+/kPHbT5/L+PXHz2T88sOnJn7+fkvGT989k/Hjt09l/PDNExnff/3YxHdfPZLx7ZcPZXzzxaaMrz9/wPHVZ/8r48tP78v4YusTGZ8/+x8Znz3dMPHpk3syth7flfHs0R0ZTx/e5qATCCeRG1RMAHygi/KBkygq4CTgJMoGFRMAH+iifOAkigo4CTiJskHFBMAHuigfOImiAk4CTqJsUDEB8IEuygdOoqiAk4CTKBtUTAB8oIvygZMoKuAk4CTKBhUTAB/oonzgJIoKOAk4ibJBxQTAB7ooHziJogJOAk6ibFAxAfCBLsoHTqKogJOAkygbVEwAfKCL8oGTKCrgJOAkygYVEwAf6KJ84CRUrM3QeYiYW0lqMLPurIxH5CSuU+PpGxmdxOp0EOy7DicBJ9EDAzplANQa6KJ81Dn3BsXWhTIKI8tPvOU8ETmJXHMScBJwEj2DigmAD3RRPnASKhKdhF6YnAiCiYUttaznJPTC/BydNsLssrFMbTSHrsfnJK6RS5g+NGs2Tq+RjXh4LGwbTCzehpOAk+iLAZ0yAGoNdFE+6pzzgNraUP4gYvLUBq+cX+MG7CTMypV53XLr1IjZpA3EzLrrJIJD17747ac7p8eDYPYCz0k8WRwOxo89gZOAk+iHAZ0yAGoNdFE+6pyb0bTNofyB94kGuwe5HK1UUxHkJNbn9KRF4nUSek6CFsg9PD2prMPTnz5fs1MUAZwEnES/DOiUAVBroIvyUefcDJZtjj6cRHxOYmT5cac5CWUjZi9gTgJOohhQMQHwgS7KB05CRR9OQl4nsWvpXpfrJJRvUEyMD6s1cBJwEv0woFMGQK2BLspHnXMzWCL6i+jTDf7uhvh0Q4b91kYY5CFMwEnYpCwUOAkA2gV0UT5wEkUFnAScRNmgYgLgA12UD5xEUZHgJMKAk4CTGAiomAD4QBflAydRVMBJwEmUDSomAD7QRfnASRQVcBJwEmWDigmAD3RRPnASRQWcBJxE2aBiAuADXZQPnERRAScBJ1E2qJgA+EAX5QMnUVTAScBJlA0qJgA+0EX50DkHoCLYpCwUOAkA2gV0UT7qnHtvrxE9BOYkMCdRNqiYAPhAF+UDJ1FUwEnASZQNKiYAPtBF+cBJFBVwEnASZYOKCYAPdFE+cBJFBZwEnETZoGIC4ANdlA+cRFEBJwEnUTaomAD4QBflAydRVMBJwEmUDSomAD7QRfnUy0msz9HrNYwsPzErN5ZPrcg2/7c2M3lqI7amlICTgJMomwGdMgBqDXRRPuqce4Pi1qmRbRmMu8TaTDAXmoYnC5MTC1tmgVdua8BJwEmUDSomAD7QRfkU4CTWZiYnRug4BO/Fkwfza2GbuZlJtWJkeW1BL5hNG8sT+gG3ZIvgR8Imu7t63vBlzNMTiYd2q2gczM3Mpz1FHwEnASdRNgM6ZQDUGuiifNQ5F8MheQhaw2TyE2szAU8PmAWePJBr/IW5FWFZaJifWVcLHYMOaF9a+OkGrTHPxU9qPt3gJwpfQ/RcvKnQgJOAkyibAZ0yAGoNdFE+6px7g2LuOQnbeGU+HKGjCxpC38CjeDScz62I6x4IvvQhS6zMB9p5CCcRewrvVa3P8fGj11lgwEnASZTNgE4ZALUGuigfdc69QbFPJ0G7ux9VOMO8XjBzErZlhoi/qnAOI7OTiHbHnAScRDNAxQTAB7oon0QnkS+8MVsN1YaJmXkz3jvDvGmjHEB0nUTAcwzpw7ycw4jMCj2gQzlP4b8qXCcBJ9EwBnTKAKg10EX5qHPuDYqNjNichJnGKDTgJOAkygYVEwAf6KJ82uMk1OQE/bWKXBdkZA04CTiJshnQKQOg1kAX5aPOuTcoInoIOAk4ibJBxQTAB7ooHziJogJOAk6ibFAxAfCBLsoHTqKogJOAkygbVEwAfKCL8oGTKCrgJOAkygYVEwAf6KJ8tslJeD+7lRrcssPtpMzXO4u6jjJ8xuh7pJkizUncmKXXZhg+/dA4idunFt+POYmr+yYWP87nJD7YQ0cce/umdRIbr4+Nvv6gg5O4tHv/JeUkPpim/Xa8fTfmJDaO7QiCFxZuZ3ESy9NDf73Tu5NYmtr5l1uPPjiyk17F//8mnEQ/DOiUAVBroIvyUefcGxTj94AaQPDtpLpG1LKDk+iwKX9kf23xSHYS16aD2Yt2NuLhsYnxY0/JSWwemzgYdxI9zEl8sIdthHEVQbqTuL9ARkE3Ob6mzYTjJK6/NbxD2ojBOwla+ODIjueO3ICT6IMBnTIAag10UT7qnHuDYk4nwXeXMrMC0c2m7M2j6M197Me0bAPzFO5vfcWOJltGt71KPJq+bWXqU6uf9Ur+CTHnBYhntHMSqcckzJ9g76aV6CQeHd81fpzcgzUTKu6cGlf7Tize/nV1emJ8mJZnD+o5iQ+nxseG1LYgGH/nI20gbp0c048PTB0cPbKZ7CRuLr79Xpc5iUu7g5kzl2eC/ReVgUh3EtcW1MtRzJzXHuL8v48Mv0APp89fPW5e2tSLoZO4esy+2GD6rHYSZ/80vPN5erjvvctv7jRbgql/Ghtx+ahZ8/If4CQKY0CnDIBaA12Ujzrnavy2QR6C1jB2pOwYahfzJl6/m48eqvs32BtcOj+mFb3v55tEhZuco0UthZNwjxZuSn5qs4b3kgu0iRvw0fgZtZPI9OfoYBsRcxLaTIRWJPx0g+ckVqeDg+9Hn258OBWMHX30/dbPD46Ojx19+N2zhyeGxk/cUpbiylSQ6iSyfbqhg9xDipN4aeWz/9049kIw/Xc9J/H3meDfL2knEexbJktx9+gLI0evqjmJ8y8G2kncOfL88JGrek6CLMWf3tdOIthz6tMn9z5+4/nhNy7rOQkyEH88//juR68/N/T6ZTUnceYPgXUSd87uDvaegZPogwGdMgBqDXRRPuqch2MhBw2fWTyECXpPH04nqKB9w4f0bl7PUtg397QmdAORPxA3wNabnKOJlmJOwjlauNDpqZMWjEVwXoDvJLr/OTpSnUR0xeWFV4PptbiTmFi8LZ3E+Dsf6Y82zs9qJ7F6YOjkffPpxrn0OYk+nYSakHjrjrrikpzEzPvm041rC8MvLHys5yTeXCUncXHqheMfxT7duDBlT5vm+WM39ZyENhDn9YctIc8dXb97fo/6N/7phrri8uxuOy1BJ5Ca2qQsFDgJANoFdFE+6pyHYyFHLicRNdbv0deT3sS7Q284WkfjtN7XuAF5tC0e13nfhIE8chKpT520QI39F8CvzbTsdMzoBahIdBLPlkZ2Ld3lzzVOj+dzElWYkzBOInFOYvpc/DqJ0El8/Mbz+96LXSeBOYmBgIoJgA90UT6JTiJn8JUE6ddJOEMvjda0mUZoGs4N/FtfztG4Je+bMJDzQvpTJy0kvwDx2nTLbH8OLSQ5CQrx3Y3g1dXw0w16QGaim5PIdp2E5yQ2Do+NHL6vF0ZpIZOTSL9OQjuJL7Y6XScRBPbTDeMkPn0SXScRBOrTDVwnMRAGdMoAqDXQRfmoc64GRUS/wTbCcRIU4ZyEDTUbIUI5CR3mKxscPzlzEvvPso1IcBJ57ifhOYkHK9PZv7uhwkxFcNg5iXz3k4CT6BtUTAB8oIvygZMoKgbhJH767lw4ozG0eD+yEcZJ0Fo2E9mdRN/3kyjESeB+EkUwoFMGQK2BLspHnXNvUET0EINxElFIG6GcRDgbkddJyGAnQcEeohQnocJ4CDiJ3kHFBMAHuigfOImiAk4CTqJsUDEB8IEuygdOoqiAk4CTKBtUTAB8oIvygZMoKuAk4CTKBhUTAB/oonzgJIoKOAk4ibJBxQTAB7ooHziJogJOAk6ibFAxAfCBLsoHTqKogJOAkygbVEwAfKCL8oGTKCrgJOAkygYVEwAf6KJ84CSKCjgJOImyQcUEwAe6KB84iaICTgJOomxQMQHwgS7KB06iqICTgJMoG1RMAHygi/KBkygq4CTgJMoGFRMAH+iifOAkigo4CTiJskHFBMAHuigfOImiAk4CTqJsUDEB8IEuygdOoqiAk4CTKBtUTAB8oIvygZMoKuAk4CTKBhUTAB/oonzgJIoKOAk4ibJBxQTAB7ooHzgJREUCTiI3qJgA+EAX5UPnHICKYJOyUOAkAGgX0AUAoFjgJABoF9AFAKBY4CQAaBfQBQCgWOAkAKgA6/OTy1t2ecBAFwCAYoGTAKAktpYnU+0CnAQAoLbASaTQqeqHrM/Pr9tFALoSzyl6RBlK6HWhk1ifNysDm1rcyjRzHvYE7WyXAACgCOAkkjDlvGOtjo8DAHQiMgAayhm1xpgFWqIF4yQo8XilTiyzkXEe9ga9ALsEAABFACfhs7W8vM6lPBVd9LnyA9AVmVNu5nhzEqFF5RXO9s7Z2Qna2S4BAEARwEmk0NVJAJATmVPRslnSToIWrb3w08+xHq4TyQGcBACgWCpWUwq97gxOAlQYyjDKUELnGX+6YdfNz2tTwY1MM+dhb9DOdgkAAIpgG2pKpzEaTgKAAQMnAQAolm13EvwuS6/zPi2OJnvtCr3deZgCbbZLPSBfJS/LlQDUk750AQAAHqXWlMgAaGhQVmuMWaAlWuA5Xl6pR26zkXEepkFPYZcAACHQBQCgWLahpoT2QOFeN+bNSYSTDtEHyPHtfKQEaLNdAgCEQBcAgGLZZicRLZsl7SSiKQfZ1OBYD9eJxEDFBMAHugAAFMu21xQyC1TZCG0Z+NMNuy7HFez0wC6FZFkDQLOBCgAAg6Y5NQVOAgCfLirwp/18cFd4AEBHGjWyOkWz80MAWkKqEMzkX0cnEZ8zBACABBo1uFK9s0uazg8BaAkpQsBd4QEAxdC0wVUWzbRlANpGqhayfLoBAAAdadr4CicBgA+cBABgcDRtfIWTAMAHTgIAMDgaOL5yofQXAGgtyXKQToKXYS8AAHlo4BALJwGAD+QAABgQzawpplbKfwEAUAQAYBA0s6bASQDgA0UAAAZBM2sKnAQAPtAFAGAQNLaaUKE02McAAOgCADAA4CQAaBFWFdAFAKA4mlxQUC4B8IEuAADFUmRN0W91QAL2BIE2Yfse5MSePlA6tgNAxbDdU20KdhL/9+tXCCfqkgqgWCCHHgJi2UaQsRWMuiiisU7i91++pPjXz19Q/PbT5xS//vgZxS8/fPrz91sUP333zMSP3z6l+OGbJxTff/34u68eUXz75UOKb77YNPH15w+++ux/Kb789D7FF1ufUHz+7H8oPnu6QfHpk3sUW4/vUjx7dIfi6cPbFPRKUBzbSZXrsq8OXyCsESkQqRFHJqQRRyZdlQKxVIoqZ2wPIZPcz3OT6n62c8I7Oe+nvUx+J/99CbAKHCH4WmA51EsRcBJwEmAgVLku++rwBcIa8auqU1L9SuqU0TSlQCyVosoZ20PIJPfz3KQ6nERRwEnASYCBUOW67KvDFwhrxK+qTkn1K6lTRtOUArFUiipnbA8hk9zPc5PqcBJFASexzU6CtnZuAGqK6lYvLSsSvjp8gbBG/KrqlFS/kjplNE0pecUCBkqVM7aHkEnu57lJdTiJooCT2DYnQev5jNll0CC4cysYvjp8gbBG/KrqlFS/kjplNE0p2cUCSqDKGdtDyCT389ykOpxEUcBJbIOToDWJ58quB40gsYsrEr46fIGwRvyq6pRUv5I6ZTRNKVnEAkqjyhnbQ8gk9/PcpDqcRFHASZTqJGi561mybUDN6drR2xi+OnyBsEb8quqUVL+SOmU0TSmdxQJKpsoZ20PIJPfz3KQ6nERRwEmU5CTo31znx7YHtSVXd5ccvjp8gbBG/KrqlFS/kjplNE0paWJJQ2sCohgU6tx6qVLt2Fg+teKttCGT/F/XpidO3pF5blIdTqIoinyVlUpEv1Y6hdLJG6dK+lki86NzffSLY89nxuwLesPm5TahXoDXoRUJXx2+QFgjflV1SqpfSZ0ymqaURLHY0xdH96c9n3YZFA2f4drEk4XJOTiJSgAnUYaTMCcn1/mx7UGvbPvZUy/A69aKhK8OXyCsEb+qOiXVr6ROGU1TSppYJEoGSWfSrgfFkXietyHWZibnZiZV944sry3ohWB+jTZtLE/oB/GHk6c2aK/1Ob3BbpKNR959FDmJtVmzMphb1U5i881xu2Lo5P1nP90/wg8X78NJ5KDIV6n+ZjKJuh8U6W7Ri7DXc+zSJXp3EhuHx/RrUUz/Q2XJxd1B8NJKf07CYI4qX6cftg3oj20/h+oFcLeuzeheZWbWeVPeUIfqY3cdWZzEo3eGZq+kOAmpkZkzkUYKdRLm8PJl+2HbgCLoerYHFTRqTCxsUWLTv/QwcWFuZevUiDENerzQEuA5Cd0gOtSvX1HjYPaSSvJHx3fNXrROYnU6mL2g8nzz2MT4scc/fPp4cXj2w8g3Pzyhct4kvMr5T94YG31j84M9wejrD+AkOlLkq6S/eT6yhCu0HHZ811CNwx2LiV6dxD8PBMGBFZMrZ/YHwejxtQKdhIHWqJXea7brQRFs+5lUL4A7lyodvcF6Yh4q35xZGgOJ7k7iwVF6c5biJKxGdEmNa6QgJ6FkkCSQtLDtQX/kOufFBRX/mfXQAag1azNWHWKBjALPOmi0mthJiDkJYz7o4aHrUZL7cxLBuHISv/xwPlyh5yS+O8cP7ZwE2Yj97z14a+fYW+twEh0o8lWq88/ZIMLpY11VZ+btSkoInoZSZiKp8cgkNZhYWCebaZaJuQW7l2lGKaUfESb5fr+unuWQzYvh0w+pUN4+FU5dkQ/VNuLWyfC91cEPVJWkjAlGDt+PT9tGTuL2a/QKDCNHr+q0uHpsyK4ZfuOyTojLR3baNUOHVZbTgj1BcUwbc4rsMiiObT+f6gXozlURcxJssmOZrzeFayZm5o3b0GLRMxCh/+A1Qhpb3qHUe7I0sYjGh65pJ0Hv1YLpuYNm3fDSg4+WQl3MXrm1OGqXx96+KTXCJTXSCFVSqZE3V3UNFRo5ckVXz8tHI4184DgJQp+K3GH2bTM283pFHcE7qwMPVbpn1imZbXKqxGYDwQtmTsJ9txk6iWhT6Ehoza6le8pJPDq+a/z4M+0knp4cfnVVO+ZwToLfWP784VRw4Fz03vLy3mD/WeskRt/4kHJ+9HWT83ASiRT5KlUuczaEoStaVArVHJSqgKbecUm1cxIdG9viqMqxrqHWk0YFOmyjX4N2EqpQ/uvni6/S6zp558niMJXL65Q6lDTB1KqeywrGjmxS3tw/MhbsudrVSYT5cffoC8HQX+9QWpx7MQieP3ZTvNP65x+D4LkjNzrNSUhoa+cGoDe2/ayqFxCmpUnjiLD8Wb2YYirFotZkcRJCGgmHShaLbWyKbDC9Zp2E+uT41x/fJ+89/s5H0ZzEFRJL7DPjLk4ilMm9N18Ihl+7SzX0vNbILVFA31MaOboeVU9HLOoUybPXLWz7dtP/GVBH8M5tGUGZSQlJiWpyOMVJSAcsZcLDhEJZ8EgvGnGdhM5zxfj03LgaCx6rQcGg5iTUiGDROY9PNzJT5KtU59+kggg1xxCutCVM9Xq8OIZOomNjUxz1Mq8Mi6N9IoM+gpmTuKGmtu6eHldOYo3eco0rH8qfbqwesHtodi5+0t1JXNpnW1snIeYkgj2ndEJEcxLB7kV6YfS/PUGgRLb9tKsXoPNWhcpYHtdNzouMVaitIv8935DsJKw0/EN1EIvT+PRDOyexpj7duL00FncS30VzEsH+97I4iZWwXFsnIeYkgr2ndfWM5iSCl5d8J2Ew2+0JTAnbBhSR8OoI3hmub8iP8PxP8cwHedGchPd5d/wTPVxx2YUiXyX9zfaNlOpIO98QVTRjEq1/jNbo9p3nJMyabsUx/j7PdxLxOYnQgZo5Cb5OYuP1sSAYW7ihs8S9TkKVyH3LlBzRnASnhXqb9cfzIiGenvlDEPyBXiQq3baw7ac9VpdVxqpEDdM4HOxD32wiynD9Ziv0DWbHcAKPk9+RRtqhPLHYxvI6iU5OIrxOgt6Z6Xk71oguqe51Ekoj038njURzEnydxNk/BcGfzsvqqSbw/nAuxUkYaE3sTIZh14OQ/s+GOoJ3nusbcBJlUuSrVH+zroAWPbRTRO+BTLGLKqDrJDo27lQc9RrF5IRt4zsJeZ0E1UqdNNF1Eub9lntduvPdjfdfMqtHhl4IghcvUFrc+i+eHbPXSaz/JZog63idBBgo237a1QvQeatC5ad1EibbdXpru2ywYgnX8HUS/hpOfiGNqBnBljpNLLLx7MVkJ/G9vRJt9gR/L85eJ+FqxPnuBmtkmDTy7xephn7010gj5jqJm1Ij7nUS9vTFMY31XwoPkUz/50QdwaZTEwJOokyKfJWVSkSZRjKBOHWcvOGMkbkis0Tmh8wMmRYyIWqXCg1j2097f3JQg712Es76YsJXhy8Q1ohfVZ2S6ldSp4ymKSWvWGhr5wZtpv8zo47gpUp9Qya5n+cm1eEkiqLIV1mpRPRrpVMonbxxqqSfJTI/OtfHXMURDIhtP+39yQFOAuSj/1PXX8ZWLmSS+3luUh1OoiiKfJWVSkS/VjqF0skbp0r6WSLzo3N9RHGsAtt+2qtcl311+AJhjfhV1SmpfiV1ymiaUiCWAun/1FU5Y3sImeR+nptUh5MoiiJfZaUS0a+VTqF08sapkn6WyPzoXB9RHKvAtp/2KtdlXx2+QFgjflV1SqpfSZ0ymqYUiKVA+j91ImOjK2nM5WsUW/7tHLpH3qm1sH3sGqAuYV+Yt4tM8nieRxfMWcaOPirCSWwc2zHz/rUFvizIMPRXed2xIwRfCyyHeimiyFep/mbRkdsbfq2Ek2gV237aKyUHJ3x1+AKBk6gX/Z+6KGPDUdl+zYfW6Evpy3MS7vr0SH9hMsn9PKe4fjAIDp53sp0T3sn57k7izn+P0ll7X+U/hbpfgP6in5EAq8ARgq8FlkO9FFHkq6xU6fRrpVMonbxxqqSbJXASdWPbT3ul5OCErw5fIKwRv6o6JZU1UgcnsT4/ubxll4tlcEfORP+nLspY5STk8CymKE5F386zQ762HeKexaI9f+FIfKdP7OXdoTX5C0ohcyveccQLmwt3iX8B8Bkl+TX11aRXw/sdn9pMchL6a8+G8RM3Vc5f3hsEO8fIHYy+8eDr9XfMXVVGXj4wEoyq2wTcODGi1wTB/ouU/2tvhVMRxkxIJ3FR3QpxWalA3cnwxff116H37THN7b0D5I2I9p6Bk9AdWYWAk2g5237aKyUHJ9rgJLaWJ5NGdjiJVGTG6m8Ra8z3k723/tF0RWQ7vHsI6b2sdUjdyzxXvD07CR3aGfCXqMNdnMmScBc+2u+/3FM+Q/98F+3/6iol+QV1v+PF2ybVE+ck1E2GRvVNhpSTEL+iEOy5Qjmvv/9MTuL+wg51fzZK/rt/Gw12f9B5TkLd5lXdNeCCshSn9Y1Vgn3vkRAuv6kOvERC+Oj154Kdf7lFcrjxl6HgD2fhJCoScBItZ9tPe6Xk4ET7nAQ9omPTmDMfjvfhGlq3rpuQE6CNck1im0m7Kjx4tiOn7aVXrM+HLWl12CIvdCy71CvqCPE80aOyHsKFk+h6fyDVwGwK13TcS29y2ksnoZYjO+Iex3MSfDTK8K2lkUD/6Ia6XYpK8jvq3kIpTiK65XHkJNSt2CjnP/wzrTS/u6GmIshJXFYvitnx9t3On24sq1dw7rT+N3aLto/feJ4MxEeP7563UxSG547caLeTAInYE1QqjX3vlZFtOu0RputBXuzpy0Ba+2gk11C2RgM0Ddp6SQzZtKjH8XCTXlJrOrUJt0VtshxZ7GW9g2kSNgz/7wX6S+1Sr6gj6NE6PnMQcxJqnOZbn7mewPoAnhXgOYaOe0WzCNw+2qrX2HkR4xKc43hOgo8Wn5Po4iSuvRKYX/CKz0lYJ9FpToLfbXa8TkJ9wKFQMxNd5iRCY91qJ2H6uwrRnjmJsDo5wElsswIrJQcn6j4nQc26tpS6EClrF2lwF9hVYSO7a8c2fJxwRbTG7qBJ2yuchLAYC9GPkSgg4dURbIZE1x+EkwH6xqw0ZqvLERR8N2HfSUS7x657UCTtJZ7Ou05C24IQsg7+cWIvzB5QzlvwdRJd5iTUTygoxseGgmDvatxJfN/xOglzK+SvP//Hn/Uj/zoJFfpOr8NH1C9ImzmJDtdJBLsXSxs+iqLIV6n+ZpsZ2x9tdRL0SKVig2dxM0JPaZe2CfUCvLSsSNTUSag80tjHHZEpFi1TCuolWhMmf0i4SS+pjYltwmPapYxHTt0rXFL/E7ZZL2Q8LR1QR/BSpb4hk9zPc5PqfrZzwsdyfkX96Iyak/jqzAE9J2Ey3xkjOP99CWgnoX4Rl52E+XTD1wLLoZzhoyiKfJWVSkS/VjqF0skbp0r6WSLzo3N9zFUcHahx9vZUfUx7A5WhqEKJuhaWJ1rUJS6pYqa2CbdFbbIcWexlvYNpEjYM/x8gdELs0jahXoCXlhUJXx2+QFgjblXdDieh8ruvDlWZqEjywdYJ0yif7rCjNjbneSnbkdP2CqWoNkXLvUDHsku9oo7gpUp9Qya5n+cm1bM6CZ6TIPSHGibznTEizUmoX3wkpk5bIcBJdEb9zV53blf4tdIplE7eOFXSzxKZH4NwEirVekoaqkmiGrmLVJ8EdlXYyO7asQ0fJ1wRrbE7aNL24qJsoGekFebfwUKvyS5tE+oFeGlZkfDV4QuENeJV1fKchMosjX08UESKbwf9Pn3/Z0kdwUuV+oZMcj/PTapndhK4x2UXinyVlUpEv1Y6hdLJG6dK+lki86NzfexcHB1oq8E+zo90EtFy+A4nYdAON/FAn9gmPKZdynjk1L3CJfV/f7O4GennlBaCegFeWlYkfHX4AmGN+FXVKal+JXXKaJpSOohFSaLkHux3KO8D0lQ0EdIj/Z8udQQvVeobMsn9PDepDidRFEW+ykolol8rnULp5I1TJf0skfnRuT6mFUcHWp+2qQ9opNbHbe4sbkboKe3SNqFegJeWFQlfHb5AWCN+VXVKql9JnTKappREsfSJPfv1x/49ebB79oo6gpcq9Q2Z5H6em1SHkyiKIl9lpRLRr5VOoYy+PRwMLd43SXPznbf+GSuRF3ePHl8zWSLzo3N99IujPUEa85SEfVw+0Xi/LZT09Nt5hjXqBXhpWZHw1bFm7wBIDC89MLX1o5Mn1Pfioqr6wZ6xt28O2knw2eNlUA7qhHupUt+QSc55zgMBnESxFPkqExNx69RI+D2iUsOvlTEn8eGU+fawypv7R8ZHj2xSxnzyxtif405CZInMj871serFcRudRBGzuBnZ9lOtXoCXltslBydcdaxOB7MXrEA23xzXP2ik7h+sNeJXVaek+pXUKaNpSukgFgM9NNjHYJCo8+ylSn1DJjmPAjwQmLEATqIoinyViYmYr3SuzegvCit4L/5ysLnDmmozN6OnzEeW1/R9S+ym6DvQ9FCl0eOFXePHnyU6CaqSY0ceirz54Zubi/rq3LGFG9+tvDw6soOW90/rOYmLu0eH1UNi5M1VnRxXjw/px1MvTg/95+1uTmIQ2JNef+zfMwDsE2wT6gVwYoexXXJQLZ8sTJqb+fhO4uGxifFjT6RAvv9oaUztO37i1o+X946PqnQ/uH+PmpNY2TM2Yr/5br4O980Xa2+blzn90szwaxvFOQlGH705OV9N1BnW6dGMgJMokyJfpZOIsZuKiFLYKdZmojuX8a3Q+MbvvMZfmFsRNZpq6My6UysdJ0F5c/9I+JMt4acbPCex8nIwc0Zlifl04+LuYPi/qT5+dfu1keHX7n16/+7RF0aOqnuMqF9kyeAk+PzwMmg8qq9VNtrYZjmohShcJ2HMhH1p4acbPCdxeW+w/6wSiPl0Y2WP+iIcyWTj8Kj+Rtwnx3eQTFQlvfBSMBgnYTCvj7CP09GTX0TH2bf1+XKmx+qCOWWgatjuqTZFvkr1N8cLFkXuN2G28cq8KYvxG5aZQmnbiAUqnVEzxcjy425OInKgZw8Ge9W9zISTsG+2Qicxeuy6dpp/p7dc5CQuTr1w/CNTH09nmZOwJ0hjXh9hH4OGorpYJ7CMbZOD+PUjigQnEQnk/GwwdS3uJMZP3JROQs3bqTdnZ/ZrJ/HBtP7dAfWe7B8DmpNwMH+VfeDDF/WmX93rXwkM1CkVSVL3kEnu57kZCzAnURRFvsrEROyzdNLu7txsSumMWurwayVnDyXNo3eGxk/cCvPm5uJoPifR25yEA61P2wQagOrcMBs5tksOTjjqeHpyeOLknVAgHy+N5XMSpc1JOGgBJbQnlxD6A7ISKfMOekv65jaiTqaXKvUNmeQ8CvBAYMYCOImiKPJVFpCIXulUZdGgbsmuJ2lTSqf8YFjdgJ3SqMN1ErHvbgQHL4efbtCDmTNdnUTe6yTsCUpCH0VhH+eESqEGs7iVQ/WpyuQ+okA50Ho2H0k+W3x3I5j9UNdWchL04MC5rk6ihOskckFOIkx4sQi6oU6+To9mBJxEmVTMSRQXfq10nISTN5wxMldklsj8iM1J7D3t1MfeiiM1y9gygidvecEDs7jbhepNLy0rEr46fIGwRvyq6pTU2JzE9N/9MuoXUKd6Fls3M81JAI8qZ2wPIZPcz3OT6nASRQEn0YuTML83r3n+2E23PvZTHM1B7YNuYBa3yqh+9NKyIuGrwxcIa8Svqk5J/eaLf+w3iRvsWLidUEZLdhJZHDbwUSffS5X6hkxyP89NqsNJFAWcRG9OolN9HEhxTAKzuFWmynXZV4cvENaIX1WdkupXUqeMpillcGIhC6EJfQSbbuG+gYM6+V6q1Ddkkvt5blIdTqIo4CTq7STCqohJh8pR5brsq8MXCGvEr6pOSfUrqVNG05RSplhAV6qcsT2ETHI/z02qw0kUBZxEjZ0EZnGrTJXrsq8OXyCsEb+qOiXVr6ROGU1TSqliAd2ocsb2EDLJ/Tw3qQ4nURRwEnV2EpjFrTCq3720rEj46vAFwhrxq6pTUv1K6pTRNKWULBbQmSpnbA8hk9zPc5PqcBJFASdRbycBKkuV67KvDl8grBG/qjol1a+kThlNUwrEUimqnLE9hExyP89NqsNJFAWcBJwEGAhVrsu+OnyBsEb8quqUVL+SOmU0TSkQS6Wocsb2EDLJ/Tw3qQ4nURRwEnASYCBUuS776vAFwhrxq6pTUv1K6pTRNKVALJWiyhnbQ8gk9/PcpDqcRFHAScBJgIFQ5brsq8MXCGvEr6pOSfUrqVNG05TSPrFsLS8X8hUrc5yt8LZzIf1dGkUHkElS95BJ7ue5SXU4iaKAk4CTAAOhynXZV4cvENaIX1WdkupXUqeMpimlDWKJXfpMDwr5srZznPX5Qq6urnLG9hAyyf08N6kOJ1EUcBJwEmAgVLku++rwBcIa8auqU1L9SuqU0TSltEEswknYKQTzMPzWVXgfGHIDk2rz/LptFszPhwYhXGMbx46jEE4iurGMeWLaRIeJ9jUb9ONojYXWyCSpe8gk9/PcpDqcRFHAScBJgIFQ5brsq8MXCGvEr6pOSfUrqVNG05TSbLFEI7ZGDfa0yozePOCb8V6s4RVqjV6K1vD+fByDnJNwmoQH4SdIOFoIvUiZJHUPmeR+nptUh5MoCjgJOAkwEKpcl311+AJhjfhV1SmpfiV1ymiaUtogFjFyx8ZuGtgtZnPoBmLzC3oxaqnQqxwPIJ2E3Ra2iDbZF5JwtBB6LJOk7iGT3M9zk+pwEkUBJwEnAQZCleuyrw5fIKwRv6o6JdWvpE4ZTVNKG8RiB3B+oMf38H+xORzyo/bhdELUmHFWxZyEPgIRP4heUvskHC2kyhnbQ8gk9/PcpDqcRFHASdTQSUTFBhRNcee2ynXZV4cvENaIX1WdkupXUqeMpimlDLFUCsou+gtpJOeZAXUVgx7ZY5MHelPSdRKxKyXYEcSdhLQPalP6dRLiEAp6LJOk7iGT3M9zk+pwEkUBJ1E3J2FqUEGjHYhR6LlV/e6lZUXCV4cvENaIX1WdkupXUqeMpill4GKpITTO2wS0kwg9IJyFazI6UeWM7SFkkvt5blIdTqIo4CTq5ST098ijYgMKpOBzW+W67KvDFwhrxK+qTkn1K6lTRtOUMmCx1JRovqKXRNR7Rw4ETgJOohTgJOrlJDRwEoMDTgJOoq1UOWN7CJnkfp6bVIeTKAo4CTgJIOh4bqkrs/emaumlZUXCV4cvENaIX1WdkupXUqeMpiklr1j06a9HYa0UGc+bauOlSn1DJrmf5ybV4SSKoshXWalE9GulUyidvHGqpJ8lMj8618dcxbEX4CQGR4ZzSx2apU9VGy8tKxK+OnyBsEb8quqUVL+SOmU0TSnZxaJPuT2fdhnkxJw3wj72UJvieVLrkEnu57lJdTiJoijyVVYqEf1a6RRKJ2+cKulnicyPzvUxY3HsHTiJwZH53FK3GuxjD7XJS8uKhK8OXyCsEb+qOiXVr6ROGU1TShax6HOccCbtepCftFOnVnrnub4hk9zPc5PqcBJFUeSrrFQi+rXSKZRO3jhV0s8SmR+d62PX4giaBPVvYherlV5aViR8dfgCYY34VdUpqX4ldcpomlI6i0Wf1y7n0LYB+TGnjrCPq52xPYRMcj/PTarDSRRFka+yUono10qnUDp541RJP0tkfnSujx2KI2gq1MsG+7jaddlXhy8Q1ohfVZ2S6ldSp4ymKSVNLPpE5jh7tj3oCT576l/v3NY3ZJL7eW5SHU6iKIp8lZVKRL9WOoXSyRunSvpZIvOjc31MLI6gJVB3mx5X/3ppWZHw1eELhDXiV1WnpPqV1CmjaUpJFEvP583sC/rBOaW1Dpnkfp6bVIeTKAo4iTKcBGgnMiErFb46fIGwRvyq6pRUv5I6ZTRNKYliMZUk19mz7UFP8NlT/3rntr4hk9zPc5PqcBJFASdRhpOwJwi0AOpu0+PqXy8tKxK+OnyBsEb8quqUVL+SOmU0TSmdxaJPZJdzaNuA/JhTR9jH1c7YHkImuZ/nJtXhJIqiyFdZqUT0a6VTKJ28caqknyUyPzrXxw7FETQV6mWDfVztuuyrwxcIa8Svqk5J9SupU0bTlJJFLPqkJpxJux7kJ+3UqZXeea5vyCT389ykOpxEURT5KiuViH6tdAqlkzdOlfSzROZH5/rYtTiCJkH9m9jFaqWXlhUJXx2+QFgjflV1SqpfSZ0ymqaU7GLR59ieT7sMcmLOG2Efe6hN8Typdcgk9/PcpDqcRFEU+SorlYh+rXQKpZM3TpX0s0TmR+f6mLE4glpD3Wqwjz3UJi8tKxK+OnyBsEb8quqUVL+SOmU0TSl5xaLPN9SUm4znTbXxUqW+IZPcz3OT6nASRVHkq6xUIvq10imUTt44VdLPEpkfnetjruIIagd1aJY+VW28tKxI+OrwBcIa8auqU1L9SuqU0TSlQCyDRqdq1lOqWnqpUt+QSe7nuUl1OImiKPJVVioR/VrpFEonb5wq6WeJzI/O9RHFsalQV2bvTdXSS8uKhK8OXyCsEb+qOiXVr6ROGU1TCsRSKaqcsT2ETHI/z02qw0kURWOdRHUCxbGdQA49BMRSEkl3hUfGVjDqooiCnQRIxJ4g0CZs34Oc2NMHBsf6vDrRSU4CVBDbPdWmObqtyxkHoHygDhCytby83pJfAUTal0ZDTrRybkgaAJKAOoALnAQolEY5CcI+BgCEWG1AHYBpgZOwSY+0L4UmnGWbLxq7CgCgscLQ2FUAwEmAQmmakyDsWgAA1AESgZMAhVL7s2yTRWA3ANB6rCQEdgMAjcakuvwXDJTan2JVHT3sNgDajdVDHLut5phvMiZ8l1GyPj+/bhdBqzB5Lv8FA6Xep1hVkiTsZtBO1ucHOXGrv0RXB6wYPOzmWkM+wvQxL3hsLU+av7fps/ggAZnnchkMiGY6CcK2ADWhNp/b0gutyftcq4QkbIvaIrKFrERKf+gt6ZtBY/EzvAE5X3FqfH51SUzFNgI1IeYk1ucnJ9Ubyvl1fmPJ4wENDebxvJ15iGYgwiXzf4eD0CbaW62YXF63G/WmpJb6IIQ+tm2glqO24fNXCfvSUrCNagud+zAfxCIAGj/DG5DzFaexToKw7UC1iUZkjTEBPLCHo7QdMKI11MYshf4hWjL/px9E7hstaMeR2pK3hVvC/yuKPZvp2Hb1RPRU2M0AhHB6+wtgQNT4/KpymI5tBGqCGBvU6GCWaZQQqHWRbRCNwlXxNdEju79Gr+NdxAKNR51a8lLkILh52KRK2JeWgm1UX+jcm7POCwBoZHqnLYPCqffJVUUxBdsC1IREJ+G/74+aybHENOJtZvf0g/AmuWDmJFJbdjgcv4CKYZWQhG1RZ+isa8L+4d7nBdBKZHqnLYPCqffJVZUkCbsZ1JRo/KZhwfZpeOlCuIavk4jGFEKvMbt3OAhvEgt6S3pLXjJN5MUXVX1TbF+dh90MQBORGZ62DAqn9idXlUYPuw00mWiQB2lYPcSx2wBoHE56d34ICqT2Z1aVxjh2A2g4cBLdsZIQ2A0ANJHOGY78HxxNOLO6QkbYtQAAqAMAMHia5iTsKgCAxgpDY1cBAEChNKS42EqJWgmAh9UG1AFaBnK+NBrlJOwDAIAA6gDtBGlfGs050UgaANKAOkALQdqXBpwEAM0H6gAtBGlfGnASADQfqAO0EKR9acBJANB8oA4AwOCAkwCg+UAdAIDBAScBQPOBOgAAgwNOAoDmA3WAFoK0Lw04CQCaD9QBWgjSvjTgJABoPlAHaCFI+9KAkwCg+UAdoIUg7UsDTgKA5gN1gBaCtC8NOAkAmg/UAQAYHHASADQfqAMAMDjgJABoPlAHAGBwwEkA0HygDtBCkPalAScBQPOBOkALQdqXBpwEAM0H6gAtBGlfGnASADQfqAO0EKR9acBJANB8oA7QQpD2pQEnAUDzgToAAIMDTgKA5gN1AAAGB5wEAM0H6gAADA44CQCaD9QBWgjSvjTgJABoPlAHaCFI+9KAkwCg+UAdoIUg7UsDTgKA5gN1gBaCtC8NOAkAmg/UAVoI0r404CQAaD5QBwBgcMBJANB8oA4AwOCAkwCg+UAdAIDBAScBQPOBOkALQdqXBpwEAM0H6gAtBGlfGnASADQfqAO0EKR9acBJANB8oA7QQpD2pQEnAUDzgTpAC0HalwacBADNB+oAAAwOOAkAmg/UAQAYHHASADQfqAO0EKR9acBJANB8oA7QQpD2pQEnAUDzgTpAC0HalwacBADNB+oALQRpXxpwEgA0H6gDtJB8ab8+P7m8ZZc7sbW8vG4Xi2F9nl6oIXoFW8uTsccVB04CgOYDdQBQDDTEzxfoJJSN4OMp+2DNQ1ZfUxHgJABoPlAHAF0wYzf9O6lmAwg7lJvZAbvCPjCbeDLBWgF/32hnsyI6VrSLbWmhY86vh82cbRUGTgKA5gN1AOBC4zUN1TR0mwE7dBLRoK8X6P/YHAQ/1mO+XRMewd83aqMNgtnOR7H/CcI1ocUw+/CRqwqcBADNB+oALaRj2msjIMZ2O3ZHkwS8RC0N+rEY/HlDzIuYLXpJP4deoYnaK2yLcBdLuIvYoFfJV1pB4CQAaD5QB2ghndKeRmYan2mQFgO2WvTcQIQZ5EMnETkKHuS9faPhXy+tezMQ+qCR26BW4esRz65fJO0bvdTqAScBQPOBOkAL6ZL2ZpxnM2HG7iQ3QMfRiMc0+CsPoJmcn49/IiGWeG/zWBws8g98oLCVWcl70AK/yKoCJwFA84E6QAtB2pcGnAQAzQfqAC0EaV8acBIANB+oAwAwOOAkAGg+UAcAYHDASQDQfKAOAMDggJMAoPlAHaCFIO1LA04CgOYDdYAWgrQvDTgJAJoP1AFaCNK+NOAkAGg+UAdoIUj70oCTAKD5QB2ghSDtSwNOAoDmA3UAAAYHnAQAzQfqAAAMDjgJAJoP1AEAGBxwEgA0H6gDtBCkfWnASQDQfKAO0EKQ9qUBJwFA84E6QAtB2pcGnAQAzQfqAC0EaV8acBIANB+oA7QQpH1pwEkA0HygDgDA4ICTAKD5QB0AgMEBJwFA84E6AACDA04CgOYDdYAWgrQvDTgJAJoP1AFaCNK+NOAkAKgI6/OTy1t2OU76loxAHaCFIO1LA04CgGLYWp7sb7yHkwCgSJD2pQEnAUAxxJwEjf3z85OUlMHk8vqyXgjm12kDtdIP7EOxZp520PtHviFcsv/7+2aFdrFLALQGpH1plHmi099YpW/JDpIGbBfRCK9Rybw+r/9TuR0tzK+rltYF6MfSf4iWdg0v6f+jlmqnfF6CXpVdAgCAoslRX0Qh640inYRfGbOsAWBwxATCKS0WjJMQUxFqi8j9cDFaFVtDBxDwXgnQZrsUkmUNAAD0Ro5q4hbKbZ28pTZ2KSTLGgAGhysQsywWjJMIk7vTnIRtw9v0QehRV10YoA4AQJlkqiaq/AlUcZNVT5S/jIXSruGlsFCG6zPVTHoldknT+WGEeJpU1uczlmwAkhEGghdCQSgREWGOhWvYaqummklCr7EHifbtaraphV3SdH4IQCNBnpdGjhMdG4JTCiW1EfVRbeHtUdNoVWxNWD4NvFcq1MguaTo/tJjn6HhsrtbdXwEAVYUS2C5pOj8EoJEgz0sjx4nO6CTCN0v6sdyLVpglu0Vs0wehR13eZ3nIRElbFmwtL6/H/4wk9Mvj1whATcmpDgCaBlK9NHo90SlOQryl55E4XFPo5K2B2tml7LWyq5MAoBH0og4AGgRSvTTqfaJ7qZVwEqAd9KIOABoEUr00an+iOVf8hWTgJEBryK0OAADIT+3LSu5aKZ0EL8NegCaSWx0AAJCfJpQVUxzlvwAAA9QBABg0TagsqJUApAF1gNaChC+NJpxo1EoA0oA6QGtBwpdGQ040ZYzBPgYAhFhtQB2gZSDnSwNOAoCGY7UBdYCWgZwvjeacaCQNAGlAHaCFIO1Lo8cTTT0E+sSeStAsbO+CvrEntDXYPxuAimETtCO9O4n/+/UrRM+RsXtA7YA0CokWCgSZg6hgZFRiY53E7798SfGvn7+g+O2nz038+uNnFL/88CnFz99vUfz03TMTP377lOKHb56Y+P7rx9999cjEt18+pPjmi00TX3/+4KvP/tfEl5/ep/hi6xMTnz/7H4rPnm5QfPrkHsXW47sUzx7dMfH04W0KenktLJQtoRbjQUZ1sECMOlggpA4WiFEHC4TUwQIx6mCBGHUYgRh1QCCSWmROjcIkuUx1Ds55mfkcRgJSBVILMlgXUh0cRiZyKHEkI4Ujw4hIDjSOoKSsOFhfrDIOlpsUHQerT2owrxLhJGI5IZPA6XjZzU7XOn0pO8/pqrzdA2pHLcaDjOpggTi1UtZHpyDKCuiUPFnjnKIGgRC1yJwahUlymeocnPMy8zmMBKQKpBZksC6kOjiMTORQ4khGCkeGEZEcaBxBSVlxsL5YZRwsNyk6Dlaf1GBeJcJJxHJCJoHT8bKbna51+lJ2ntNVebsH1I5ajAcZ1cECcWqlrI9OQZQV0Cl5ssY5RQ0CIWqROTUKk+Qy1Tk452XmcxgJSBVILchgXUh1cBiZyKHEkYwUjgwjIjnQOIKSsuJgfbHKOFhuUnQcrD6pwbxKhJOI5YRMAqfjZTc7Xev0pew8p6vydg+oHbUYDzKqgwXi1EpZH52CKCugU/JkjXOKGgRC1CJzahQmyWWqc3DOy8znMBKQKpBakMG6kOrgMDKRQ4kjGSkcGUZEcqBxBCVlxcH6YpVxsNyk6DhYfVKDeZUIJxHLCZkETsfLbna61ulL2XlOV+XtHlA7ajEeZFQHC8SplbI+OgVRVkCn5Mka5xQ1CISoRebUKEySy1Tn4JyXmc9hJCBVILUgg3Uh1cFhZCKHEkcyUjgyjIjkQOMISsqKg/XFKuNguUnRcbD6pAbzKhFOIpYTMgmcjpfd7HSt05ey85yuyts9oHbUYjzIqA4WiFMrZX10CqKsgE7JkzXOKWoQCFGLzKlRmCSXqc7BOS8zn8NIQKpAakEG60Kqg8PIRA4ljmSkcGQYEcmBxhGUlBUH64tVxsFyk6LjYPVJDeZVIpxELCdkEjgdL7vZ6VqnL2XnOV2Vt3tA7ajFeJBRHSwQp1bK+ugURFkBnZIna5xT1CAQohaZU6MwSS5TnYNzXmY+h5GAVIHUggzWhVQHh5GJHEocyUjhyDAikgONIygpKw7WF6uMg+UmRcfB6pMazKtEOIlYTsgkcDpedrPTtU5fys5zuipv94DaUYvxIKM6WCBOrZT10SmIsgI6JU/WOKeoQSBELTKn31ibmTy14a7sEHnbizBJLlM9jLunT17gtOfM13H71OL7SgJX900sfswqkFqQwbqQ6uAwMpFDiSMZKRwZRkRyoHEEJWXFwfpilXGw3KToOFh9UoN5lQgnEcsJmQROx8tudrrW6UvZeU5X5e0eUDtqMR5kVAcLxKmVsj46BVFWQKfkyRrnFDUIhKhF5pQdg3ASj45PzKY4ic1jEwe1k4irQGpBButCqoPDyEQOJY5kpHBkGBHJgcYRlJQVB+uLVcbBcpOi42D1SQ3mVSKcRCwnZBI4HS+72elapy9l5zldlbd7QO2oxXiQUR0sEKdWyvroFERZAZ2SJ2ucU9QgEKIWmdNvGGdA/87NTNIfHIwsry3ohWB+TW+16/VDbv/rxvKEXivXJx5BtDx0XduI6zO7JkbMml1Ld//18913x9XyxMk7lPNrs3pDEMytUvLfPmU2LX4czkl8tDSmNwfB7IdaC1emxseGzJrxE7dYF1IdHEYmcihxJCOFI8OISA40jqCkrDhYX6wyDpabFB0Hq09qMK8SC3IST2xfKuZWYps6RdjrOXbJGvmcxJUp/Tr2XtUZcHW/fjRzRna87Gbdr9cWhoORN1dlj9ouPPunIPjTeRTKVqJ61iTh2oxOI2ZmXeRnvlCH6mN3L9LU8WRxePZqkpO4vFf/CVYgH/5ZP9ICcQqiqICuQKIapwTyRwjEQf3JXk/VPmhomFjYogSmf+lh6CT4YbRAowA//HVl3iS8br91aiScmaAhw65PPILbUjsJavBMT0XsGj9uFuycxOp0oBfUVMT4sSdyTkI7iUfvDAWvnNdCOD8bTK2akWLsyENauH9kfOzIJhkIWhg9skkCoX+FjaCAk+hOPOmp10OrqJfDvuwacseCoycnMbT4CWXAewf1AzgJ0AOqZ00SUmmjN0xPTEIq05xZFwOPZHVQGaX3Xp2chBXIK/oBnESxqD/Z66mahzYExkyYNaGTsFoQC8ZJhBohvWjt6DXrczrfLNF6/whuy8d6TmLpnk71i4ccJyHmJIIUJzH7oRHCR0tjQyfv6zmJE7e0KM7NGidBQerYf3bzxNDY2zfhJPKhjq76WwXZwNBIxiLqVPaMwcy8XUnZEE5IaDOR1HhkkhpMLKzT8c0yMbdg9zLNxFxIlE/iWd59RAl097SesyL0FBY5iY+jOasr7CT2HtwfqFT45I2xYM8r9K5LF8ordDzDyN8+Ud289tawfjj80owplOf/PQhevKj68uqxoWD4yFXhJC4f3akbB8HUmbYXypagelbnv8nh0Emww46lvd4UrpmYmTduQ+ewnoEI/QevEbrY8g6llJimlHhj5STovVowfchW0uHTD++YqV1i9mokEFM3tZNIFshlOoxBC+Trz6+nCeTzZ1IgxklAIBHqT1Y91aBQ9XlmnZLWJqFKYJPPXK55ofOchPuGM+UIsqWxyx2cxNOTw6+uhh4685xEspMYPbJ6YigYfUNOS8BJdEcmfaKT0EUtqoY2S2zJ46pq5yQ6Nrb10fhQu6ASlGt02Ma8hnDH33+5dEh/MPZsiXafXiMHujqtFn787PHicDD25iPKjwdHx3nOKti7qFPh6ts76d93dKG8v0B17uXLqr9vvK0O849Pju8IgpdWqF9vv6ZeVkcn8fEbzwc7//IRddWNvwwFfzgHJ9ECImnoVIygrJaJaoqsVIq2xUoXasdIDrE1YXqnHypZKW5j6ySCQ9e++O2nC6+S3zh5J5qTuLovCIaWHjhzElIgrwuB7JYC2TiWKhDfSUAgEvUnq05vVlC+UeJRQob12eQzD/+8YMp+1+skWAjJR3BapjkJ2khmQo0ImvHpuXE1NBgJBAfPGyeRfJ2E4yTw6YZmUE5CzTGEK20DVd3i9TF0Eh0bm/rIZVQvhPXRPpHBHCFs8/sv9+hZyEncoHdd48eeik83rttPLwx2zooK5er9I2PBzrFR9cZLfRI8c0ZNSIwcvq/7W3mIkb+9Tbk3/N8bql/Dydt0J3F+j30OzXNHbsBJNB/VszpvdSryuG4SXqSrQm0Vye/5hmQnYTYlHKqDUtzGetaXRv4b6tONO6fH405CTNoFB86xk4gE8tZ6mkDeSheI7yQgEIn6k3XPtjfYFhQRdk5Ch/kgj8N8tMFhxgUO8/G3/IzPhHHVMvhaSxPSRsBJZCKW9Kpa2ULJ8w1RUTMm0U4zRGt0+85zEmZNt/rovNUL27CTiM9JDJ/aFHMSsesk9q5+e1Z7jJ2Ln+hrynLMSbxw/CPqy2X1BIlzEvFOohecsXtA7YikoVJROwmbw+FgH5pmE1F6s46iHcPZO858XpA5H0Z0KG4WKsVpbGZ9051EWEM/JF2oSTvrJEKBvLPxWAgky5yEEsjnz04LgcTnJCAQOAkKOIlWOwkKXQQteminiN4Gxcd430l0bNypPuo1ikn1PZ9YG3YS8jqJicXbOlHct1yhk3iqv7Wx56q5Oj3jdRKfrh43XwsaenE6PichPwYOXl7iTqI/ilbYUwmahepZnbc6Fa2TMKmuc1t7ZYNVSriGr5Pw13Dm84LckWA/7TRjpcQbJzuJH983KpxdfDNUTOw6CRbIh19bJ0EC6X6dRLJA3OskIBD1J9ueRRQQcBI1dBLVC5lATsbILHFyQiaB0/Gym52udfpSdp7TVXm7B9SOPqShBvsC35N1iIzqYIE4tVLWR6cgygrolDxZ45yiBoEQ1S+q9QqT5DLVOTjnZeZzGAlIFUgtyGBdSHVwGJnIocSRjBSODCMiOdA4gpKy4mB9sco4WG5SdBysPqnBvEqEk4jlhEwCp+NlNztd6/Sl7Dynq/J2D6gdfUgDTgJOwu0pRM9hklymOgfnvMx8DiMBqQKpBRmsC6kODiMTOZQ4kpHCkWFEJAcaR1BSVhysL1YZB8tNio6D1Sc1mFeJcBKxnJBJ4HS87Gana52+lJ3ndFXe7gG1oxbjQUZ1sECcWinro1MQZQV0Sp6scU5Rg0CIWmROjcIkuUx1Ds55mfkcRgJSBVILMlgXUh0cRiZyKHEkI4Ujw4hIDjSOoKSsOFhfrDIOlpsUHQerT2owrxLhJGI5IZPA6XjZzU7XOn0pO8/pqrzdA2pHLcaDjOpggTi1UtZHpyDKCuiUPFnjnKIGgRC1yBwR0ZU39hub+kodXs4QeSfhwvaxq4VSwyT51tLIoetf/uvatLkqyMl5mflh3I6uojOMHY1dni+CdSHVwWFkIoeS+ws7D6zASQjU0b2eq1RkrJVOTsgk4O53+lt2sNOjsgtlnzmdRC8vY/eA2lF9aVBkVAcLxKmVsj46BVFWQKfkyRrnFDUIhKhF5kQRDufR14L0dfdlOAl3fXKoJH+8sEv/AIdJdQ7OeZn5HEYC6mYB9rZUMS3IYF1IdXAYmURDycZhsihwEjGqn/RwEmBbqMV4ACdRQWqROVEoJyF9g5iiOBV9lc8O/Kqxd29W/mqS+OpfpvY8J6Ffg2VuxTmO+fqe4dBsNCeh7jBkMPcZ0ncsnLM3GVK3CTASiDkJdQ9Di70zlfq639D4aKBuSPXtzUVaIEb3HNS3I/rhm3ANHWPFKOXGiRG7Zv8lKxkpHBlGRHKgcQQlZcXB+mKVcbDcpOg4WH1Sg3mVCCcBJwGKpPrSoICTqCC1yBwZ+lvHGvN9Zm9OIpquELYj+q6ybm+tQ6727CR06DsI8Netw13oOHJOIvx0I7q9kP7yM9/pUv+QgvoW9MTibSOBxDmJhyeG7C94KScRHLysRLFJK/V3pPWN5JWT2NQ3Sn5AMtl4fSzYc8UMJZiT8FFHD7utmgEnAbaF6kuDAk6igtQic/zQI70eyIWT6HB/ILXJrBSfVuRrL52E9hxsR2LHSXIS+pbHx80tj5+eHFbTEuGvKJhfFU9zEtfsz9aRU2AnMUXugUSxut/MTJA61FQEOQn7a9KWnSc24CRSMGcI9IM9laBZ2N4FfWNPaGtQf7IZHesQ8fmDmJNQwznfKs1zBv4cQ9720Va9xs6IGBshj5NjTqKLk1A24pXzZKnjcxLWSXSakxCeG04igeonPeYkwLZQi/EAcxIVpBaZIyK6MCKcEtA3ciUzMafmCQj/1sOxHWPXPSjytFdbtckIIevgHEcl+aVDek3X6yS6zEmo28brPcbINPCPPlon8WPH6ySCP/8zHErOHNArcJ1EhDq67eaKBpwE2BaqLw0KOIkKUovMqVGYJJepzsE5LzOfw0hAqkBqQYbVRXgv+R++eY/sh3YSkUzkUOJIRgpHhhGRHGgcQUlZcbC+WGUcLDcpOg5Wn9RgXiXCScRywmSASQKn42U3O13r9KXsPKer8nYPqB21GA8yqoMFYismnMQgqUXm1ChMkstU5+Ccl5nPYSQgVSC1ICPUhZiBGH2Df1vcyEQOJY5kpHBkGBHJgcYRlJQVB+uLVcbBcpOi42D1SQ3mVSKcRCwnTAaYJHA6Xnaz07VOX8rOc7oqb/eA2lF9aVBkVAcLJKyYcBIDpBaZU6MwSS5TnYNzXmY+h5GAVIHUggzWhVQHh5GJHEocyUjhyDAikgONIygpKw7WF6uMg+UmRcfB6pMazKtEOIlYTsgkcDpedrPTtU5fys5zuipv94DaUYvxIKM6WCBOrZT10SmIsgI6JU/WOKeoQSBELTKnRmGSXKY6B+e8zHwOIwGpAqkFGawLqQ4OIxM5lDiSkcKRYUQkBxpHUFJWHKwvVhkHy02KjoPVJzWYV4lwErGckEngdLzsZqdrnb6Uned0Vd7uAbWjFuNBRnWwQJxaKeujUxBlBXRKnqxxTlGDQIhaZE6NwiS5THUOznmZ+RxGAlIFUgsyWBdSHRxGJnIocSQjhSPDiEgONI6gpKw4WF+sMg6WmxQdB6tPajCvEuEkYjkhk8DpeNnNTtc6fSk7z+mqvN0DakctxgNWR3Qdu767n1bHx0uL0dfolTquTI2fuCkFIuujUxBlBXRKnqxxTlGDQAj1J3s9heg5TJJzqsvgEUGOCxxwEhx0GjMqEU4ilhMyCZyOl93sdK3Tl7LznK7K2z2gdiRKY+vUSPhNuUqEVce16WD2olXHw2MT48eekDo235w4GHcSmJMoheoX1XqFSXKb6nASIozoOFh9UoN5lQgnEcsJmQROx8tudrrW6UvZeU5X5e0eUDsSpZHPSazN6C/EK3gvvnmfvRsxtZmbUbflCUaW1/T9eeym6Fv+tuWThUlztx8RVh2Pju8K7/cXqsP+EOL4Ox/9/OGU/vZ8MHtAz0lc3js+qh4SY2+ta4GEPyUws3v/yOFPRBF0Cp9T6WRpg0AY9SfHuwnRT5gkt6kOJyHCiI6D1Sc1mFeJcBKxnJBJ4HS87Gana52+lJ3ndFXe7gG1w5FG7OY5whl0irUZe6c/NgG0hn/agNf4C3MrwrKQpeB7+7gRqePR8dB4hJ9u8JzEh1Pmvn72043Le9UtgUkdn7wxNvr6g68f31/YObZwQ6nj0u4ATqJvTDcAUDVsgnYETgJOAhRJojRyz0nYxivzxiUk/TCBbSMWyElEzRSxnzWSkaSOC3P6Tn/SSYy/85F0EvSvVsd7r2gncWVG/aCAVscZzEn0j/qTvZ5C9BwmyWWqc/CIYMKMCxxmgOAxgoMHCw4zanDw8GECcxLdqX7SywRyMgZOAgyORGn06SRod/ejihQnEbXsGEYdz5ZGdi3dDdVx59R4PieBOYliqX5RrVeYJDfBHsIZEUywh5ADBJxELiXCScRyQiaB0/Gym52udfpSdp7TVXm7B9SOAqThOQnlEgzqpwfsDxMkOgl5nYT95YIO10nEvrthflhZOwl68Mr5rk4C10kUi/qT492E6CdMknOqy+ARQY4LHHASHHQaMyoRTiKWEzIJnI6X3ex0rdOXsvOcrsrbPaB21GI8yKgOFohTK019jM1JzJyRRdApfE6lk6UNAmFqkTk1CpPkMtU5OOdl5nMYCUgVSC3IYF1IdXAYmcihRA4oHDyycBgRyYHGEZSUFQfri1XGwXKTouNg9UkN5lUinEQsJ2QSOB0vu9npWqcvZec5XZW3e0DtqMV4kFEdLBCnVob10f62YRDsOHHPCkRWQKfkyRrnFDUIhFB/stdTiJ7DJLlMdQ7OeZn5HEYCUgVSCzJYF1IdHEYmciiRAwoHjywcRkRyoHEEJWXFwfpilXGw3KToOFh9UoN5lQgnEcsJmQROx8tudrrW6UvZeU5X5e0eUDtqMR5kVAcLxKmVsj46BVFWQKfkyRrnFDUIhKhF5tQoTJLLVOfgnJeZz2EkIFUgtSCDdSHVwWFkIocSRzJSODKMiORA4whKyoqD9cUq42C5SdFxsPqkBvMqEU4ilhMyCZyOl93sdK3Tl7LznK7K2z2gdtRiPMioDhaIUytlfXQKoqyATsmTNc4pahAIsU2ZYy6sSf2aTymxMk8vwWC+7dwpNpZP6Tb2CqHw9Z/iq4tsmCSXqa7j7rtL4d3Y4pnPYSQgVSC1YGI1nI4LgqHF+0YdNxfffo9HECWTlT3hnVfsUOJIRgrHxsXddMTRY9dJRCvT5vgvLNxOdxLnX5w+r8R1cYpaPn/slpWYUdlnT09PD/3n7e5O4oMjh5dIfedefu7IDTiJeMgEcjJGZglnhiyUKgngJEBPVF8aFBnVwQIx6mCBwEkMgsTMyfetn14i+qbxNgXZiMjHrM91u+fKk4XJmNtIff0myWWqq3h0fBff1zWe+RxGAlIFUgsqrkwFB85ZXdw/Mj56ZFMvjO2PO4ke5iQu7h49vqZEdOGlYPi/N0hH79PCa2rBcxJ3j75AOUOMHL1K+row5TqJ9/c+f+xmhjmJG38Zelk5CWUpXv7LTTgJGTKBnIyRWcLJIQulSQKn47mz4SRAB6ovDYqM6mCBGHWwQGR9dAoinETPJGZOTifB39wxY3P0RZ7o1qix26eGDdRgnNp4fi7thqpJt151b8+a4SUl/IGdXjmhdlE7rkSv3x5HPN1jleTr4beTDl2jbL/77rhanjh557ef7pzWy4T51tKvm8fC5xxe2vz0l803x8eOPgqFwFpQQe5h7MhDoQs1ITGq9hx7++YPH+wZG91Jy6/8Wc9JrOwZG1EP1daFG1oyCV96shE6iY1jO0aPXdc6+vtM8NJKkpP44vyLwdTyxanATEt4TsJOSHx28z+H9bMFwfNv3iTRXT5qX04w9U9S3+Uj+uHQ4Q9IgLcOP7f3DJyECDgJsC1UXxoUcBIVxMkc8hC0hkkabt1Qu/C9UPXNRcIPC+h9v/3ysL2zWfTd4OieJQmNzRreSy7QJm4gbnPiHN9/ScJhqGehNdYriPCbxZ4rfFW6TfRNaXoon27X7KXfr88E9C+lur4x/DMxJ/H05LD2E5T59k4qTxaH7RehtQSkCqQWbJCZsD0TfrrBcxIf7An0gv10Y2VPMHL4Poll4/CYXri/sGPUuxGLDeEk/nzB6OjawnCKkwjHHROukzj7p+EjV0hrt488v+89KzeKj994fuj1y1p3ZCn+eD42J3Hn2Zk/DB1eMTLMpUQ4CZsZslCaWgknAXqg+tKggJOoIImZI8bU7rE+F76D1yEGaRqP9ZSAHX1pDX8oEDmJ1MZJC2bATr31anhY5yVF7RXOSzKxsr7WsVlHJyGfziQ5z0kEcSexJu6kEt4q/v3wafWcRGcnEeni7MFg72rcSaiZCZJJ6CTMVIT6rpN2Epdn1HedtGqim8PayDUnEY47JtKcxGdPT++zf5eakzi/xz7QPHd03XUSwe5FI8NcSoSTkDkBJwH6pfrSoMioDhaIUQcLBE5iECRmTi4nETXWUwLrSdMM4dESnERq46QFahyZj3AGwj++/5KksbAt7QcfKpSHSLxVKx+525wEN9tFT7c0cui6TvWkOYlXV2OZz/HL1X3BwfMdnMTDE0PjJ26Furi5OJrPSWSZk8hynQSPOybSnUQot/f+GOw59fEbz+sPNaLAnESngJMA20L1pUEBJ1FBisgccZWAGpv5oX9RguskOjVOWlC2g/41+LdeTTis+5LsPVhNY7uGv7vhNeMjk5OgdfrZ9ZqYk4g93eMv1acbhvHpQ+PTN4yToIezF+R1EoH+xZkni+HlBF2vk4h9dyM4eFmrg5wEPSAz0c1JZLlOgsL97sbt10aGX7tHgvrYLvC4YyLtOonbR543B/KvkwiC8NMNWtRmAtdJuAEnAbaF6kuDAk6igtQic2oUJsllqnNwzsvM5zASkCqQWpDBupDq4DAykUOJidicRHhzWBvCSciBxhGUlBWH5yQyf3cjVN+zR0tTO/HdjXjIBHIyRmaJkxMyCbjjZaGkkB3s9Ch3IZxEa6nFeJBRHSwQp1bK+mjUwQKRFdApebLGOUUNAiFqkTk1CpPkMtU5OOdl5nMYCUgVSC3IYF1IdXAYmcihJJTMmf3U2Yro5rA2xP0kcjmJ/u4nYdV37uVg6ozVYF4lwknEckImgeh4OAmQlepLgyKjOlggTq2U9RFOoihqkTk1CpPkMtU5OOdl5nMYCUgVSC3IYF1IdXAYmcihxJGMFI4MIyI50DiCkrLiYH2xyjhYblJ0HKw+qcG8SoSTiOWETAKn42U3O13r9KXsPKer8nYPqB21GA8yqoMF4tRKWR+dgigroFPyZI1zihoEQtQic2oUJsllqnNwzsvM5zASkCqQWpDBupDq4DAykUOJIxkpHBlGRHKgcQQlZcXB+mKVcbDcpOg4WH1Sg3mVCCcRywmZBE7Hy252utbpS9l5Tlfl7R5QO2oxHmRUBwvEqZWyPjoFUVZAp+TJGucUNQiEqEXm1ChMkstU5+Ccl5nPYSQgVSC1IIN1IdXBYWQihxJHMlI4MoyI5EDjCErKioP1xSrjYLlJ0XGw+qQG8yoRTiKWEzIJnI6X3ex0rdOXsvOcrsrbPaB21GI8yKgOFohTK2V9dAqirIBOyZM1zilqEAhRi8ypUZgkl6nOwTkvM5/DSECqQGpBButCqoPDyEQOJY5kpHBkGBHJgcYRlJQVB+uLVcbBcpOi42D1SQ3mVSKcRCwnZBI4HS+72elapy9l5zldlbd7QO2oxXiQUR0sEKdWyvroFERZAZ2SJ2ucU9QgEKIWmVOjMEkuU52Dc15mPoeRgFSB1IIM1oVUB4eRiRxKHMlI4cgwIpIDjSMoKSsO1herjIPlJkXHweqTGsyrRDiJWE7IJHA6Xnaz07VOX8rOc7oqb/eA2lGL8SCjOlggTq2U9dEpiLICOiVP1jinqEEgRC0yp0ZhklymOgfnvMx8DiMBqQKpBRmsC6kODiMTOZQ4kpHCkWFEJAcaR1BSVhysL1YZB8tNio6D1Sc1mFeJcBKxnJBJ4HS87Gana52+lJ3ndFXe7gG1oxbjQUZ1sECcWinro1MQZQV0Sp6scU5Rg0CIWmROjcIkuUx1Ds55mfkcRgJSBVILMlgXUh0cRiZyKHEkI4Ujw4hIDjSOoKSsOFhfrDIOlpsUHQerT2owrxLhJGI5IZPA6XjZzU7XOn0pO8/pqrzdA2pHLcaDjOpggTi1UtZHpyDKCuiUPFnjnKIGgRC1yJwahUlymeocnPMy8zmMBKQKpBZksC6kOjiMTORQ4khGCkeGEZEcaBxBSVlxsL5YZRwsNyk6Dlaf1GBeJcJJxHJCJoHT8bKbna51+lJ2ntNVebsH1I5ajAcZ1cECcWqlrI9OQZQV0Cl5ssY5RQ0CIWqROTUKk+Qy1Tk452XmcxgJSBVILchgXUh1cBiZyKHEkYwUjgwjIjnQOIKSsuJgfbHKOFhuUnQcrD6pwbxKhJOI5YRMAqfjZTc7Xev0pew8p6vydg+oHbUYDzKqgwXi1EpZH52CKCugU/JkjXOKGgRC1CJzahQmyWWqc3DOy8znMBKQKpBakMG6kOrgMDKRQ4kjGSkcGUZEcqBxBCVlxcH6YpVxsNyk6DhYfVKDeZUIJxHLCZkETsfLbna61ulL2XlOV+XtHlA7ajEeZFQHC8SplbI+OgVRVkCn5Mka5xQ1CISoRebUKEySy1Tn4JyXmc9hJCBVILUgg3Uh1cFhZCKHEkcyUjgyjIjkQOMISsqKg/XFKuNguUnRcbD6pAbzKhFOIpYTMgmcjpfd7HSt05ey85yuyts9oHbUYjzIqA4WiFMrZX10CqKsgE7JkzXOKWoQCFGLzKlRmCSXqc7BOS8zn8NIQKpAakEG60Kqg8PIRA4ljmSkcGQYEcmBxhGUlBUH64tVxsFyk6LjYPVJDeZVIpxELCdkEjgdL7vZ6VqnL2XnOV2Vt3tA7ajFeJBRHSwQp1bK+ugURFkBnZIna5xT1CAQohaZU6MwSS5TnYNzXmY+h5GAVIHUggzWhVQHh5GJHEocyUjhyDAikgONIygpKw7WF6uMg+UmRcfB6pMazKtEOIlYTsgkcDpedrPTtU5fys5zuipv94DaUYvxIKM6WCBOrZT10SmIsgI6JU/WOKeoQSBELTKnRmGSXKY6B+e8zHwOIwGpAqkFGawLqQ4OIxM5lDiSkcKRYUQkBxpHUFJWHKwvVhkHy02KjoPVJzWYV4lwErGckEngdLzsZqdrnb6Uned0Vd7uAbWjFuNBRnWwQJxaKeujUxBlBXRKnqxxTlGDQIhaZE6NwiS5THUOznmZ+RxGAlIFUgsyWBdSHRxGJnIocSQjhSPDiEgONI6gpKw4WF+sMg6WmxQdB6tPajCvEuEkYjkhk8DpeNnNTtc6fSk7z+mqvN0DakctxoOM6mCBOLVS1kenIMoK6JQ8WeOcogaBELXInBqFSXKZ6hyc8zLzOYwEpAqkFmSwLqQ6OIxM5FDiSEYKR4YRkRxoHEFJWXGwvlhlHCw3KToOVp/UYF4lwknEckImgdPxspudrnX6Unae01V5uwfUjlqMBxnVwQJxaqWsj05BlBXQKXmyxjlFDQIhapE5NQqT5DLVOTjnZeZzGAlIFUgtyGBdSHVwGJnIocSRjBSODCMiOdA4gpKy4mB9sco4WG5SdBysPqnBvEqEk4jlhEwCp+NlNztd6/Sl7Dynq/J2D6gdtRgPMqqDBeLUSlkfnYIoK6BT8mSNc4oaBELUInNqFCbJZapzcM7LzOcwEpAqkFqQwbqQ6uAwMpFDiSMZKRwZRkRyoHEEJWXFwfpilXGw3KToOFh9UoN5lQgnEcsJmQROx8tudrrW6UvZeU5X5e0eUDtqMR5kVAcLxKmVsj46BVFWQKfkyRrnFDUIhKhF5tQoTJLLVOfgnJeZz2EkIFUgtSCDdSHVwWFkIocSRzJSODKMiORA4whKyoqD9cUq42C5SdFxsPqkBvMqEU4ilhMyCZyOl93sdK3Tl7LznK7K2z2gdtRiPMioDhaIUytlfXQKoqyATsmTNc4pahAIUYvMqVGYJJepzsE5LzOfw0hAqkBqQQbrQqqDw8hEDiWOZKRwZBgRyYHGEZSUFQfri1XGwXKTouNg9UkN5lViY51ExaOFhbIlQBqFRAsFgsxBVDAyKrF3JwH6xJ5K0Cxs74K+sSe0Ndg/G4CKYRO0I82Ua8Y/HoB2AoEAAAqkgQVFuygUSgCSgUAAAMXSWCdB2McAAIGVBwQCACiIplUTWyM1dhUAIMRqQ2NXAQBAfzTZSRB2LQBAY4URYtcCAEAfNKqU2OoosBsAABAIAGAwNNxJEHYbAK3HSiKO3QYAAL3SnDpi66KH3QxAu7F68LCbAQCgV5rvJAjbAoAWY8WQhG0BAAA90ZAiYitiCrYRAG3FKiEF2wgAAHqiFU6CsO0AaCVWBunYdgAAkJ9WOAnbCIC2YpWQgm0EAAA90ZwiYotiErYFAC3GiiEJ2wIAAHqi+U7Cbgag3Vg9eNjNAADQK42qI7Y0xrHbAGg9VhJx7DYAAOiVhjsJuwEAAIEAAAZD00qJLZAhdi0AQGOFEWLXAgBAHzTZSdhVAIAQqw2NXQUAAP3RwGpiyyQKJQBJWHlAIACAgmisk7APAABxIBAAQLE0s6CgUALQAQgEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgcBIAtA4IBABQIHASALQOCAQAUCBwEgC0DggEAFAgLXMSW8uTk8tb9kEK6/Pz63YRgEYCJwEAKJA2OYn1eVofdHQS5DRUmy6tAKg3lOF2CQAA+qY9TmJreXm9+5wEuY35df2PXQFA84CTAAAUSHuchCbLpxsANB04CQBAgVShoOjZgkxkbQknAUAH4CQAAAWyPQUlNqDTg4yfJWRuCScBQAcKcBJZpISLlwFoB9vuJGiRypq5wtEuE7YARStou2zZBWpmlxzEE0fLciUALSBVIBnBxcsAAEHZToLri0FVGVqljYMY0O2qcEuI+zgVOrJdAqA6rM8PcljN/ilhnwLBxcsAgBjbM+LGqlDoD8z7nBCzndfphylOgjbbpRB/DQC90XXErAop6iCyCCS3ZGpzXgAAA2d7RtxYFQorYHoltO9v0lrASYDBEcvV9fnJSTWpNr9Oq+l/RZiSoeudn7czD9EMRLhk/u9wENpEe6sVk8vrdqPelNRSH4TQx7YNwmeMQevtUkiWNV2InRcAQKupwIhraqAqkFG59B6LamlLaQxabZc0nR8CkAWZjoQxATywh8MoLdpctWuojVkK/UO0ZP5PP4jcN1rQjiO1JW8LtyRCr98uaTo/zIR4TQCAltOQIbb4QgmAJjZiRpaAcopR6yLbIBqFq+Jrokd2f41ex7uIBXISnVry0jY6CV6GvQCglTRniJXVMG0ZgLwkOgl/1I6a8WyBNgGxbWb3DkM/+wOxYOYkUlt2OlwMCAQAMCCaU0RQKMHAicZvGrcpswzsF8yj8DoJ5QI0k4ReY3bvcBDeJBb0lvSWvGSapJsJ2miXIBAAQKE0p4igUIJqEA3ylQICAQAMiEYVEa6J/gIAZVFRJ0FAIACAQdCoOoJCCUAHIBAAwCBoWh0xlVH+CwBgIBAAQOE0rZSgUALQAQgEAFA4TSslKJQAdAACAQAUTgNLCdVHg30MABBYeUAgAICCgJMAoF1YeUAgAICCaGY1QZUEoAMQCACgQIosKPp9DmgRtuOBhz1BoCfsSQQA1ISCncT//foVoiWBit8BaKHnQF4BUDvgJIqJ33/5kuJfP3/B8dtPn3P8+uNnHL/88CnFz99vcfz03TOOH799yvHDN09MfP/1YxPfffWI49svH3J888Wmia8/f2Diq8/+l+PLT++b+GLrE47Pn/0Px2dPN0x8+uSeia3HdzmePbrD8fThbRP0J6Pid6DiWpDp6mSpzE8nJ2U2Okko009mnZNvMs2cBENeAVBf4CSKCTgJIIGTgJMAoD3ASRQTcBJAAicBJwFAe4CTKCbgJIAETgJOAoD2ACdRTMBJAAmcBJwEAO0BTqKYgJMAEjgJOAkA2gOcRDEBJwEkcBJwEgC0BziJYgJOAkjgJOAkAGgPcBLFBJwEkMBJwEkA0B7gJIoJOAkggZOAkwCgPTTFSTxZmKSnN8ytuFtTY2N5Iu8uydGfk7h1cky/DGb0yGY2J3F/Ycf+S3ASlUOdHJMbazO0PHlqQy3rLJ1fi2VO/7F1akQdUz3RzLq3NTF0ut57d1zlGvHqqs3SJ4vDs1eTncTmiaGDHwzESdw6/NzUGTgJAGpMM5zEynxUoNWyLdzdQ+7YV/TnJOyExOqBINh/1nkL2MlJ3Ds8SnvASVSPSAvaSQTByPKTwTiJno6p0vU6vbDpGz9/8fTkcDB+7Cll6eYx8tXJTuL+EXIdA3ES638ZCgI4CQBqTROcBL0nCyYWtrz163O6hhNmq37TNm9XUmUPJyR0IU5qPDJJDSYW1un4ZpmYW7B7mWZiLmTX0j3lIa5NU4E+NGvWDZ9+SE7izqnwzd/cqnESHy+FkxCzH6Y5iZuLZBM0r6wYJ7F+gl6IZmzhxrdf3uCH+y/CSVQLdXJMHlonoee9xKjff75puyxyeE6l97o5spljU421g5HN9LOHTiI4dI0tb5Sls4tvhovB+IlbMhUPfnDznXD5wIpyEvcXdgTBjlGTitP//dawXhh+7Z5KudXjZBM00+d0pp39UxD8ad8es+65o+uXj+40y8HeM8grAOpKY52EWmkne3UZpdqqa7qupDxvYeckOjY2W3VF1uU+fHNparSNrSX1Gp5ZJ2EK9IVXqf6fvKPe8wXTaz9+9uuqMhnXf/j08eJwMHb0Eb3te3B0PJhaTXISmyeGgtE3Nr958sMnb4wFez4kJ7FCBXjniQ3MSdSASAsmZ07pdDplnUQB+UZthLdQO6rG+pjhAluKeGO1yUyhPaOkNcxeUDNn3pzEQ0rCMfVBG89JbL69Mxh9/cHXj7/bODwWvHw5dBJv39385uJuWnjrzoOvbr82Eryw8PH9e2++EAz99S7l20d/HQ5evGCdRLDvPcqxU1NBMPT6ZcxJANAAGuskVBkNV9oGXGp1+ZZOomNjvSZeo2Vll28uQyehJo3pTd7pceUk1mbpnd2xJ+LTjesH7R6aoZP3E5zE6n67WbPznY3YnEQwcwZOosqok6OTh90A50mB+Raag7iTsOm9wJ/cRbso1HGMkzAfw2mnqybPpJO49opt7TiJq/G0PHHPOIndH1D6KSfx0grlXugkLu2z7TTPH7tl5yTOqxxTsxFwEgA0gyY4CVNMw2sj7HxDVI5jb/tkqe06J2HWdKrsqkabt32xOYmYk4jPSQwvbYo5ifTrJKI5ifCTaf5w+ruVlwP9dhBOorJEWlA5o02AzlKimHyjNqlOwhyBEA9D42KCbITK2PHjlLG/6bSUTkI53VfOd5mTCCfGOjiJaE6Cr5OAkwCgiTTCSVCEZVqhSy2F++4tKrWuk+jYuFNl12sUuyZUGzIQvpOQn0BPLN52rpOgkp3oJOSH08Gf/6mcxMbrvJO+TuLht1+eMW8RcZ1E1VAnRyePzhCdKuEAX0i+Tep80+1VDhN8nYR+Xuun9TKF9isGrQ49JxF9d0Nn6ee//vi+eVGzB+1kwviYGuVXVTaeNfNo8jqJQE+MdXAS8jqJYOp0spN4vDSlt+M6CQDqS1OcxHaHnC42EV7IpoK/uGE+3eDPoZ05CYrQRqjo/t2NMDAnUTUqrgWZrk6Wyvx0clJmo5OEMv1k1jn5JtPMSTDkFQD1BU6imICTABI4CTgJANoDnEQxAScBJHAScBIAtAc4iWICTgJI4CTgJABoD3ASxQScBJDAScBJANAe4CSKCTgJIIGTgJMAoD3ASRQTcBJAAicBJwFAe4CTKCbgJIAETgJOAoD2ULCTAK3CdjzwsCcI9IQ9iQCAmlCwk5Dve1oVmJMAkoprAXMSAIACgZMoJuAkgAROAk4CgPYAJ1FMwEkACZwEnAQA7QFOopiAkwASOAk4CQDaA5xEMQEnASRwEnASALQHOIliAk4CSOAk4CQAaA9VcxIby6dWvJWJEbZ8sjBJT8zMZdy94JCl+casfS1BMHz6oanRt08tvh+r1B9Ojb/zEZxEU1Enx0uS6oTjJNZExi5tGifx0dI752M5eXnv2Ns34SQAAD4DdxJbp0YmT204K1ODbEFGK8AtY7tsLE+MLD8RzcqKqDRfmw5mL5oC/dvDYxPjx56Sk9g8NnEw7iQwJ9FoCtDCICPmJFYpYy/YOQlK1LE3H1N+Pjg6/krcSWBOAgCQQqWcBPkAOkag29tlYn5Nb43mHsgriJaJTmJtJnzSlfmJhS1aoDUTI7TL/NzMJIXaOzxyl+dKaWAOG0ZUmh8d3zV+/Fns0407p8bVvhOLt39dnZ4YG6bl2Vf0nMSHU+NjQ2pbEIyfuKWr9s3FUf14/96Do29swknUE3VyRHqYyOckwowleK/1ObMizENqY5N5ZHnNJq3e1CVjY06C/W7kdD9eGlP7qpy8MjU+qlL04H49J/HBnrHRnWpbEIwt3NDpd+OEeZnTu/88/N8bcBIAtI8BOgmqm7rAWDLV0NAWiJpLNXFmXa+xNTHeUoz6CrtXkpOwH3zQgi2pK/OBPXL4mUi0Rj6X/2J4E4cszcpM2JcTfrrBcxL0/u/g+ejTjQ+ngrGjD+md3/0j42NHaGHzxND4iZvqLeDlvQGcRG1RJ0ekh8oxQSYtcKKyCeAclmv8hbmVrhkbcxJm8sy+tPDTDZ6TuDIV7D9rEtI4iWD09QeUihuHx0YO3//y4f2FHaMLN1T6XdwdwEkA0EoG6CRMiKKWIUJ/wO+9NGZigIZ58VA6CesDRCTOSZg10SYqsupQwjfYNc5zJb0YN2JOggv0TxdeDabX4k5iYvFj6SToXz2HfG5WO4nV/UOL981k8lnMSdQXdXK8JMmnBT+HpS7Sslo7ia4Z6zoJHXpO4v3ZYN/1uJNga2vnJN5a16l45oB2Epdndpy4ZzLwH5iTAKCdVNRJiNHdC/POrJuT8N+9RaXW1uXUOQl7EIrwHV7qiwmDS/OzpZFdS3fDAn3n9Hg+J4E5iWZQgBY8JxHlYVJWR+mdIWOlk3h6cnji5J3QSdxeGsvnJDAnAQAYuJPIF1Qi6ShqXN/gD3oDHu8t+j0Wt0x0EjypMDGSUHO7XSfhPpf3YqJSHoYszeK7G8Grq+GnG/SAzEQ3J4HrJJqBOjkiPXoJz0kol2CYmJk3n1mkOImuGSvTlfJTfHcjmL0afrpBDw6c6+okcJ0E2HZ0/oFk7DkaMBVzEiVEVKCLDFmauUBz6Hd7NqhMq0qd8t2N2JzE/vfIRsBJ1JGKa8FxEjJLZX6anFTZqENmIydhbE5i+h+ce3ASoDTqMfRsR5SmJjiJYqIoJ6Euj6DzqBha/EQVbjiJOqJOjpck1YkCncS3X57Zr/M1CHa8dSfKPTgJUBoqZ7wk38bw9cXicmq+oyxZ22VV9zWVJqjtUlP7nMRgQqaOTCCZRpxMHZ2ErdqcXly7Oc9ktvk5BydRBSquBb/ScZbmdxJRBsrcc1JOZpqTYzK16LUhr0BeqiY3X18sLqfmO8qSspJV3ddUmqC2S01wEsWETB2ZQDKNOJngJBpPxbXgVzrOUjgJUDuqJjdfXywup+Y7ypKyklXd11SaoLZLTXASxYRMHZlAMo04meAkGk/FteBXOs5SOAlQO6omN19fLC6n5jvKkrKSVd3XVJqgtktNcBLFhEwdmUAyjTiZ4CQaT8W14Fc6zlI4CVA7qiY3X18sLqfmO8qSspJV3ddUmqC2S01VcxL5f8FLfzVOfHtef/8t4XuhFNEueS66jO4L1CHWo+/Rjbz7yCTQndMn1c8ZcBrpr4DehpNoA+rkeElSnYCTAE2ianKDk+iLxO7Mdzee5JtDJAW3JCcxMRLt9WRhfoLvNBUPsUvBToJew+wlmzr8uxsPj03oH0biNOJkgpNoPFUrbU7ASYAmUTW5wUn0RWJ35nES9nY6ur17tyjlA+yKkdgveKlb8SzwjwtsnZpZPuXenEcfIbYL35wqfG3e0/GauZl54yTi9/aJxZOFXbQpTB0dd0+bX+06eee31emJcfWrXXMH9ZzE1X3mR7wIdXMqlVW3TuofTAoOTB0cPbIJJ1F/1MlxkqRKAScBmkTV5JbBSdw6eeKcEtflveMn1I/1G2VJWcmq7msqTVDbpaYBOglxp0hFJj8RThsI/0Ejur3HpfgIIzbBQL4h3LqxPLewFa5xjhDbJW4O1Es1m9TNMe3T2d25ccf4/fFC+Ktd4acbPCehfrWLb5WtnEQw9uYjyqcHR8fHjtLCQ3U3KvVDoOrXkuAkGoE6OV6SVCfgJECTqJrcujuJ+0fGD2gnEVeWlJWs6r6m0gS1XWoaoJMwIUb0DBEO9jl+wUv7BvvwycI8PZdek3AEsUv4krxfNFC2QzVenzNPGrXRy6khUufioWD6RtxJqN8TF05iYvFjnU/nZ7WTWD0wdPK+mew6hzmJZqBOjpck1Qm/0sliBycB6kWvcvOmomlocH7K3xss1JpuP+V/6LrW17XpXePqaK+ufr4W3nBw9kNS1kdmEpreQIZzEuGPJATBgRUtq0u7R0d2mDWjx677mkoT1HapqaJOQgztXkjrwA/1xMO8Gf71moQjdHQS+iB6Tf45CWq8a+leWJrvvjuez0lgTqJ5JGqhOgEnAZpEVrnREEDFPCzpUZHneWuu9qalXuM7CdtGLviz4NpJBLMXzRBgpqV/2XzTzENHcxLaSWy+vTPY/56W1ZkDwcuXSVOXdgcjf/uEZHX3b6PD/71Bmrr92sjwa/fO/3sw9Ne7LXQS+YL6j45inQEtGezQbh/xBAMtUkvdi7SvaiD61T+C3MVNDtFYTE7ox1muk4h9dyM4dE0XaHIS9IDMRDcngeskmoc6OV6SVCfgJECTyCY3/S5RlPGEeevEGYi0NWKBhhX3aI/1nMTSXSMunpMIUpzEwQ+Usr776saJkZ0n7uk5ieNrWlb6x/qNpshG7Fu+e/SFkaNX0wS1XWqqmJOobcjS7BRoClOj/UptIjYnsf+sU7jhJOpIxbUAJwGaRCa5qXeSM+s8kaDffLrz1km+wbxTjd5JpjgJeTSrr9BJPD05PLeqxZVnTiLZSQy/dvHoC8HQX+/ASTQyZGl2CjTXaL9Sh/X6XDijMbR431ZtLtxwEnVEnRwvSaoTMl2dLIWTALUjq9yMG4jMhDdv7TsJNZOhmRjp7CTcowknoT7dMIztmx2bumacBD08cK7TdRKOk8CnG22I/pyEqtdO1ebCDSdRRyquBTgJ0CSqJjdfXywup+Y7ypKyklXd11SaoLZLTXASxYRMHZlAMo04meAkGk/FteBXOs5SOAlQO6omN19fLC6n5jvKkrKSVd3XVJqgtktNcBLFhEwdmUAyjTiZ4CQaT8W14Fc6zlI4CVA7qiY3X18sLqfmO8qSspJV3ddUmqC2S01wEsWETB2ZQDKNOJngJBpPxbXgVzrOUjgJUDuqJjdfXywup+Y7ypKyklXd11SaoLZLTTVyEuZ6Fr5h1HZEdD2OGzJ1ZAKp4G+B9uMkVvbQHz+2cMOk2ncbh0dHDt/v4CTef2nmfZV8K+panxcWPnacxPL00H+Zq385HTkjRZW/fPT1JcrLcy8/d+QGnEQOBqyFfsOvdBR+fjo5GWUjnASoElWTm68vFpdT8x1lSVnJqg4nIe/+0WfwxbTbF9vqJMbeWjd59t3Ky3Sqg3QnsXHM3hxt5Ng1yr9L+1wncXHqhWO3rI3gdOSMjKr8+l+G9ign8ezRB0de/sstOInMqJPjJUl1wq90FH5+OjkZZSOcBKgSVZObry8Wl1PzHWVJWcmqDieR00nQUK1vVjq/5twqKnyozISzqcNe0SYifBncxkxveLt0uAMVHS386a/wq8PR7oeum9S5+67+7S7i1VXpJG6fCtfPXrX5dO2VcM0VnVhXpsZHh8wa/dWgRCdx48TCmS5zEhdeCqb/vjIdmGkJz0ksT5uvI9/6L/tLYsHzx25SRl55c6d9PPVPSsrLR/XDocMfUGreOvzc1Bk4iayokyMzp2IBJwGaRHFyi+q5JfPbV30/CW/38eNP4STyol50/Mzqc2nJ5CfC24AI/0F9o7/pG85JJGzqsBd/dTj0B+pV8Z1GEn/oq0NEX0SObqptjvb7L5cOBTM3fv7i2dJIMHtRF+gLrwbTa6GTeLI4bGYmfvnh46Wxfdconz6cCl45r7Lq/pHxsSMPtZOwd8umNbSQ7CR0dP10Q2eeCddJnH/R3CLtzpHnp89F6Xj7yPPDb1zWSUke4o/nKS+jOYk7z878gSyFSVBU/K6okyMzp2IBJwGaROFyUzesNMNExqDRJHp7qW95PHtJ6gtOIgeJ3SmG6gwRfnyQ/AteehTvcIvTLHc/pTbc3ylPlB5rM2IqQjWmv86s+f2Xe7Tm3UfKSdi7Zf905/T48OmH1klEd0tVDC89iM1JBKGTGD9xU+fWWXXb7AE7ic+fnQ5vmKLmJN7fax9onju67jqJ4OUlk6Co+F1RJ0dmTsUCTgI0icLlpsaFyElQtadnUPhT0Xp8cRtIJ7Gmli8ocan7U+27Rm8gg6nZA6b51KpSVuy2VCwrWdV9TcFJdIxw4OcRWkQ0J+Fu6rCX5ySi16NnKdYTnig9wsmP3uYk7A1Tw0r96J0h/btwsTmJcp2Ejc/O/inYe/r2kef3vacyMqrymJPolUQtVCfgJECTKFxu0kmoIm+motXEQzjV7bzt7DAnoQzE9NqPn6k3kwfPq6lo+3G2/rml/Wc3TwwFo29Qtf9+4/Wx4OUrcBIFdGc08Ecuz97HNLQCCZs67OU5CdHGpIK3i3YYuqUXdLTwqoswaaLds18noZyp+XTDMDY1Oza12rOTuEfL4lfjujqJ8DqJO0eety/Au04iCMJPN2jxZWUmcJ1ELtTJkZlTsYCTAE2icLlJJ5E0by1GDdOs06cb9JYymFt9nw6jrpDTcxKq2n/37KHyEEcW99sjaXae2ICTqHb1HGjI0hwmkC3QXKP9Si3rtVO1uXAnOwlRxJ2ck9XchOckMn93I0rNpamd+O5GDiquBTgJ0CQKl1vynIQfanIifP+Z6iQ+Vx9wKKavk7I6zEngOgmDetF8ilsWJTgJOr3R/SQyO4n+7idhU/Pcy8HUmShBUfG7UnEtwEmAJlG43NKuk5AzEIZozls/NGbCveLy4TE6wMTibaWsjtdJBDNnWFayqvuaShPUdqkJTqKYGLiTEOXbKeJOzslqLvNPlnVORJmOnJGyynNqygRFxe9KxbUAJwGaRNXk5upLOYnhU5tKXPLTDRYXK0vKSlZ1X1NpgtouNcFJFBMydaIEitdov1LLei0TS6YX127OM5ltfs7Jai7zT5Z1TkSZjpyRsspzasoERcXvSsW14FY6kaVwEqB2VE1uUl9PT+q79hx834gLTqI7VevOMkOmjgku0Fyj/Uot67VMLJleXLs5z2S2+Tknq7nMP1nWORFlOnJGyirPqSkTFBW/KxXXgkxXJ0vhJEDtqJrcfH2xuJya7yhLykpWdV9TaYLaLjXBSRQTMnVkAsk04mSCk2g8FdeCX+k4S+EkQO2omtx8fbG4nJrvKEvKSlZ1X1NpgtouNVXNSWwsn+LrXDqHaSm/w6lJu8i2x8h6fJk66ougSxf1nansTpbxY0/gJNqBOjlekiCyBPIK5KVqcoOT6IvE7ozuBJUlnqg7WLsrE8NpGd03YjDR7fgxJ/Ho+K5ZchL2rV54PwnMSbQIOjmgZ+xJBCAbKme8mryNASfRF4ndmcdJ2AkA3T6aDLBf0o2+eDOy/ES21FvFSL/O98OmXSYWtmhT+s9uxVrq3ZMj5iQSdt9lV4y8+8jemWri5B3fSawdVDcnUfn04Oj42NFHH06NvzJlZi7Mj3jJbwQd/ABOAgwE9B1oEiqfbXGuRMBJ9IXTneqGHoJMfiKcaRD+g4ZtdesPWhP6gFhLG3KkFwdRuyT97JZzcLtjhxDHT3xth65nm5PYPDZx8Dzlk71V9odTwdhRdZ/s787N6gt6N08Mhbe5JEux5yqcBBgA6DvQJFQ+c62uQMBJ9EVid4pxN0OEJiDpBqX21h/2YQcnYQf40CVEm2iN2jfp4N1CHD/xtR0KH777qPOnG7eXxvZdVz8HOmVumD3+zkc6pW6dHBs6ef/ZavzOqYufwEmAglEdh+4DDUIVS5CCPUcDpqJOgvaKzUDIMD+j1clJ6CedCJ83aU4i9eBpEZ+T8He3JvTatPr5ro7XSTxeHJ4YGyYDocxp0pzEwcvKpbJRhZMAxWJ0iu4DjSFx6NnGwJxEXxTQneQP6CjKImzwtQjmxuY0fttHPCdBi2wm4k5Cm4ZwsoE2pV8n0f1Xu0zEjt/ptdk5CVqcvZDoJH754fxs+Kviak4i/TqJIMCnG6BgVK/pNEb3gcbAWV2RgJPoiyp1J//yp28yBhIydWQCyTQKk+n87Nibj3Q+iU83Yokl0wtOAhSIFCl6EDSDKg09KuAk+qIq3al+n42nHyrmJNRv1evfloWTANuBFCl6EDQDmdVVCDiJvqhad5YZWZ2ETibOJyerOLFkesFJgKLwFYpOBA2gakMPnERfVK07yww4CVB9fIWiE0EDqNrQAyfRF1XrzjIDTgJUH1+h6ETQADixudYh4CRqGXASoOKkyRP9COoO5zZVOVlCWxtwEojaBEagepEmT/QjqDuc23ASJmrvJECrsB0PKo/qrLiB4EA/grrD6Q0nYaLeTgIQqMuggnRwEhRIWlBr4CScgJOoPSjKoILASYAGAyfhBJxE7UFRBlWjs40wgbwF9SWbk/j47Mv/v9EhFUfW9Jq1/9j38r+ZNfv+38d2jVn49tKRl995YtYc/o99qs2/nV17Ry+Eu1c44CRqDyoyqBqUk1mwrQGoGyp7fSex+c4+cgNr/zGqPcGT//dvoUsgS/EfN2kh3GRb6jW+k7Bt5MLhS87BoyetRsBJ1B5UZFB9kKWgSSQ5iUtHhv7jJluEb5/ePGwnJHT829nNZN+QukYsKCcRLgiDUqGAk6g9qNGg+iBLQZNIcBLkIchJiDkDGvLdTyUSZyCMS/BnKRKdxMvv3Px//1bBaQk4idqDGg2qD7IUNIkEJ0HhfgARXScxSiaD1vhOQs1k6AYv/1sXJ4FPN+KgoBQMajSoPshS0CSSnUSLA05iu9haXl63i13o0rJTz20tT04ub9kHKazPz2d8IQD0CpwEaBJwEk7ASZRHbFinBxkH8G4tU3tufZ42BR2dBB1btenSCoB+oRyzSwDUH5XPoZNAmICTKAnhJOwIrh/yaB5YwxCtoO2yZTK01S7F0DMZ4imTIbcxv67/sSsAGAQpWQpALVH5rJ1ERUL+oKP8EUf8qnijiLyBRg3utEqP3mKst6vCLSHuYxc6oF3yEUcHYBvplKUA1A2Vz95wvo0BJ9EiYsN66A/MRxAhZjuv0w/hJED96ZSlANQNlc/ecL6NASfRIhKdRCefYD51gJMA9QdOAjSJApzE2szkqQ13ZedI3wVOoq3QGE+nXFkEs2RwHodzErSYbiZoo13ykU6Cl+VKAEqhU5YCUDdUPnvDeb7owUmkB5wE6BfUaFB9kKWgSRTjJOZmzLvG+TW7cn1OP+Y1TxbCt5Ujy0/YfGwsT4iVekc4CdAvpfUcAD2DLAVNQuWzMQQ9x9pMMLGwpZZX5oOZdbNmbkVtIgOhN22dGmGTYXYhJ0Ero2ZmAU4C9A9qNKg+yFLQJApxEqFL2FiesLMLPCchTIYhmpOgNjF7oQNOAvRLaT0HQM8gS0GTUPkcH8tzB89AhHMS0QxEOCfhNg7nJOwFFqIZnAToF9RoUH2QpaBJFOIkJidG6DiENRBkFwwTM/MT1lvYNbhOwgMFpWBK6zkAegZZCpqEymf2BBUIOAnQL6jRoPogS0GTgJOAk2gaqNGg+iBLQZOAk4CTaBqo0aD6IEtBk4CTgJNoGqjRoPogS0GTgJOAk2gaqNGg+iBLQZOAk4CTaBqo0aD6IEtBk6iKk7DfCxVO4tr0xMk7v61OTyze/lX9+/HP33+09M55ZSOuTI2fuAUnAZJBjQbVB1kKmkR1nYSZkzBOwsxJPDg6/op2EpiTAB1AjQbVB1kKmkQRTsK9wZT7813kErr+xJdoc+h64pzE+aUxtXX8xK1wTuLm4qjeIQheWdFOYuNwuGLH23fhJNpKaT0HQM8gS0GTUPlsDUGP4f4Ql/fzXWpN9OsbyT/xxW1+/+XSoWDmRuKnGzwnoZ3E5omh8RM39ZzEzXdG91z56tH9hZ37L2FOovWgRoPqgywFTaJ/J+H/EJf7813hJxedfuIr/Bmw33+5R23efdTdSazutwfQ7Dyx8ei7r86E6zAn0WJK6zkAegZZCpqEyufQAfQWzg9xrfs/3+XNSST8xFc4S5FrTuLg5ZTrJC7uDqb/ASfRUlCjQfVBloIm0b+TcK+TIE9gCH++S81JONdJJLYJfwYs5ToJ7SRo84Fz/nUSQWA/3bCPMCfRZkrrOQB6BlkKmoTKZ2sIBhbRpxvdw/3uBu4nAfKCGg2qD7IUNAk4CTiJpoEaDaoPshQ0iTKcRJ6AkwD9ghoNqg+yFDQJOAk4iaaBGg18KCtAM7A9CqqE6hdvON/GgJMA/YJaA3yQFc0A/VhN4CTgJJoGag3wQVY0A/RjNamak6hOwEnUFdQa4IOsaAbox2pC/QLSsOdowEAYBVNaz4EagaxoBuhHABKBMAoGtQb4ICuaAfoRgEQgjIJBrQE+yIpmgH4EIBEIo2BQa4APsqIZoB8BSATCKBjUGuCDrGgG6EcAEoEwCga1BvggK5oB+hGARCCMgkGtAT7IimaAfgQgEQijYFBrgA+yohmgHwFIBMIoGNQa4IOsaAboRwASgTAKBrUG+CArmgH6EYBEIIyCQa0BPsiKZoB+BCARCKNgUGuAD7KiGaAfAUgEwigY1Brgg6xoBuhHABKBMAoGtQb4ICuaAfoRgEQgjIJBrQE+yIpmgH4EIBEIo2BQa4APsqIZoB8BSATCKBjUGuCDrGgG6EcAEoEwCga1BvggK5oB+hGARCCMgkGtAT7IimaAfgQgEQijYFBrgA+yohmgHwFIBMIoGNQa4IOsaAboRwASgTAKBrUG+CArmgH6EYBEIIyCQa0BPsiKZoB+BCARCKNgUGuAD7KiGaAfAUgEwigY1Brgg6xoBuhHABKBMAoGtQb4ICuaAfoRgEQgjIJBrQE+yIpmgH4EIBEIo2BQa4APsqIZoB8BSATCKBjUGuCDrGgG6EcAEoEwCga1BvggK5oB+hGARCCMgkGtAT7IimaAfgQgEQijYFBrKgJ1BEjDnqOKYV8c6Bt7QgEoC+RcwUDGFUF1xK9fIfyobIqiywoJlCBQPsi5goGMK0LVhqXff/mS4l8/f0Hx20+fU/z642cUv/zw6c/fb1H89N0zEz9++5Tih2+eUHz/9ePvvnpE8e2XDym++WLTxNefP/jqs/+l+PLT+xRfbH1C8fmz/6H47OkGxadP7lFsPb5L8ezRHYqnD29T0CuBk+gn/H6UXcm9yR1qelN2qNOn3K3Up063Oj1rOtf0rNO5tehf0GCQcwUDGVcEOAk4iUEEnAQAPsi5goGMKwKcBJzEIAJOAgAf5FzBQMYVAU4CTmIQAScBgA9yrmAg44oAJwEnMYiAkwDABzlXMJBxRYCTgJMYRMBJAOCDnCsYyLgiwEnASQwi4CQA8EHOFQxkXBHgJOAkBhFwEgD4IOcKBjKuCHAScBKDCDgJAHyQcwUDGVcEOAk4iUEEnAQAPsi5goGMK0LuYWlthnYRzKw7DbKHOpS7+yCcxMaxF2bOt8NJFNg7/UU2J/HR0lgwfuJWopN48NbOAytJTuLCS0Hw0gqcBKghyLmCgYwrguoIbxjoFGqsGll+Yh5uLE8Ek6c2Yg36i+KdxO3XRmhEbZGTGGDvZI9+ncTG62NBkOwkMCcBagtyrmAg44rQn5NYmQ/MWKUGLcP8mtkUrpmYmTfjWTQDEY5wvEYfc5LaTyxs/XKPD/Xqqhp+niwOB8HwBA0sxCtHT5qFsSObauC5uTiqH/Koc2l3EOzeP23W7XjrzvUF2ltDZqJlTiJD70Rrvlqfs2tUL/z61dYpMmC6U4i5hbA3u2ySRz50XTuJa9QZ06/OmnXDpzbJSXxMBkIxNjVrnMT9I+N6BTH29s0fvrn5DnfrwuFwMRg9vqachJiTuLTPbgqG/nqXevbci0Hw4vSUWfX8mzfhJEC1QM4VDGRcEVRH6IEka6ixSjC3QivV0GIGkicLk9oc6MFGuwS1JouTsEPa1pI61DMagR4dnwim10InsbT56c8f0hAxdPL+Mz3wDC3ef7p5YigYfWPTvoV9+Yp1EsH+i/Tm9R/7aew5dr19cxKCrr0TdkG0xliBuRW9RpsS1UYvqN3VQpdN+rl+f7ywK5i5YZ2EMYUXyKtMLN5+rDp037Xvt35+cJQMhJyTiHdobE7i/sKOYORvnwgnsXHshSD490tqTmL1+FAQTC1rJxFMn6POPU0eY/iNy3ASoFIg5woGMq4IqiPMIJQxePDQg5Z+yyvezirUVrVGvEnN4CTMpq/W7ZtXw/Dph8ZJTF//wTiJqdXvIiexSmYhYueJDTsn8YGaBl97e6SdTiJX79iQa4wbWGdvwb0TcxLJm5zneveRnZMgR/jbT3dOjSsncf1gEIy9+Sj+6UbUlZ6TuKz+FE3cSazQgYdfu6c/3bh79IVg6K939JzEBdW5V97cCScBKgdyrmAg44qgOkKPH1mDxyr7RjYcWuIjUzTYqDGGfYPZMZx153GIF2hHnpMIP1/v4CSit7B8nQScRK7eCdtHa2JzEvHeyeAk+Lmi6yQ8J+HPSaweCIL9ZxPnJK6oZziTZ04CTgJUF+RcwUDGFaEfJ2E8gR459PBj0DPqdkAi+DoJfw2PQ7ygRqDoOolg9kJnJyGvk6DxJtlJfPZ3Orra3srrJLr0TjhvQRFNJ2gr0JuTkEcOZi8lOomE6ySu2EsbxkfJEey5qqzhP1/Raw7MvKz/D0ZHdpie7XqdBJwEqCzIuYKBjCuC6gg9kAws1NDCw1XX8K/57/e7G+Ii/+Y7icqE34+yK7k3uUNNb8oOdfqUuxXf3QD1BTlXMJBxRYCTgJMYRMBJAOCDnCsYyLgiVG1YgpPoCpwEnASoKci5goGMU1mfn1zessvFs7W8vG4XNXAScBKDCDgJAHyQcwXTMBlvLU8OcvgvDnqh83AScBIDDzgJAHyQcwXTZCexPj85OUl/4Pw6rab/FeHwva4up1eP5+3MQzQDES6Z/zschDbR3mrF5PK63ag3JbXUByH0sW2D8BkV9FAOANsecBJdqVqXJQacBAA+yLmCaYyMo9FbY0wAD+zhmE2LalW0htqYpdA/REvm//SDyH2jBe04UlvytnALQ69ZDgDbHnASXalalyUGnAQAPsi5gmmYjMUoHloBPY4L1LrINohG4ar4muiR3V+j1/EuYoGcRKeWvAQnASdRSsBJAOCDnCuYhsk40Ul4o7ZoxrMF2gTEtpnd0w/Cm+SCmZNIbZl+OOoIkIY9RxXDvjjQN/aEAlAWyLmCabKMo/Gbxm1Tsgj2C+ZReJ2EcgGaSUKvMbt3OAhvEgt6S3pLXjJNhJmgR/Kt5LYH5iS6UrUuSwzMSQDgg5wrmNbLOBrktxc4CTiJQQScBAA+yLmCgZOAk0gMOImuwEnASYCagpwrGMi4IsBJwEkMIuAkAPBBzhUMZFwR4CTgJAYRcBIA+CDnCgYyrghwEnASgwg4CQB8kHMFAxlXBDgJOIlBBJwEAD7IuYKBjCsCnAScxCACTgIAH+RcwUDGFQFOAk5iEAEnAYAPcq5gSMagIsgBYNsDTqIrVeuyxICTAMAHOQeaCZwEnMQgAk4CAB/kHGgmcBJwEoMIOAkAfJBzoJnAScBJDCLgJADwQc6BZgInAScxiICTAMAHOQeaCZwEnMQgAk4CAB/kHGgmcBJwEoMIOAkAfJBzoJnAScBJDCLgJADwQc6ByrO1PNn1l8rX5+fX7aIBTgJOYhABJwGAD3IOVJv1eaqMQUcnQU5DtYm3oodyANj2gJPoStW6LDHgJADwQc6BKrO1vLzefU6C3Mb8uv7HriDgJOAkBhFwEgD4IOdA5cny6YYHnAScxCACTgIAH+QcqDxwEnASlQk4CQB8kHOg8sBJwElUJuAkAPBBzoHKI50EL3ezF3AScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWYCJwEnMYiAkwDABzkHmgmcBJzEIAJOAgAf5BxoJnAScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWYCJwEnMYiAkwDABzkHmgmcBJzEIAJOAgAf5BxoJnAScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWYCJwEnMYiAkwDABzkHmgmcBJzEIAJOAgAf5BxoJnAScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWYCJwEnMYiAkwDABzkHmgmcBJzEIAJOAgAf5BxoJnAScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWYCJwEnMYiAkwDABzkHmgmcBJzEIAJOAgAf5BxoJnAScBKDCDgJAHyQc6CZwEnASQwi4CQA8EHOgWZSi2FpWwJOotkBJwHKBzkHmgnVU5CGPUcVw7440Df2hAJQFsg5AAAAAPQOnAQAAAAAegdOAgAAAAC9AycBAAAAgF75v//7/wBt6mGg2jSvTQAAAABJRU5ErkJggg==" mimetype="image/png" id="_86514e24-a06f-0af0-53d1-1268764bafac" height="auto" width="auto"/>
+</figure>
2
002613_f13846da-3c06-cda0-02ad-cf27c2daf5e2Table should have title
<table id="_f13846da-3c06-cda0-02ad-cf27c2daf5e2" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
+<th valign="middle" align="center">Organization Represented</th>
+</tr> <tr> <td valign="middle" align="left">Simon Cox</td>
+<td valign="middle" align="left">CSIRO</td>
+</tr> <tr> <td valign="middle" align="left">David Danko</td>
2

+
Document Attributes

+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
--Draft is not a recognised status
2

+
Metanorma XML Syntax

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
XML Line 000004:42attribute "format" not allowed here; expected attribute "locale",​ "script" or "type"
2
XML Line 000005:148character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000005:194character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000017:144character content of element "subdoctype" invalid; must be equal to "conceptual-model", "conceptual-model-and-encoding", "conceptual-model-and-implementation", "encoding", "extension", "general", "implementation", "profile" or "profile-with-extension"
2
XML Line 000068:82element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000075:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000087:71element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000103:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000106:61element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000115:58element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000123:102element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000162:52element "clause" not allowed here; expected the element end-tag or element "admonition", "amend", "bookmark", "columnbreak", "dl", "example", "figure",​ "form", "formula", "hr", "imagemap", "note", "ol", "p", "pagebreak", "passthrough", "permission", "pre", "quote", "recommendation", "requirement", "review",​ "sourcecode", "svgmap",​ "table", "toc" or "ul"
2
XML Line 000183:65element "clause" not allowed here; expected the element end-tag or element "admonition", "amend", "bookmark", "columnbreak", "dl", "example", "figure",​ "form", "formula", "hr", "imagemap", "note", "ol", "p", "pagebreak", "passthrough", "permission", "pre", "quote", "recommendation", "requirement", "review",​ "sourcecode", "svgmap",​ "table", "toc" or "ul"
2
XML Line 000569:112element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000569:229element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000584:109element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000584:245element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 001089:11element "example" incomplete; expected element "dl", "figure",​ "formula", "ol", "p", "quote", "sourcecode" or "ul"
2
XML Line 002112:129element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 002112:18element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 002531:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002533:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002537:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002539:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002545:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002547:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002549:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002552:257attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002554:146found attribute "format",​ but no attributes allowed here
2
XML Line 002556:215element "link" missing required attribute "target"
2
XML Line 002556:82found attribute "format",​ but no attributes allowed here
2
XML Line 002557:217element "link" missing required attribute "target"
2
XML Line 002557:82found attribute "format",​ but no attributes allowed here
2
XML Line 002559:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002561:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002563:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002565:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002570:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002572:144found attribute "format",​ but no attributes allowed here
2
XML Line 002575:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002578:295found attribute "format",​ but no attributes allowed here
2
XML Line 002579:97found attribute "format",​ but no attributes allowed here
2
XML Line 002581:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002584:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002587:295found attribute "format",​ but no attributes allowed here
2
XML Line 002588:97found attribute "format",​ but no attributes allowed here
2
XML Line 002590:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002597:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002603:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002609:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002611:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002613:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002615:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002620:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002622:146found attribute "format",​ but no attributes allowed here
2
XML Line 002623:110found attribute "format",​ but no attributes allowed here
2
XML Line 002625:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002628:294found attribute "format",​ but no attributes allowed here
2
XML Line 002629:97found attribute "format",​ but no attributes allowed here
2
XML Line 002630:97found attribute "format",​ but no attributes allowed here
2
XML Line 002631:97found attribute "format",​ but no attributes allowed here
2
XML Line 002632:97found attribute "format",​ but no attributes allowed here
2
XML Line 002633:97found attribute "format",​ but no attributes allowed here
2
XML Line 002634:97found attribute "format",​ but no attributes allowed here
2
XML Line 002635:97found attribute "format",​ but no attributes allowed here
2
XML Line 002636:97found attribute "format",​ but no attributes allowed here
2
XML Line 002637:97found attribute "format",​ but no attributes allowed here
2
XML Line 002638:97found attribute "format",​ but no attributes allowed here
2
XML Line 002640:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002642:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002645:294found attribute "format",​ but no attributes allowed here
2
XML Line 002646:97found attribute "format",​ but no attributes allowed here
2
XML Line 002647:97found attribute "format",​ but no attributes allowed here
2
XML Line 002648:97found attribute "format",​ but no attributes allowed here
2
XML Line 002649:97found attribute "format",​ but no attributes allowed here
2
XML Line 002650:97found attribute "format",​ but no attributes allowed here
2
XML Line 002651:97found attribute "format",​ but no attributes allowed here
2
XML Line 002652:97found attribute "format",​ but no attributes allowed here
2
XML Line 002653:97found attribute "format",​ but no attributes allowed here
2
XML Line 002655:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2

+
diff --git a/sources/document.html b/sources/document.html
index f1cd39f..de99389 100644
--- a/sources/document.html
+++ b/sources/document.html
@@ -1347,9 +1347,9 @@
   
 
     

-      Submission Date:  2024-11-29
-      Approval Date:  2029-11-01
-      Publication Date:  2029-11-01
+      Submission Date:  2024-12-10
+      Approval Date:  2025-xx-xx
+      Publication Date:  2025-xx-xx
       External identifier of this OGC® document: 
       Internal identifier of this OGC® document: 08-131r3
       
@@ -1438,78 +1438,65 @@
 

 
 
 
@@ -1524,67 +1511,89 @@
 

 
 

-

I.  Preface
This OGC member developed and approved document defines a model and related requirements and recommendations for writing and structuring modular standards documents. Further, this model is designed to enable the consistent and verifiable testing of implementations of a standard that claim conformance.
The goal is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
NOTE  1:    For OGC only: Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard shall comply with the requirements stated in this document.
NOTE  2:    Historically, this document has been known and abbreviated as the “ModSpec”. For continuity and ease of understanding this document may also be refered to as the “OGC ModSpec”.
Suggested additions, changes, and comments on this this document are welcome and
+


I.  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 the consistent and verifiable testing of implementations of a standard that claim conformance.
The goal is to ensure that a standard specifies requirements in a common and consistent manner and that these requirements are testable.
NOTE:    Historically, this document has been known and abbreviated as the “ModSpec”. For continuity and ease of understanding this document may also be refered to as the “OGC ModSpec”.
Suggested additions, changes, and comments on this this document are welcome and
 encouraged. Such suggestions may be submitted through the OGC Change Request System
-(http://www.opengeospatial.org/standards/cr) or by creating an issue in the GitHub repository for this document (https://github.com/opengeospatial/ogc-modspec).
II.  Security considerations
No security considerations have been made for this document.
III.  Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
  • Carl Reed, Heazeltech, ImageMatters
IV.  Document terms and definitions
This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008], which
+(http://ogc.standardstracker.org/) or by creating an issue in the OGC ModSpec GitHub repository (https://github.com/opengeospatial/ogc-modspec).
II.  Security considerations
No security considerations have been made for this document.
III.  Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
  • Carl Reed, Charles Heazel, ImageMatters
IV.  Document terms and definitions
This document uses the standard terms defined in Subclause 5.3 of [OGC 05-008], which
 is based on the ISO/IEC Directives, Part 2. Rules for the structure and drafting of
 International Standards. In particular, the word “shall” (not “must”) is the
 imperative verb form used to indicate a requirement to be strictly followed to
-conform to this standard.
V.  Document editors
The following OGC Members participated in editing this document:
PersonOrganization Represented
Carl ReedCarl Reed & Associates
Chuck HeazelHeazeltech
VI.  Document Contributors
The following OGC Members contributed and particpated in developing Version 2 of the ModSpec.
PersonOrganization Represented
Simon CoxCSIRO and OGC Fellow
Chuck HeazelHeazeltech
Clemens Porteleinteractive instruments GmbH
Jeff YutzlerImageMatters
VII.  Revision history
This is the second normative version of this document.
VIII.  Future work
Improvements to this document will be made based on implementation and changing technical requirements. Planned extensions include:
  • ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL.
    
+conform to the ModSpec.
V.  Document editors
The following OGC Members participated in editing this document:
PersonOrganization Represented
Carl ReedCarl Reed & Associates
Chuck HeazelCharles Heazel
VI.  Document Contributors
The following OGC Members contributed and particpated in developing Version 2 of the ModSpec.
PersonOrganization Represented
Simon CoxCSIRO and OGC Fellow
Chuck HeazelCharles Heazel
Clemens Porteleinteractive instruments GmbH
Jeff YutzlerImageMatters
VII.  Revision history
This is the second normative version of this document.
VIII.  Future work
Improvements to this document will be made based on implementation and changing technical requirements. 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.
    
 
    • 
-
IX.  Foreword
This OGC document (aka the ModSpec) specifies a formal structure for standards documents but does not supply
-specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, [cls-6]
-and the Conformance Test Suite Annex A.1).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
X.  Acknowledgements
The following OGC Members were key contributors to Version 1 of the ModSpec
PersonOrganization Represented
Simon CoxCSIRO
David DankoESRI
James GreenwoodSeiCorp, Inc.
John R. HerringOracle USA
Andreas MatheusUniversity of the Bundeswehr — ITS
Richard PearsallUS National Geospatial-Intelligence Agency (NGA)
Clemens Porteleinteractive instruments GmbH
Barry ReffUS Department of Homeland Security (DHS)
Paul ScarponciniBentley Systems, Inc.
Arliss WhitesideBAE Systems — C3I Systems
1.  Scope
The ModSpec defines characteristics and structure for the specification of Standards
+
IX.  Foreword
The OGC ModSpec — A Standard for Designing and Writing Modular Standards specifies a formal structure and requirements for writing modular standards documents. However, the ModSpec does not supply specific content. Where possible, this document is conformant with itself (with respect to the core conformance test class, [cls-6]
+and the Conformance Test Suite Annex A.1).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
1.  Scope
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.
    
+
    • 
+
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.
NOTE:    For OGC Standards work, the word “standard” in this document applies to all OGC draft standards, approved standards, draft Abstract Specifications, and approved Abstract Specifications. The exceptions are OGC Abstract Specifications that originate in ISO or Community Standards that are developed external to the OGC and then submitted to the OGC.
[Annex-B] defines the UML model upon which the ModSpec is
-based. Annex B also contains informal and non-normative definitions ordered for ease
+requirements, mimicking implementation structure, and maximizing usability and
+interoperability. The ultimate goal of this approach is to enable interoperable implementations of a standard to be tested and deemed conformant or not.
Therefore, a standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards. The approach modelled in the ModSpec has been referred to as the “core and extension model” due to its insistence on a modular structure throughout all parts of a standard and its implementation.
There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the OGC API — Common Part 1: Core Standard and in the CDB 2.0 Standard CRS Requirements Module. By formally implementing the requirements specified in the ModSpec, reusable, testable, modular standards can be developed.
1.1.  Understanding the ModSpec

+
+
Reading the Terms and Definitions clause and Clause cls-4 will help understanding the content and
+requirements stated in this document.

+
+
annex-C defines the UML model upon which the ModSpec is
+based. Annex C also contains informal and non-normative definitions ordered for ease
 of understanding. These two sections can be read first to aid in the understanding of
-the rest of the document.
2.  Conformance
Conformance to the ModSpec by technical implementation standards
-can be tested by inspection. The test suite is in Annex A.
There are five (5) conformance classes for this document:
  1. Standards documents in general (the core) — see [cls-6] and Annex A.1
    
+the rest of the document.
    NOTE  1:    For OGC Standards work, the word “standard” in the ModSpec applies to all OGC draft standards, approved standards, draft Abstract Specifications, and approved Abstract Specifications. The exceptions are OGC Abstract Specifications that originate in ISO or Community Standards that are developed external to the OGC and then submitted to the OGC.
    NOTE  2:    Please note that the ModSpec has been approved by the OGC Membership as a policy directive for the development and revision of any OGC Standard or Abstract Specification that has requirements. However, the ModSpec is written to be non-OGC specific and can be used by any Standards Development Organization (SDO) as a formal guide for structuring a standards document.
    NOTE  3:    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.
    
+
+
+
+
+
+
+
1.2.  ModSpec document structure

+
+
Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are:

+
+
  • Core: contains all the core requirements and informational text that define the model and internal structure of a standard.
    
 
    • 
-
  • Standards using UML to state requirements, extending the core — see
-Clause 10.2.2 and Annex A.2
    
+
  • Part 1: UML Model requirements
    
 
    • 
-
  • Standards using XML schema to state requirements, extending the core — see
-Clause 10.2.3 and Annex A.3
    
+
  • Part 2: XML and Schematron Model requirements
    
+
    • 
+

+
+
Future Parts to the ModSpec Standard may include:

+
+
  • Part 3: RDF/OWL requirements
    
 
    • 
-
  • Standards using Schematron to state requirements, extending XML schema — see
-Clause 10.2.4 and Annex A.4
    
+
  • Part 4: JSON Schema
    
 
    • 
-
  • Standards defining requirement for a new category of XML schemas, extending
-the core, whose target XML schemas must be conformant with the XML schema conformance
-class above — see Clause 10.2.5 and Annex A.5.
    
+

+
2.  Conformance
Conformance to the ModSpec by technical implementation standards
+can be tested by inspection. The test suite is in Annex A.
There is one conformance class for this document:
  1. The Core: Common requirements for standards documents in general. See [cls-6] and Annex A.1
    
 
    2. 
-
This document contains normative language and thus places requirements on
+
This document contains normative language and thus places requirements on
 conformance, or mechanism for adoption, of candidate standards to which the ModSpec
-applies. In particular:
  • [cls-6] specifies the core requirements which shall be met by all conformant
+applies. In particular:
    • [cls-6] specifies the core requirements which shall be met by all conformant
 standards.
      
 
      • 
-
    • Clause 10 gives information on how the ModSpec is to be applied to requirements,
-conformance clauses, UML models, or XML Schemas.
      
+
    • Clause 9 gives information on how the ModSpec is to be applied to extensions to the core model for requirements and
+conformance clauses.
      
 
      • 
-
    The various subclauses of Clause 10 list requirements partially derived from the
-core, but more specific to the conditions where a data model expressed in one of the
-specified languages (UML or XML) is involved. These requirements classes are
-extensions of the core presented in [cls-6].
3.  Normative references

-
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.

+
Such extensions are defined in additional Parts (volumes) to the Core.
3.  Normative references

+
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/IEC: ISO/IEC 10000-1, ISO, IEC

 
ISO/IEC DIR 2, ISO/IEC Directives, Part 2. https://www.iso.org/sites/directives/current/part2/index.xhtml.

-
ISO: ISO 19105, Geographic information — Conformance and testing. International Organization for Standardization, Geneva https://www.iso.org/standard/76457.html.

-
ISO/IEC: ISO/IEC 19501, Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/32620.html.

-
OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2, OMG Document Number: formal/2007-11-04, Standard document URL: http://www.omg.org/spec/UML/2.1.2/Infrastructure/PDF

-
OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, OMG Document Number: formal/2007-11-02; Standard document URL: http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF

+
ISO: ISO 19105:2022, Geographic information — Conformance and testing. International Organization for Standardization, Geneva (2022). https://www.iso.org/standard/76457.html.

+
OMG Unified Modeling Language (OMG UML), Infrastructure, V2.5, OMG Document Number: formal/2015-03-01, Standard document URL: https://www.omg.org/spec/UML/2.5

+
OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1, OMG Document Number: formal/2012-05-07; Standard document URL: https://www.omg.org/spec/UML/ISO/19505-2/PDF

 
ISO/IEC: ISO/IEC 19757-3:2006, Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron. International Organization for Standardization, International Electrotechnical Commission, Geneva (2006). https://www.iso.org/standard/40833.html.

 
W3C: W3C xmlschema-1, XML Schema Part 1: Structures Second Edition. World Wide Web Consortium https://www.w3.org/TR/xmlschema-1/.

 
W3C: W3C xmlschema-2, XML Schema Part 2: Datatypes Second Edition. World Wide Web Consortium https://www.w3.org/TR/xmlschema-2/.

-
4.  Terms and definitions

+
4.  Terms and definitions

 
 
 
For the purposes of this document, the following terms and definitions shall apply.
@@ -1592,179 +1601,158 @@
 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 [cls-6-1].

-
+
Many of these definitions depend upon the model given in annex-C.

 
-
4.1. all-components schema document

-
XML schema document which includes, either directly or through the inclusion of
-other schema documents, all schema components associated to its namespace

 
+
4.1. building block

+
a requirements class or a requirements module with no direct dependencies on other requirements classes or modules and their associated compliance test class or compliance test module.

 
-
4.2. building block

-
a requirements class or a requirements module and their associated compliance test class or compliance test module.

 
-
-
4.3. certificate of conformance

-
evidence of conformance to all or part of a standard, awarded for passing one or
-more of the conformance test classes (Clause 4.7) specified in
+
4.2. certificate of conformance

+
evidence of conformance to all or part of a standard, awarded for passing one or
+more of the conformance test classes (Clause 4.6) specified in
 that standard

 
 
- 
Note 1 to entry: “Certificates” do not have to be instantiated documents. Having proof of passing
+ 
Note 1 to entry: “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 https://www.ogc.org/resources/certified-products/.
Each certificate of conformance is awarded to a standardization target (Clause 4.26).

+an online list of conformant applications at https://www.ogc.org/resources/certified-products/.
Each certificate of conformance is awarded to a standardization target (Clause 4.26).

 
-
4.4. conformance test

-
test, abstract or real, of a single requirements (Clause 4.21) contained
+
4.3. conformance test

+
test, abstract or real, of a single requirements (Clause 4.21) contained
 within a standard, or set of standards

 
 
-
4.5. conformance test case

-
test for a particular requirement or a set of related requirements

-
+
4.4. conformance test case

+
test for a particular requirement or a set of related requirements

 
- 
Note 1 to entry: When no ambiguity, the word “case” may be omitted. i.e.
-conformance test (Clause 4.4) is the same as
-conformance test case (Clause 4.5).

 
-
4.6. conformance test module

-
set of related for against a given requirements module all with the same standardization target

+ 
Note 1 to entry: When no ambiguity, the word “case” may be omitted. i.e.
+conformance test is the same as conformance test case.

 
+
4.5. conformance test module

+
set of related tests for a given requirements module all with the same standardization target

 
 
+ 
Note 1 to entry: When there is no ambiguity, the word “test” may be omitted. i.e. conformance test module
+is the same as conformance module. Conformance modules may be nested in a hierarchical way.

 
- 
Note 1 to entry: When there is no ambiguity, the word “test” may be omitted. i.e. conformance test module (Clause 4.6)
-is the same as conformance module. Conformance modules may be nested in a hierarchical way.
[SOURCE: ISO 19105]

+
4.6. conformance test class
conformance class ALTERNATIVE

 
-
4.7. conformance test class
conformance test level ALTERNATIVE

 
 
+
set of conformance tests that must be passed to receive a single certificate of conformance (Clause 4.2)

 
-
set of term conformance tests, display conformance test not resolved via ID conformance-tests that must be passed to receive a single certificate of conformance (Clause 4.3)

 
+ 
Note 1 to entry: When no ambiguity is possible, the word “test” may be left out, so conformance test class
+maybe called a conformance class.
In the ModSpec, the set of requirements (Clause 4.21) tested by the
+conformance tests within a conformance class is a
+requirements class and its dependencies. Optional requirements will
+be in a separate requirements class (Clause 4.22) with other requirements
+that are part of the same option. Each requirements class corresponds to a
+separate conformance test class.
Each requirements class will be in a 1 to 1 correspondence to a similarly named
+conformance test class (Clause 4.6) that tests all of the requirements in a requirements class.
All requirements (Clause 4.21) in a conformance class will have the same standardization target (Clause 4.26).

 
- 
Note 1 to entry: When no ambiguity is possible, the word “test” may be left out, so conformance test class (Clause 4.7)
-maybe called a conformance class.
In the ModSpec, the set of requirements (Clause 4.21) tested by the
-conformance tests within a conformance class is a
-requirements class (Clause 4.22) and its dependencies. Optional requirements (Clause 4.21) will
-be in a separate requirements class (Clause 4.22) with other requirements (Clause 4.21)
-that are part of the same option. Each requirements class (Clause 4.22) corresponds to a
-separate conformance class
Each requirements class will be in a 1 to 1 correspondence to a similarly named
-conformance class that tests all of the
-requirements class’s (Clause 4.22) requirements (Clause 4.21).
All requirements (Clause 4.21) in a conformance class
-will have the same standardization target (Clause 4.26).

+
4.7. conformance suite
conformance test suite ALTERNATIVE
abstract test suite ALTERNATIVE

 
-
4.8. conformance suite
conformance test suite ALTERNATIVE
abstract test suite ALTERNATIVE

 
 
 
 
+
set of conformance classes that define tests for all requirements of a standard or abstract specification

 
-
set of conformance classes that define tests for all requirements (Clause 4.21) of a standard or abstract specification

 
+ 
Note 1 to entry: The conformance suite is the union of all conformance classes. It is by definition the
+conformance class of the entire standard or abstract specification.
In the ModSpec, each requirement (Clause 4.21) is mandatory within its conformance class and each requirement (Clause 4.21) is tested in at least one conformance test (Clause 4.3).

 
- 
Note 1 to entry: The conformance suite (Clause 4.8) is the union of all conformance classes. It is by definition the
-conformance class of the entire standard or abstract specification.
In this Policy, each requirement (Clause 4.21) is mandatory within its conformance class and each requirement (Clause 4.21) is tested in at least one conformance test (Clause 4.4).

-
-
4.9. core requirements class

-
unique requirements class (Clause 4.22) that must be satisfied by any conformant
+
4.8. core requirements class

+
unique requirements class (Clause 4.22) that must be satisfied by any conformant
 standardization targets (Clause 4.26) associated to the
 standard

 
 
- 
Note 1 to entry: The core requirements class (Clause 4.22) is unique because if it were possible to have
+ 
Note 1 to entry: 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 (Clause 4.7), and thus would have to be contained in any other
+conformance test class (Clause 4.6), 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.
The “core” can refer to this requirements class (Clause 4.22), its associated
-conformance test class (Clause 4.7) or the software module that implements that
+set of standards.
The “core” can refer to this requirements class, its associated
+conformance test class (Clause 4.6) or the software module that implements that
 requirements class.

 
-
4.10. direct dependency (of a requirements class)

-
another requirements class (Clause 4.22) (the dependency) whose requirements (Clause 4.21) are defined to also be
-requirements (Clause 4.21) of this
-requirements class (Clause 4.22)

-
-
- 
Note 1 to entry: A  direct dependency (Clause 4.10)
-of the current requirements class (Clause 4.22) will have the same
-standardization target (Clause 4.26) as the current
-requirements class (Clause 4.22). This is another ways of saying that the current
-requirements class (Clause 4.22) extends, or uses all the aspects of the
- direct dependency (Clause 4.10).
-Any tests associated with this
-dependency (Clause 4.10) can be applied to this
-requirements class (Clause 4.22).
When testing a
- direct dependency (Clause 4.10), the
-standardization target (Clause 4.26) is directly subject to the test in the specified
-conformance test class (Clause 4.7) of the  direct dependency (Clause 4.10).

-
-
4.11. indirect dependency (of a requirements class)

-
requirements class (Clause 4.22) with a different
+
4.9. direct dependency (of a requirements class)

+
another requirements class (Clause 4.22) (the dependency) whose requirements (Clause 4.21) are defined to also be
+requirement(s) of this requirements class

+
+
+ 
Note 1 to entry: A direct dependency (of a requirements class) of the current requirements class (Clause 4.22) will have the same
+standardization target (Clause 4.26) as the current requirements class. This is another way of saying that the current
+requirements class extends, or uses all the aspects of the direct dependency (of a requirements class).
+Any tests associated with this direct dependency (of a requirements class) can be applied to this requirements class.
When testing a direct dependency of a requirements class, the standardization target is directly subject to the test in the specified
+conformance test class (Clause 4.6) of the direct dependency of a requirements class.

+
+
4.10. indirect dependency (of a requirements class)

+
requirements class (Clause 4.22) with a different
 standardization target (Clause 4.26) which is used, produced or associated to by the
 implementation of this requirements class (Clause 4.22)

 
 
- 
Note 1 to entry: In this instance, as opposed to the
-direct dependency (Clause 4.10),
-the test against the consumable or product used
+ 
Note 1 to entry: 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 (Clause 4.22) does not directly test the
-requirements class (Clause 4.22), but tests only its side effects. Hence, a particular
+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 (Clause 4.10)
-test the same standardization target (Clause 4.26), but
- indirect dependencies (Clause 4.11)
-test related but different standardization targets (Clause 4.26).
For example, if a DRM-enabled service is required
+Direct dependencies test the same standardization target (Clause 4.26), but
+indirect dependencies}} test related but different standardization target,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 (Clause 4.3) of a particular kind.

+certificate of conformance (Clause 4.2) of a particular kind.

 
-
4.12. extension (of a requirements class)

-
requirements class (Clause 4.22) which has a
- direct dependency (Clause 4.10) on another
-requirements class (Clause 4.22)

+
4.11. extension (of a requirements class)

+
requirements class (Clause 4.22) which has a direct dependency on another requirements class

 
 
- 
Note 1 to entry: Here extension (Clause 4.12) is
-defined on requirements class (Clause 4.22) so that their implementation may be
-software extensions in a manner analogous to the extension relation between the
-requirements classes (Clause 4.22).

+ 
Note 1 to entry: Here an extension of a requirements class is defined on requirements class so that their implementation may be
+software extensions in a manner analogous to the extension relation between the requirements classes.

 
-
4.13. general recommendation

-
recommendation applying to all entities in a standard

+
4.12. general recommendation

+
recommendation applying to all entities in a standard

 
 
-
4.14. home (of a requirement or recommendation)

-
official statement of a requirement (Clause 4.21) or recommendation (Clause 4.20) that is the
+
4.13. home (of a requirement or recommendation)

+
official statement of a requirement (Clause 4.21) or recommendation (Clause 4.20) that is the
 precedent for any other version repeated or rephrased elsewhere in a standard

 
 
- 
Note 1 to entry: Explanatory text associated with normative language often repeats or rephrases the
+ 
Note 1 to entry: Explanatory text associated with normative language often repeats or rephrases the
 requirement to aid in the discussion and understanding of the official version
 of the normative language. Since such restatements are often less formal than
 the original source and potentially subject to alternate interpretation, it is
 important to know the location of the home official version of the language.

 
-
4.15. model
abstract model ALTERNATIVE
conceptual model ALTERNATIVE

+
4.14. model
abstract model ALTERNATIVE
conceptual model ALTERNATIVE

 
 
 
 
 
-
theoretical construct that represents something, with a set of variables and a
+
theoretical construct that represents something, with a set of variables and a
 set of logical and quantitative relationships between them.

 
 
-
4.16. module

-
one of a set of separate parts that can be joined together to form a larger object

+
4.15. module

+
one of a set of separate parts that can be joined together to form a larger object

+
+
 
+
4.16. optional requirements class

+
An optional requirements class may or may not be implemented or specified in a profile or extension. However, if a profile, extension, or implementation specifies the use of an optional requirements class, then every requirement in that requirements class shall be implemented.

 
 
-
4.17. optional requirements class

-
An optional requirements class may or may not be implemented or specified in a profile or extension. However, if a profile, extension, or implementation specifies the use of an optional requirements class, then every requirement in that requirements class shall be implemented.

+
4.17. part of a requirment

+
Collection of requirements that are parts to a requirement. Satisfaction of all requirement parts are necessary for this requirement to be satisfied. The use of parts is optional.

 
 
 
4.18. permission

@@ -1775,7 +1763,7 @@ 
4.18. perm
 
4.19. 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 (Clause 4.7),
+conformance test classes (Clause 4.6),
 conforming subsets, options and parameters of those base standards, or
 profiles necessary to accomplish a particular function.

 
@@ -1800,9 +1788,9 @@ 
4.20. 
 
 
 
- 
Note 1 to entry: Although using normative language, a recommendation (Clause 4.20) is not
+ 
Note 1 to entry: Although using normative language, a recommendation is not
 a requirement (Clause 4.21). The usual form replaces the “shall” (imperative or
-command) of a requirement (Clause 4.21) with a “should” (suggestive or
+command) of a requirement with a “should” (suggestive or
 conditional).
Note 2 to entry: Recommendations are not tested and therefor have no related conformance test.
[SOURCE: ISO/IEC DIR 2]

 
 
4.21. requirement

@@ -1812,22 +1800,20 @@ 
4.21. req
 
 
 
- 
Note 1 to entry: Each requirement (Clause 4.21) is a normative criterion for a single
-type of standardization target. In the ModSpec, requirements are
-associated to  conformance tests (Clause 4.4) that can be used to prove
-compliance to the underlying criteria by the standardization target (Clause 4.26).
The implementation of a requirement (Clause 4.21) is dependent on the type of
+ 
Note 1 to entry: Each requirement is a normative criterion for a single type of standardization target. In the ModSpec, requirements are
+associated to  conformance tests (Clause 4.3) that can be used to prove
+compliance to the underlying criteria by the standardization target (Clause 4.26).
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 (Clause 4.21) allows us to
-use set descriptions of both the standard and its implementations.
Requirements (Clause 4.21) use normative language and are
-commands and use the imperative “shall” or similar imperative constructs.
+standard in terms of a set of testable requirements allows for
+using set descriptions of both the standard and its implementations.
Requirements use normative language and 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.
[SOURCE: ISO/IEC DIR 2]

 
 
4.22. requirements class

 
aggregate of all term requirements, display requirement not resolved via ID requirements with a single standrdization target that
-must all be satisfied to pass a conformance test class (Clause 4.7)

+must all be satisfied to pass a conformance test class (Clause 4.6)

 
 
  
Note 1 to entry: There is some confusion possible here, since the testing of indirect
@@ -1844,34 +1830,34 @@ 
4.23.
 
 
4.24. specification

 
document containing recommendations (Clause 4.20),
-requirements (Clause 4.21) and  conformance tests (Clause 4.4) for
+requirements (Clause 4.21) and  conformance tests (Clause 4.3) for
 those requirements (Clause 4.21)

 
 
- 
Note 1 to entry: This definition is included for completeness. See Clause 7.4.
This does not restrict what else a standard may contain, as long as it does
-contain the three types of element cited.

+
+
+ 
Note 1 to entry: This definition is included for completeness.
Note 2 to entry: 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.
+Implementatins Standards are always testable and contain a conformance test suite (Clause 4.7).

 
 
4.25. standard

 
document that has been approved by a legitimate Standards Body

 
 
- 
Note 1 to entry: This definition is included for completeness. Standard (Clause 4.25) and
-specification (Clause 4.24) can apply to the same document. While specification (Clause 4.24) is
-always valid, standard (Clause 4.25) only applies after the adoption of the document by a
+ 
Note 1 to entry: This definition is included for completeness. Standard (Clause 4.25) and
+specification (Clause 4.24) 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.

 
 
4.26. standardization target

 
entity to which some requirements (Clause 4.21) of a standard (Clause 4.25) apply

 
 
-
-
- 
Note 1 to entry: The standardization target (Clause 4.26) is the entity which may receive a
-certificate of conformance (Clause 4.3) for a requirements class (Clause 4.22).
Note 2 to entry: Need to add examples! The standardization target of the CDB version 2.0 CRS Requirements Classes is to ensure that an implementation clearly defines (with metadata) the CRS for a CDB compliant datastore.

+ 
Note 1 to entry: The standardization target is the entity which may receive a
+certificate of conformance (Clause 4.2) for a requirements class (Clause 4.22).

 
 
4.27. standardization target type

-
type of entity or set of entities to which the requirements (Clause 4.21) of a
-standard (Clause 4.25) apply

+
type of entity or set of entities to which the requirements (Clause 4.21) of a standard (Clause 4.25) apply

 
 
  
Note 1 to entry: 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 and 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.

@@ -1882,352 +1868,118 @@ 
4.28. state
 
 
 
- 
Note 1 to entry: Includes all statements in a document not part of the normative
-requirements (Clause 4.21),
-recommendations (Clause 4.20) or
- conformance tests (Clause 4.4). Included for completeness.
[SOURCE: ISO/IEC DIR 2]

-
6.  Introduction
NOTE  1:    Reading the Terms and Definitions clause and Clause <TBD> will help understanding the content and
-requirements stated in this document.
This OGC document, 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”).
    
-
    • 
-
  • 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.
    
-
    • 
-
The goal of this approach is to enable implementations of a standard to be tested and deemed conformant or not.
NOTE  2:    Please note that the ModSpec has been approved by the OGC Membership as a policy directive for the development and revision of any OGC Standard or Abstract Specification that has requirements. However, the ModSpec is written to be non-OGC specific and can be used by any Standards Development Organization (SDO) as a formal guide for structuring a standards document.
A standard that follows the rules specified in the ModSpec presents requirements organized in requirements classes which must be satisfied by passing the tests defined in a conformance suite (also known as the Abstract Test Suite in an OGC Standard). These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. This results in a standard having a modular structure, where each requirements class has a corresponding conformance (test) class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the requirements and conformance clauses. A goal of the design pattern is the ability to define requirements classes and associated conformance classes that can be used across multiple standards.
There are numerous examples of requirements/conformance classes that can be used not only in OGC Standards, but for geospatially focused standards defined by other organizations and Standards Development Organizations (SDOs). Some OGC examples can be found in the OGC API — Common Part 1: Core Standard and in the CDB 2.0 Standard CRS Requirements Module. By formally implementing the requirements specified in the ModSpec, reusable, modular standards can be developed.
6.1.  Conformance, Requirements, and key information

-
-
In the conformance test suite there will be a test defined to verify the validity of
-the claim that an implementation of the standard (standardization target) satisfies
-each mandatory requirement specified in the standard. Since the normative language of the body of the standard and the
-conformance test classes both define what conformance to the standard means, they
-will be equivalent in a well-written standard. The ModSpec requires
-a standards document to be well-written, at least in stating requirements and conformance
-tests.

-
-
Conformance tests are aggregated into conformance classes that specify how certain
-“certificates of conformance” are achieved. The natural inclination is to aggregate
-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
-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 to achieve a particular conformance class (see
-Clause 4.7). This document also includes a “middle” structure
-called a conformance test module. Requirements modules
-parallel the conformance test modules. A standard written to the ModSpec may
-use this “module” structure in any manner consistent with the rest of this Policy.

-
-
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.
-Each requirement within an optional requirements class is mandatory when that requirements class is
-implemented. When needed, a particular requirements class may contain only a single
-requirement.

-
-
However, care must be taken, since the requirements classes may not always in a one-to-one
-correspondence to conformance classes in other standards which may be the source of
-requirements for a standard conformant to this Policy. If other standards are
-used, their options shall be specified to be useable within a standard conformant to
-this policy, see Clause 9.4.1.

-
-
Conformance classes may contain dependencies on one another. These are represented by
-tests in one conformance class that state that another conformance class must be
-passed to qualify to pass this conformance class. In terms of requirements, that says
-that the dependent conformance class contains tests (by reference) for all
-requirements of the “included” conformance class.

-
-
As defined in the ModSpec, one requirements
-class is dependent on another if the other is included through such a reference. In
-this manner, requirements classes can be treated as sets of requirements (each in a
-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 Table 1 above.

-
-
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 Table 13 and Table 14.

-
6.2.  The ModSpec and the “Form” of a standard

-
-
NOTE:    For OGC Standards, the assumptions is that documents are in a commonly used
-logical form (template).

-
-
This form should be specified by the following descriptions:

-
-
  1. A standards document contains Clauses (corresponding to numbered sections as they might
-appear in a table of contents) which describe its standardization target and its requirements.
    
-
    2. 
-
  2. A standard contains Annexes or is associated to other documents (both a
-logical type of Clause), one of which is the Conformance Test Suite (which may be an
-abstract description of the test suites to be implemented separately). In OGC Documents, this is Annex A – Abstract Test Suite.
    
-
    3. 
-
  3. All requirements, recommendations, permissions, and models are introduced and defined first in
-the numbered Clauses.
    
-
    4. 
-
  4. All requirements are identifiable as requirements.
    
-
    5. 
-
  5. All requirements in a document are uniquely numbered.
    
-
    6. 
-
  6. All tests for conformance to those requirements are defined in the Conformance Test Suite.
    
-
    7. 
-
  7. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.
    
-
    8. 
-
  8. The tests, if conducted, determine to some degree of certainty whether an
-implementation meets the requirements which the tests reference.
    
-
    9. 
-
  9. The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard
-does not do this, it is has by default only one “conformance class”.
    
-
    10. 
-
  10. Certificates of conformance (see Clause 4.1) are
-awarded by a testing entity based on these conformance classes.
    
-
    11. 
-
  11. There is a clear distinction between normative and informative parts of the text.
    
-
    12. 
-
  12. Examples and notes are informative, and do not use “normative”
-language.
    
-
    13. 
-

-
-
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.

-
-
The ModSpec defines a “requirement” of a standard as an atomic testable
-criterion. See the formal definition of requirement in Clause 4.21

-
-
A UML representation of important properties of this model is given in [annex-B-2].

-
6.3.  ModSpec document structure

-
-
Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are:

-
-
  • Core: contains all the core requirements and informational text that define the model and internal structure of a standard.
    
-
    • 
-
  • Part 1: UML Model requirements
    
-
    • 
-
  • Part 2: XML Model requirements
    
-
    • 
-
  • Part 3: Schematron requirements
    
-
    • 
-
  • Part 4: XML Metaschema requirements
    
-
    • 
-

-
-
Future Parts to the ModSpec Standard may include:

-
-
  • Part 5: RDF/OWL requirements
    
-
    • 
-

-
6.4.  Building Blocks

-
-
In software development technology, there is a concept called building block. In software development, building blocks are used to support the software build process where source code files/libraries can be accessed from multiple sources, converted into executable code, and linked together in the proper order until a complete set of executable files is generated. The same concept can be applied to OGC Standards development: Requirements classes and/or modules can be linked together from one or more standards to create a new standard not originally envisioned when the requirements were originally defined.

-
-
The Open Group suggests that building blocks have the following characteristics:

-
-
  1. A building block is a package of functionality defined to meet business or domain needs.
    
-
    2. 
-
  2. A building block may interoperate with other, inter-dependent, building blocks.
    
-
    3. 
-
  3. A good building block has the following characteristics:
    
-
    1. Considers implementation and usage, and evolves to exploit technology and standards.
      
-
      2. 
-
    2. May be assembled from other building blocks.
      
-
      3. 
-
    3. May be a subassembly of other building blocks.
      
-
      4. 
-
    4. Ideally a building block is re-usable and replaceable, and well specified.
      
-
      5. 
-
    
-
    4. 
-
  4. A building block may have multiple implementations but with different inter-dependent building blocks.
    
-
    5. 
-

-
-
These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work.
NOTE:    The approach modelled in the ModSpec has been referred to as the “core and extension model” due to its
-insistence on a modular structure throughout all parts of a standard and its implementation.

-
-
-
7.  Conventions
7.1.  Symbols (and abbreviated terms)

+ 
Note 1 to entry: Includes all statements in a document not part of the normative
+requirements (Clause 4.21), recommendations (Clause 4.20) or
+ conformance tests (Clause 4.3). Included for completeness.
[SOURCE: ISO/IEC DIR 2]

+
6.  Conventions
6.1.  Symbols (and abbreviated terms)

 
-
All symbols used in this document are either:

+
All symbols used in this document are either:

 
-
  1. Common mathematical symbols
    
+
    1. Common mathematical symbols
      
 
      2. 
-
    2. UML 2 (Unified Modeling Language) as defined by OMG and accepted as a publicly
+
    3. UML 2 (Unified Modeling Language) as defined by OMG and accepted as a publicly
 available standard (PAS) by ISO in its earlier 1.3 version.
      
 
      4. 
 
    
-
7.2.  Identifiers

+
6.2.  Identifiers

 
-
The normative provisions in this standard are denoted by the URI namespace

+
The normative provisions in this standard are denoted by the URI namespace

 
-
https://www.opengis.net/spec/modspec/1.1/

+
https://www.opengis.net/spec/modspec/1.1/

 
-
All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

+
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:

+
For the sake of brevity, the use of “req” in a requirement URI denotes:

 
-
https://www.opengis.net/spec/modspec/1.1/

+
https://www.opengis.net/spec/modspec/1.1/

 
-
An example might be:

+
An example might be:

 
-
/req/core/crs

+
/req/core/crs

 
-
All conformance tests that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

+
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:

+
For the sake of brevity, the use of “conf” in a requirement URI denotes:

 
-
https://www.opengis.net/spec/modspec/1.1/

+
https://www.opengis.net/spec/modspec/1.1/

 
-
The same convenstion is used for permissions (per) and recommendations (rec).

-
7.3.  Abbreviated terms

+
The same convention is used for permissions (per) and recommendations (rec).

+
6.3.  Abbreviated terms

 
-
In this document the following abbreviations and acronyms are used or introduced:

+
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”)

-
OCL
Object Constraint Language (part of UML)

-
OGC
Open Geospatial Consortium (http://www.opengeospatial.org/)

-
OMG
Object Management Group (http://www.omg.org/)

-
OOP
Object Oriented Programming

-
OOPL
OOP Language (such as C++ or Java)

-
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

+
ERA
Entity, Relation, Attribute (pre-object modeling technique)

+
ISO
International Organization for Standardization (from Greek for “same”)

+
OCL
Object Constraint Language (part of UML)

+
OGC
Open Geospatial Consortium (http://www.opengeospatial.org/)

+
OMG
Object Management Group (http://www.omg.org/)

+
OOP
Object Oriented Programming

+
OOPL
OOP Language (such as C++ or Java)

+
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

 

-
7.4.  Finding requirements and recommendations

+
6.4.  Finding requirements and recommendations

 
-
Each normative statement in the ModSpec is stated in one and only one place,
+
Each normative statement in the ModSpec is stated in one and only one place,
 in a standard format, with an 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 this document, all requirements are associated with tests specified in the test suite
 in Annex A. The reference to the requirement in the test case is done by a
 requirements label Recommendations are not tested although they still are documented using a standard template and have unique identifiers.

 
-
Requirements classes are separated into their own clauses and named, and specified
+
Requirements classes are separated into their own clauses and named, and specified
 according to inheritance (direct dependencies). The Conformance test classes in the
 test suite are similarly named to establish an explicit and link between
 requirements classes and conformance test classes.

-
8.  Fundamentals
8.1.  The ModSpec and the “Form” of a standard

-
-
NOTE:    For OGC Standards, the assumption is that documents are in a commonly used
-logical form (template).

-
-
This form should be specified by the following descriptions:

-
-
  1. A standards document contains Clauses (corresponding to numbered sections as they might
-appear in a table of contents) which describe its standardization target and its requirements.
    
-
    2. 
-
  2. A standard contains Annexes or is associated to other documents (both a
-logical type of Clause), one of which is the Conformance Test Suite (which may be an
-abstract description of the test suites to be implemented separately). In OGC Documents, this is Annex A – Abstract Test Suite.
    
-
    3. 
-
  3. All requirements, recommendations, permissions, and models are introduced and defined first in
-the numbered Clauses.
    
-
    4. 
-
  4. All requirements are identifiable as requirements.
    
-
    5. 
-
  5. All requirements in a document are uniquely numbered.
    
-
    6. 
-
  6. All tests for conformance to those requirements are defined in the Conformance Test Suite.
    
-
    7. 
-
  7. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.
    
-
    8. 
-
  8. The tests, if conducted, determine to some degree of certainty whether an
-implementation meets the requirements which the tests reference.
    
-
    9. 
-
  9. The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard
-does not do this, by default it has only one “conformance class”.
    
-
    10. 
-
  10. Certificates of conformance (see Clause 4.1) are
-awarded by a testing entity based on these conformance classes.
    
-
    11. 
-
  11. There is a clear distinction between normative and informative parts of the text.
    
-
    12. 
-
  12. Examples and notes are informative, and do not use “normative”
-language.
    
-
    13. 
-

-
-
In informative sections, the use of the word “will” implies that something is an implication of a requirement. The “will” statements are
-not requirements but explain the consequence of requirements.

-
-
The ModSpec defines a “requirement” of a standard as an atomic testable
-criterion. See the formal definition of requirement in Clause 4.21

-
-
A UML representation of important properties of this model is given in [annex-B-2].

-
8.2.  ModSpec document structure

-
-
Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are:

+
7.  Standards Fundamentals
7.1.  Building Blocks

 
-
  • Core: contains all the core requirements and informational text that define the model and internal structure of a standard.
    
-
    • 
-
  • Part 1: UML Model requirements
    
-
    • 
-
  • Part 2: XML Model requirements
    
-
    • 
-
  • Part 3: Schematron requirements
    
-
    • 
-
  • Part 4: XML Metaschema requirements
    
-
    • 
-

-
-
Future Parts to the ModSpec Standard may include:

-
-
  • Part 5: RDF/OWL requirements
    
-
    • 
-

-
8.3.  Building Blocks

+
In software development technology, there is a concept called building block. In software development, building blocks are used to support the software build process where source code files/libraries can be accessed from multiple sources, converted into executable code, and linked together in the proper order until a complete set of executable files is generated. The same concept can be applied to OGC Standards development: Requirements classes and/or modules can be linked together from one or more standards to create a new standard not originally envisioned when the requirements were originally defined.

 
-
In software development technology, there is a concept called building block. In software development, building blocks are used to support the software build process where source code files/libraries can be accessed from multiple sources, converted into executable code, and linked together in the proper order until a complete set of executable files is generated. The same concept can be applied to OGC Standards development: Requirements classes and/or modules can be linked together from one or more standards to create a new standard not originally envisioned when the requirements were originally defined.

+
The Open Group suggests that building blocks have the following characteristics:

 
-
The Open Group suggests that building blocks have the following characteristics:

-
-
  1. A building block is a package of functionality defined to meet business or domain needs.
    
+
    1. A building block is a package of functionality defined to meet business or domain needs.
      
 
      2. 
-
    2. A building block may interoperate with other, inter-dependent, building blocks.
      
+
    3. A building block may interoperate with other, inter-dependent, building blocks.
      
 
      4. 
-
    4. A good building block has the following characteristics:
      
-
      1. Considers implementation and usage and evolves to exploit technology and standards.
        
+
      2. A good building block has the following characteristics:
        
+
        1. Considers implementation and usage, and evolves to exploit technology and standards.
          
 
          2. 
-
        2. May be assembled from other building blocks.
          
+
        3. May be assembled from other building blocks.
          
 
          4. 
-
        4. May be a subassembly of other building blocks.
          
+
        5. May be a subassembly of other building blocks.
          
 
          6. 
-
        6. Ideally a building block is re-usable and replaceable, and well specified.
          
+
        7. Ideally a building block is re-usable and replaceable, and well specified.
          
 
          8. 
 
        
 
        3. 
-
      3. A building block may have multiple implementations but with different inter-dependent building blocks.
        
+
      4. A building block may have multiple implementations but with different inter-dependent building blocks.
        
 
        5. 
 
      
 
-
      These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work.
      NOTE:    The approach modelled in the ModSpec has been referred to as the “core and extension model” due to its
-insistence on a modular structure throughout all parts of a standard and its implementation.
-The modular approach is consistent with the definition and use of software building blocks.
      
-
+
      These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work.
      
+
7.2.  Standardization Context — Goals and Targets

 
-
8.4.  Standardization Context — Goals 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 OGC Standard document shall 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:

 
-
Instances of a Standardization Target Type are the Standardization Targets.  These are the real-world manifestations of the Standardization Target Type.  In summary:

-
-
  • Standardization Goal – identifies the problem and identifies the actors and entities involved in solving that problem
    
+
    • Standardization Goal – identifies the problem and identifies the actors and entities involved in solving that problem
      
 
      • 
-
    • Standardization Target Type – An abstract representation of one of the actors or entities identified in the Standardization Goal
      
+
    • Standardization Target Type – An abstract representation of one of the actors or entities identified in the Standardization Goal
      
 
      • 
-
    • Standardization Target – an implementation of a Standardization Target Type. These are the real-world entities which can be tested for conformance with the requirements documented in the Standard.
      
+
    • Standardization Target – an implementation of a Standardization Target Type. These are the real-world entities which can be tested for conformance with the requirements documented in the Standard.
      
 
      • 
 
    
 
-
    Standardization Target Types can be hierarchical.  The Conceptual, Logical, Physical hierarchy is one example where the Standardization Target Types are information models. Another example would be implementations of OGC API — Features Part 2 which support XML data exchange.
    
+
    Standardization Target Types can be hierarchical. The Conceptual, Logical, Physical hierarchy is one example where the Standardization Target Types are information models. Another example would be implementations of OGC API — Features Part 2 which support XML data exchange.
    
 
-
    Notice that the Standardization Targets and Standardization Target Types no longer form a simple taxonomy. 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.
    
-
8.5.  Conformance, Requirements, and key information

+
Notice that the Standardization Targets and Standardization Target Types no longer form a simple taxonomy. 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.

+
7.3.  Conformance, Requirements, and key information

 
-
In the conformance test suite, there will be a test defined to verify the validity of
+
In the conformance test suite, there will be a test defined to verify the validity of
 the claim that an implementation of the standard (standardization target) satisfies
 each mandatory requirement specified in the standard. Since the normative language of the body of the standard and the
 conformance test classes both define what conformance to the standard means, they
@@ -2235,7 +1987,7 @@ 
4.28. state
 a standards document to be well-written, at least in stating requirements and conformance
 tests.

 
-
Conformance tests are aggregated into conformance classes that specify how certain
+
Conformance tests are aggregated into conformance classes that specify how certain
 “certificates of conformance” are achieved. The natural inclination is to aggregate
 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,
@@ -2243,82 +1995,131 @@ 
4.28. state
 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
+
Therefore, the ModSpec defines a “requirements class” as a set of requirements that must
 all be passed to achieve a particular conformance class (see
-Clause 4.7). This document also includes a “middle” structure
+Clause 4.6). This document also includes a “middle” structure
 called a conformance test module. Requirements modules
 parallel the conformance test modules. A standard written to the ModSpec may
 use this “module” structure in any manner consistent with the rest of this Policy.

 
-
A standard may have mandatory and optional requirements classes.  This allows the options
+
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.
 Each requirement within an optional requirements class is mandatory when that requirements class is
 implemented. When needed, a particular requirements class may contain only a single
 requirement.

 
-
However, care must be taken, since the requirements classes may not always in a one-to-one
+
However, care must be taken, since the requirements classes may not always in a one-to-one
 correspondence to conformance classes in other standards which may be the source of
 requirements for a standard conformant to the ModSpec. If other standards are
 used, their options shall be specified to be useable within a standard conformant to
-this policy, see Clause 9.4.1.

+this policy, see Clause 8.4.1.

 
-
Conformance classes may contain dependencies on one another. These are represented by
+
Conformance classes may contain dependencies on one another. These are represented by
 tests in one conformance class that state that another conformance class must be
 passed to qualify to pass this conformance class. In terms of requirements, that says
 that the dependent conformance class contains tests (by reference) for all
 requirements of the “included” conformance class.

 
-
As defined in the ModSpec, one requirements
+
As defined in the ModSpec, one requirements
 class is dependent on another if the other is included through such a reference. In
 this manner, requirements classes can be treated as sets of requirements (each in a
 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 Table 1 above.

+
In the ModSpec, each conformance requirement is separated in its own labeled
+paragraph, such as req-1 below.

 
-
The distribution of the information in a standard is not restricted. The only
+
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 Table 13 and Table 14.

-
9.  Requirements Class: Core
The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the core of the ModSpec.
Table 1
REQ001/req/core/reqs-are-testable

+consistent with the conformance test classes, see Table 14 and Table 15.

+
7.4.  Documenting the Standard

+
+
NOTE:    OGC Standards are written using an OGC Member approved template that is conformant with the
+requirements stated in the ModSpec

+
+
This form should be specified by the following descriptions:

+
+
  1. A standards document contains Clauses (corresponding to numbered sections as they might
+appear in a table of contents) which describe its standardization target and its requirements.
    
+
    2. 
+
  2. A standard contains Annexes or is associated to other documents (both a
+logical type of Clause), one of which is the Conformance Test Suite (which may be an
+abstract description of the test suites to be implemented separately). In OGC Documents, this is Annex A – Abstract Test Suite.
    
+
    3. 
+
  3. All requirements, recommendations, permissions, and models are introduced and defined first in
+the numbered Clauses.
    
+
    4. 
+
  4. All requirements are identifiable as requirements.
    
+
    5. 
+
  5. All requirements in a document are uniquely numbered.
    
+
    6. 
+
  6. All tests for conformance to those requirements are defined in the Conformance Test Suite.
    
+
    7. 
+
  7. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.
    
+
    8. 
+
  8. The tests, if conducted, determine to some degree of certainty whether an
+implementation meets the requirements which the tests reference.
    
+
    9. 
+
  9. The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard
+does not do this, it is has by default only one “conformance class”.
    
+
    10. 
+
  10. Certificates of conformance (see [term-all-components-schema-document]) are
+awarded by a testing entity based on these conformance classes.
    
+
    11. 
+
  11. There is a clear distinction between normative and informative parts of the text.
    
+
    12. 
+
  12. Examples and notes are informative, and do not use “normative”
+language.
    
+
    13. 
+

+
+
In informative sections, the use of the word “will” implies that something is an implication of a requirement. The “will” statements are
+not requirements, but explain the consequence of requirements.

+
+
The ModSpec defines a “requirement” of a standard as an atomic testable
+criterion. See the formal definition of requirement in Clause 4.21

+
+
A UML representation of important properties of this model is given in [annex-B-2].

+
8.  ModSpec Requirements Class: Core
The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the core of the ModSpec.
NOTE:    The following requirement is for OGC work only and will be moved to the OGC Policy statement regarding the use of the ModSpec. This move will happen once the policy is removed.
Table 1
REQ000/req/core/ogc-compliance

+Any new OGC Standard, abstract specification that contains requirements, or major revision of an existing OGC Standard SHALL comply with the requirements stated in this document.
The following requirement states that every requirement is testable.
Table 2
REQ001/req/core/reqs-are-testable

 All the parts of a requirement, a requirements module, or requirements class SHALL be
 testable. Failure to pass any part of any requirement shall be a failure to pass the
-associated conformance test class.
NOTE:    This further means that failure to pass the test specified for a part of requirement is a
-failure to pass the requirement.
Table 2
REQ002/req/core/all-components-assigned-uri

+associated conformance test class.
NOTE:    This further means that failure to pass the test specified for a part of requirement is a
+failure to pass the requirement.
Table 3
REQ002/req/core/all-components-assigned-uri

 Each component of the standard, including requirements, requirements modules,
 requirements classes, conformance test cases, conformance modules and conformance
 classes SHALL be assigned a URI.
-For OGC standards documents, these URIs SHALL be conformant with the OGC Naming Authority policies.
NOTE:    In the OGC, the enforcement of this requirement and its associated recommendation is the purview of
-the OGC Naming Authority or its equivalents.
Table 3
REC001/req/core/uri-external-use

+For OGC standards documents, these URIs SHALL be conformant with the OGC Naming Authority policies.
NOTE:    In the OGC, the enforcement of this requirement and its associated recommendation is the purview of
+the OGC Naming Authority or its equivalents.
Table 4
REC001/req/core/uri-external-use

 These URI identities SHOULD be used in any external documentation that reference
 these component elements 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.
While a requirement may be referenced in more than one place in a standard, the normative definition of a requirement shall be its “home” (see Clause 7.4) and
-will be the only place where full normative language is used.
The following permissions relate to possible content specified in the core of a standard.
Table 4
PER001/per/core/informational-content-in-core

+conformance for implementations conformant to the standard in question.
While a requirement may be referenced in more than one place in a standard, the normative definition of a requirement shall be its “home” (see Clause 6.4) and
+will be the only place where full normative language is used.
The following permissions relate to possible content specified in the core of a standard.
Table 5
PER001/per/core/informational-content-in-core

 The informational and structural universals of the standard MAY be included in the
 core text and its associated models without violations of the ModSpec. This is
 true if the requirements of the extension are not implicit in what is
-included in the core.
In this manner, the core requirements class and its associated contents can be
+included in the core.
In this manner, the core requirements class and its associated contents can be
 thought of not only as the requirements of the core conformance class, but as a form
 of reference model for establishing core vocabularies and schemas for the entire
-standard.
Table 5
PER002/per/core/core-may-contain-schema-terms

+standard.
Table 6
PER002/per/core/core-may-contain-schema-terms

 The core MAY contain the definition and schema of commonly used terms and data
-structures for use in other structures throughout the standard.
Table 6
PER003/per/core/core-names-of-operations

+structures for use in other structures throughout the standard.
Table 7
PER003/per/core/core-names-of-operations

 This may include the list of the names of all operations and operation parameters
 to be used in any request-response pairs defined in any conformance class of the
 standard. If a service receives a request that is not supported in its
 conformance claim, then the service may return an error message text stating that the
-requested operation is part of a non-supported extension.
The following states how and where vocabularies are specified in relation to a requirement or requirements class.
Table 7
REQ003/req/core/vocabulary-and-parent-req-class

+requested operation is part of a non-supported extension.
The following states how and where vocabularies are specified in relation to a requirement or requirements class.
Table 8
REQ003/req/core/vocabulary-and-parent-req-class

 Requirements on the use and interpretation of vocabulary SHALL be in the
-requirements class where that use or interpretation is used.
Table 8
PER004/per/core/external-vocabs-core

-Importation of external vocabularies and schemas MAY be in the core.
Example
In the specification of a metadata service, the Dublin Core concept of a “Title” and
+requirements class where that use or interpretation is used.
Table 9
PER004/per/core/external-vocabs-core

+Importation of external vocabularies and schemas MAY be in the core.
Example
In the specification of a metadata service, the Dublin Core concept of a “Title” and
 the XML schema structure used for its specification can be in the core of the service
 specification. How a particular request-response pair uses the data structure to mean
 the title of a particular document or dataset will be specified in the requirements
 class in which the request-response pair is defined and set against requirements.

-
9.1.  Using the model

+
8.1.  Using the model

 
-
The primary difficulty in speaking about standards (or candidate
+
The primary difficulty in speaking about standards (or candidate
 standards)1 as a group is their diverse
 nature. Some standards use UML to define behavior, others use XML to define data
 structures, and others use no specific modeling language at all. However, they all
@@ -2328,7 +2129,7 @@ 
4.28. state
 model of an implementation of the standard (the standardization target). For
 completeness, they should also specify the conformance tests for these requirements
 that are to be run for validation of the implementations against those
-requirements.
NOTE:    This “test suite” specification is a requirement for
+requirements.
NOTE:    This “test suite” specification is a requirement for
 ISO and for OGC, but is often ignored in less formal standardization efforts. In such
 cases, if there exists a “validation authority” for conformance, they must interpret
 the requirements to be tested possibly separated from the authors of the
@@ -2336,7 +2137,7 @@ 
4.28. state
 
 
 
-
The assumption is that each standard has a single
+
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
@@ -2344,29 +2145,29 @@ 
4.28. state
 Clause 4.22). In this sense, the next requirement divides
 standard into parts more than restricting their content.

 
-
Table 9
REQ004/req/core/single-standardization-target

+
Table 10
REQ004/req/core/single-standardization-target

 Each requirement in a conformant standard SHALL have a single standardization
 target type.

 
-
In practice, the standardization target of the core requirements class is the root
+
In practice, the standardization target of the core requirements class is the root
 of an inheritance tree where extensions all have the core’s target as an ancestor,
 and thus can be considered as belonging to the same “class” or type as the core’s
 target.

 
-
Table 10
REQ005/req/core/modspec/test-class-single-standardization-target

+
Table 11
REQ005/req/core/modspec/test-class-single-standardization-target

 All conformance tests in a single conformance test class in a conformant
 standard SHALL have the same standardization target.

 
-
This means that all requirements are considered as targeting the same entity being
+
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
-Clause 4.11).

+Clause 4.10).

 
-
Table 11
PER005/per/core/repeated-requirements

+
Table 12
PER005/per/core/repeated-requirements

 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.

 
-
This second statement will be in a separate requirements class, since it will have a
+
This second statement will be in a separate requirements class, since it will have a
 separate standardization target and thus belong to the requirements to be tested by
 a separate conformance class. For example, in a service interface, a standard
 may be written that requires both the client and server to use a particular language
@@ -2374,10 +2175,10 @@ 
4.28. state
 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. The most
+
One solution is to state the requirement twice, once for each target. The most
 common alternative is to introduce a new “superclass”.

 
-
Table 12
PER006/per/core/abstract-superclass

+
Table 13
PER006/per/core/abstract-superclass

 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. This is
 diagrammed in Figure 1.

@@ -2389,109 +2190,109 @@ 
4.28. state
 
Example — Abstract Superclass

 
 

-
9.2.  The “standards” document

+
8.2.  The “standards” document

 
-
Each standard document is comprised of a set of requirements and their associated conformance tests.

+
Each standard document is comprised of a set of requirements and their associated conformance tests.

 
-
Table 13
REQ006/req/core/requirements-grouped

+
Table 14
REQ006/req/core/requirements-grouped

 Requirements SHALL be grouped together in clauses (numbered sections) of the
 document in a strictly hierarchical manner, consistent with
 requirements classes.

 
-
Table 14
REQ007/req/core/requirements-test-suite-structure

+
Table 15
REQ007/req/core/requirements-test-suite-structure

 The requirements structure of the document SHALL be in a logical correspondence to
 the test suite structure.

 
-
If two requirements are
+
If two requirements are
 in the same requirments class, they should be tested in the same conformance
 class in the conformance suite. Each requirement is separately identifiable
 either by a label as is done in the ModSpec.

 
-
In summary, the structure of the requirements and requirements classes of the model
+
In summary, the structure of the requirements and requirements classes of the model
 should be reflected in the organization of the conformance tests and classes, and
 also in the structure of the normative clauses in the specification document.

-
9.3.  Conformance Test Suite

+
8.3.  Conformance Test Suite

 
-
The requirements specified in this clause will be applied directly to the test suite, and in particular
+
The requirements specified in this clause will be applied directly to the test suite, and in particular
 to the conformance classes. By definition, a “test suite” is a collection of
 identifiable conformance classes. A conformance class is a well-defined set of
 conformance tests. Each conformance test is a concrete or abstract (depending on the
 type of suite) description of a test to be performed on each candidate conformant
 implementation, to determine if it meets a well-defined set of requirements as
-stated in the normative clauses of the standards document.
NOTE:    The Test Suite is normative in the sense that it describes the tests to be
+stated in the normative clauses of the standards document.
NOTE:    The Test Suite is normative in the sense that it describes the tests to be
 performed to pass conformance, but it specifies no requirements in any other sense.
 The requirements are specified in the body of the standard. The test suite
 only describes in detail how those requirements should be tested.

 
 
 
-
In each of the profiles defined in the Clauses to follow, some set of entities,
+
In each of the profiles defined in the Clauses to follow, some set of entities,
 types, elements, or objects are defined and segregated into implementation
 requirements classes.

 
-
Table 15
REQ008/req/core/requirements-class-correspondence-to-conformance-classes

+
Table 16
REQ008/req/core/requirements-class-correspondence-to-conformance-classes

 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.

 
-
Strict parallelism of implementation and governance is the essence of this standard.

-
9.4.  Requirements for Modularity

+
Strict parallelism of implementation and governance is the essence of this standard.

+
8.4.  Requirements for Modularity

 
-
9.4.1.  Each Conformance class tests a complete requirements class

+
8.4.1.  Each Conformance class tests a complete requirements class

 
-
Table 16
REQ009/req/core/no-optional-tests

+
Table 17
REQ009/req/core/no-optional-tests

 A Conformance class SHALL not contain any optional conformance tests.

 
-
This requirement stops
+
This requirement stops
 conformance classes from containing optional requirements and tests, and, at least
 as far as the standard is concerned, makes all certificates of conformance mean
 that exactly the same tests have been conducted. Standards documents may use
 recommendations for such options, but the conformance test classes do not test
 recommendations.

 
-
Table 17
PER007/per/core/conf-class-paramterized

+
Table 18
PER007/per/core/conf-class-paramterized

 A Conformance class may be parameterized.

 
-
This means that the class’s tests
+
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.

 
-
For example, if a conformance class needs to apply tests against a specific data format, such as GML or
+
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.
 Because the parameters choose which requirements will be tested, two conformance
 classes with distinct parameters should be considered as distinct conformance
 classes.

 
-
The most common parameters are the identities of indirect dependencies. For example,
+
The most common parameters are the identities of indirect dependencies. For example,
 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.

 
-
Table 18
REQ010/req/core/all-parameters-expressed

+
Table 19
REQ010/req/core/all-parameters-expressed

 A certificate of conformance SHALL specify all parameter values used to pass the
 tests in its conformance test class.

 
-
Conformance to a particular conformance class means exactly the same thing everywhere.

+
Conformance to a particular conformance class means exactly the same thing everywhere.

 
-
Table 19
REQ011/req/core/conf-class-single-req-class

+
Table 20
REQ011/req/core/conf-class-single-req-class

 A Conformance class SHALL explicitly test only requirements from a single
 requirements class.

 
-
This means that there is a strict correspondence between the requirements classes
+
This means that there is a strict correspondence between the requirements classes
 and the conformance test classes in the test suite. Recall that a conformance test
 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.

 
-
Table 20
REQ012/req/core/con-class-dependencies

+
Table 21
REQ012/req/core/con-class-dependencies

 A Conformance class SHALL specify any other conformance class upon which it is
 dependent and that other conformance class shall be used to test the specified
 dependency.

 
-
Such referenced conformance classes may be in the same standard or may be a
+
Such referenced conformance classes may be in the same standard or may be a
 conformance class of another standard.

 
 
Example — Indirect dependency on schema

 
-
If a service specifies that a particular output is required to be conformant to a
+
If a service specifies that a particular output is required to be conformant to a
 conformance test class in a specific standard (say a normatively referenced XML
 schema), then the conformance class of that normative reference will be used to test
 that output. For example, if an OGC Web Feature Service (WFS) implementation instance specifies that its feature collection output is
@@ -2500,82 +2301,81 @@ 
4.28. state
 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
+
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 listing of which options within a class were tested. If a
-standard’s authors wish to make a particular requirement optional, Table 16
+standard’s authors wish to make a particular requirement optional, Table 17
 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
+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.

 
 
 
-
Table 21
REQ013/req/core/imported-requirements-class
AIf a requirements class is imported from another standard for use within a
+
Table 22
REQ013/req/core/imported-requirements-class
AIf 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.
BEach 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.#

 
-
The tracking of the parallelism between requirements and tests should be easy if the
+
The tracking of the parallelism between requirements and tests should be easy if the
 standards document is non-ambiguous. To insure this, by utilizing the names of the two types of classes the following requirement places a
 default mapping between the two.

 
-
Table 22
REQ014/req/core/all-classes-explicitly-named

+
Table 23
REQ014/req/core/all-classes-explicitly-named

 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.

 
-
Logically, a requirements class (set of requirements) and a conformance class (set
+
Logically, a requirements class (set of requirements) and a conformance class (set
 of tests) are not comparable. This can be remedied by noting that both have a
 consistent relation to a set of requirements. A requirements class is a set of
 requirements. A conformance class tests a set of requirements. Therefore a requirements class corresponds precisely to a conformance class if they
 both are related (as described) to the same set of requirements.

 
+
8.5.  Requirements classes contain all requirements tested by a conformance test case

 
-
9.4.2.  Requirements classes contain all requirements tested by a conformance test case

-
-
Table 23
REQ015/req/core/req-in-only-one-rec-class
AEach requirement in the standard SHALL be contained in one and only one
+
Table 24
REQ015/req/core/req-in-only-one-rec-class
AEach requirement in the standard SHALL be contained in one and only one
 requirements class.
BInclusion of any requirement in a requirements class by a
 conformance class _SHALL imply inclusion of all requirements in its class (as a
 dependency).

 
-
Unless a requirement is referenced in a conformance test and thus in a conformance
+
Unless a requirement is referenced in a conformance test and thus in a conformance
 class, it cannot be considered a requirement since no test has been defined for it.

 
-
Table 24
REC002/rec/core/parallel-structure

+
Table 25
REC002/rec/core/parallel-structure

 If possible, the structure of the normative clauses of the standard SHOULD
 parallel the structure of the conformance classes in the conformance clause.

 
-
The above requirement in conjunction with Table 16 means that all requirements in a conformant
+
The above requirement in conjunction with Table 17 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.

 
-
Table 25
REQ016/req/core/co-dependent-requirements
AIf any two requirements are co-dependent (each
+
Table 26
REQ016/req/core/co-dependent-requirements
AIf any two requirements are co-dependent (each
 dependent on the other) then they shall be in the same requirements class.
BIf any
 two requirements classes are co-dependent, they shall be merged into a single class.

 
-
Normally, circular dependencies between implementation components are signs of a
+
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).

 
-
Table 26
REC003/rec/core/circular-dependencies

+
Table 27
REC003/rec/core/circular-dependencies

 Circular dependencies of all types should be avoided whenever possible.

 
-
Table 27
REQ017/req/core/structure-requirements-classes

+
Table 28
REQ017/req/core/structure-requirements-classes

 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.
NOTE:    The only certain manner to test this requirement maybe to create a reference
+extensions.
NOTE:    The only certain manner to test this requirement maybe to create a reference
 implementation.

 
 
 
-
This requirement is more important and may be more difficult than it seems. It
+
This requirement is more important and may be more difficult than it seems. It
 states simply that conformance classes and their associated requirements classes can
 be put in a one-to-one correspondence to a fully modular implementation of the
 complete standard (at least against a single
@@ -2584,105 +2384,99 @@ 
4.28. state
 the software requirements classes are properly separated, they can be implemented in
 a “plug’n’play” fashion.

 
-
Table 28
REQ018/req/core/requirements-and-dependencies

+
Table 29
REQ018/req/core/requirements-and-dependencies

 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.#

 
-
This means, for example, that a UML classifier cannot be redefined in a new
+
This means, for example, that a UML classifier cannot be redefined in a new
 extension. If a new version of the classifier is needed it has to be a valid subtype
 of the original.

 
-
In terms of generalization, subclassing, extension and restriction (into a new class
+
In terms of generalization, subclassing, extension and restriction (into a new class
 or type) are all acceptable, redefinition (of an old class or type) is not.

 
-
Clause 9.2 makes some pointed suggestion as to how to organize the conformance
+
Clause 8.2 makes some pointed suggestion as to how to organize the conformance
 classes and normative clauses in parallel to make this requirement easier to verify.

 
-
Most standards include examples, which are useful for illustrative or pedagogical
+
Most standards include examples, which are useful for illustrative or pedagogical
 purposes. However, it is not possible to write a standard “by example” that
 leads to conformance tests. Examples are therefore non-normative, by definition.

-
+
8.6.  Profiles are defined as sets of conformance classes

 
-
9.4.3.  Profiles are defined as sets of conformance classes

-
-
All the conformance classes created in a standard form a base (an upper bound
+
All the conformance classes created in a standard form a base (an upper bound
 of all conformance classes) for defining profiles as defined in ISO/IEC 10000 (see
 ISO/IEC DIR 2). The base for creating a profile can be defined as the union of all
 requirements classes.

 
-
Table 29
REQ019/req/core/profile-conformance

+
Table 30
REQ019/req/core/profile-conformance

 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.

-
+
8.7.  There is a Defined Core

 
-
9.4.4.  There is a Defined Core

-
-
Table 30
REQ020/req/core/core-requirements-separate

+
Table 31
REQ020/req/core/core-requirements-separate

 Every standard SHALL define and identify a core set of requirements as a
 separate conformance class.

 
-
Table 31
REQ021/req/core/requirements-and-dependencies

+
Table 32
REQ021/req/core/requirements-and-dependencies

 All general recommendations SHALL be in the core.

 
-
Table 32
REQ022/req/core/requirements-and-dependencies
AEvery other requirements class in a standard SHALL a standardization
+
Table 33
REQ022/req/core/requirements-and-dependencies
AEvery other requirements class in a standard SHALL a standardization
 target type which is a subtype of that of the core
BAnd every requirement class SHALL have the core as a direct dependency.

 
-
Table 33
REC004/rec/core/simple-core

+
Table 34
REC004/rec/core/simple-core

 The core SHOULD be as simple as possible.

 
-
Table 34
PER008/per/core/core-type

+
Table 35
PER008/per/core/core-type

 The core MAY be partially or totally abstract.

 
-
Table 35
PER009/per/core/req-class-another-standard

+
Table 36
PER009/per/core/req-class-another-standard

 The core requirements class MAY be a conformance class in another standard.

 
-
Table 36
REC005/rec/core/optional-tests

+
Table 37
REC005/rec/core/optional-tests

 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 Table 21.

+in that conformance class that are required by the current standard’s core requirements class. See Table 22.

 
-
Since the core requirements class is contained (as a direct dependency) in each
+
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.

 
-
Table 37
PER010/per/core/core-maybe-recommendations

+
Table 38
PER010/per/core/core-maybe-recommendations

 Since the basic concept of some standards is mechanism not implementation, the core MAY contain only
-recommendations, and include no requirements.
NOTE:    In most cases, if someone feels the need to define a “simple” version of the
+recommendations, and include no requirements.
NOTE:    In most cases, if someone feels the need to define a “simple” version of the
 standard, it is probably a good approximation of the best core. For example, the
 core of a refactored GML might be the equivalent of the “GML for Simple Features”
 profile. The core for any SQL version of feature geometry is probably “Simple
 Features.”

 
 
-
-
-
9.4.5.  Extensions are requirements classes

+
8.8.  Extensions are requirements classes

 
-
A common mechanism to extend the functionality of a standard is to define
+
A common mechanism to extend the functionality of a standard is to define
 extensions, which may be either local or encompass other standards.

 
-
Standards should use extensions as required and feasible, but should never hinder them.

+
Standards should use extensions as required and feasible, but should never hinder them.

 
-
Table 38
REQ023/req/core/core-and-extensions

+
Table 39
REQ023/req/core/core-and-extensions

 Each standard conformant to the ModSpec SHALL consist of the core and some
 number of requirements classes defined as extensions to that core.

 
-
Table 39
REQ024/req/core/extensions-conformant-to-the-modspec

+
Table 40
REQ024/req/core/extensions-conformant-to-the-modspec

 A standard conformant to the ModSpec SHALL require all conformant extensions
 to itself to be conformant to the ModSpec.

 
-
Since software is evolutionary at its best, it would not be wise to restrict that
+
Since software is evolutionary at its best, it would not be wise to restrict that
 evolutionary tendency by restricting the specification of extensions. A
 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.

 
-
Table 40
REQ025/req/core/restriction-of-extensions

+
Table 41
REQ025/req/core/restriction-of-extensions

 A standard conformant to the ModSpec SHALL never restrict in any manner
 future, logically valid extensions of its standardization targets.

 
-
The above requirement should not be interpreted as a restriction on quality
+
The above requirement should not be interpreted as a restriction on quality
 control. Any efforts by a standard to enforce a level of quality on its
 standardization targets, when well and properly formed, do not interfere with the
 proper extension of those targets. So, the standard may require its
@@ -2693,12 +2487,10 @@ 
4.28. state
 require a standardization target to not accept an alternative, such as KML, or
 GeoJSON, as long at that alternative can carry viable information consistent with
 the fundamental intent of the standard.

-
+
8.9.  Optional requirements are organized as requirements classes

 
-
9.4.6.  Optional requirements are organized as requirements classes

-
-
Table 41
REQ026/req/core/optional requirements

-The only conditional requirements acceptable in a standard conformant with the ModSpec SHALL be expressible as a list of conformance classes to be passed.
NOTE:    Standards and implementations are restricted by this, but not instances of
+
Table 42
REQ026/req/core/optional requirements

+The only conditional requirements acceptable in a standard conformant with the ModSpec SHALL be expressible as a list of conformance classes to be passed.
NOTE:    Standards and implementations are restricted by this, but not instances of
 schemas. For example, a XML schema standard can specify an optional element, which
 data instances may use or not. However schema-aware processors claiming conformance
 to the standard should be able to handle all elements defined in the schema, whether
@@ -2706,1250 +2498,510 @@ 
4.28. state
 
 
 
-
Requirements of the form “if the implementation does this, it must do it this way” are considered to be options and should be in a separate requirements class.

-

-
-
9.4.7.  Requirements classes intersect overlap only by reference

+
Requirements of the form “if the implementation does this, it must do it this way” are considered to be options and should be in a separate requirements class.

+
8.10.  Requirements classes intersect overlap only by reference

 
-
Table 42
REQ027/req/core/req-class-overlap-by-reference

+
Table 43
REQ027/req/core/req-class-overlap-by-reference

 The common portion of any two requirements classes SHALL consist only of references
 to other requirements classes.

 
-
This implies that each requirement is directly in exactly one requirements class and
+
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 conformance test cases which require the execution of the
-dependency conformance class. See for example Annex A.2.1.
NOTE:    All general recommendations are in the core requirements class. The core
+dependency conformance class. See for example [annex-A-2-1].
NOTE:    All general recommendations are in the core requirements class. The core
 conformance test class contains tests that all other conformance classes must pass.

 
 
-

-
10.  Mapping this standard to types of models
10.1.  Semantics

+
9.  Mapping this standard to types of models
9.1.  Semantics

 
-
The previous section defines requirements for conformance to the ModSpec, but
+
The previous section defines requirements for conformance to the ModSpec Hpwever,
 testing for that conformance may depend on how the various forms and parts of a
-conformant standard are viewed. This clause specifies how those views
-are to be defined in most of the common cases. Standards that take an alternative
-mechanism to the ones listed here must be tested solely on the structure of their
-conformance test suite, until an extension to ModSpec is defined for that
+conformant standard are viewed. Additional Parts to the ModSpec Standard specify how those views
+are to be defined. Standards that take an alternative
+mechanism to the ones defined in the additional Parts must be tested solely on the structure of their
+conformance test suite until such times as an extension to the ModSpec is defined for that
 alternate mechanism.

 
-
Standards are often structured about some form of modeling language, or
-implementation paradigm. This clause looks at some common types of models and
-defines a mechanism to map parts of the model (language, schema, etc.) to the
-conformance classes used as the model from [cls-6-1].

+
Standards are often structured about 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 used as the model from cls-6-1.

 
-
As suggested in Clause Table 32, the structure of the normative clauses in a
+
As suggested in Clause Table 33, 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.

-
10.2.  Data Models

+
9.2.  A Note on Data Models

 
-
10.2.1.  Common modeling issues

+
If a data model is to be used to define the parameters of operational interfaces,
+then that model should belong in the core since it can be considered as part of a
+common reference model and vocabulary.

 
-
If a data model is to be used to define the parameters of operational interfaces, then that model should belong in the core since it can be considered as part of a common reference model and vocabulary.

-
-
If a data model is to be used to create “data transfer” elements, the issue is more
+
If a data model is to be used to create “data transfer” elements, the issue is more
 complex. In the use of parameter names and types in the operational model above, the
 definition of a common vocabulary in the core is justifiable. In the case where data
 transfer elements are being defined, it may be that some types and elements are a
 defining separator between conformance classes and have to exist independently of
-such data elements defined for non-dependent classes. For these reasons, care should be taken in creating separable data transfer schemas across requirements.
+such data elements defined for non-dependent classes. For these reasons, care
+should be taken in creating separable data transfer schemas across requirements.
 Dependencies in the schemas will have to parallel the dependencies in the
 requirements classes. The mechanism for enforcing this is dependent on the schema
 language.

-

-
-
10.2.2.  Optional Requirements class: UML model extension to the core

-
-
If the organizing mechanism for the data model used in the standard is an object model, then the
-mapping from parts of the model to the requirements classes should follow the
-logical mechanism described here.

-
-
The terminology used here is common to all versions of the UML standard, and may
-be applied to any such version.

-
-
First, by the requirements above, the extension relationship of this conformance
-test class to the core will be made explicit.

-
-
Table 43
Requirements Class — UML extension to the core
/req/core/data-representation
TargetModSpec Conformant UML Model
DependencyOGC ModSpec Version 2 (need proper title and document number)
REQ028/req/core/uml/conformance-with-core
REQ029/req/core/uml/object-model
REQ030/req/core/uml/dependency-graph
REQ031/req/core/uml/leaf-package
REQ032/req/core/uml/class-package
REQ033/req/core/uml/to-leaf
REQ034/req/core/uml/common-req-classes
REQ035/req/core/uml/source-target
REQ036/req/core/uml/leaf-package-dependency
REQ037/req/core/uml/two-way-dependency
REQ038/req/core/uml/segregate-into-leaf-packages

-
-
Any conformant UML extension shall comply with the ModSpec Core requirements class.

-
-
Table 44
REQ028/req/core/uml/conformance-with-core

-An implementation passing the UML conformance test class SHALL first pass the core
-conformance test class

-
-
Assuming all legitimate direct package dependencies are included in the UML model,
-the conformance/requirements class associated to a package 
-  
-    A
-  
- will directly
-reference the conformance/requirements class associated to another package 
-  
-    B
-  
-,
-if and only if 
-  
-    A
-  
- is dependent on 
-  
-    B
-  
-. Indirect dependencies will be
-dealt with as the conformance classes cascade.

-
-
This clause uses UML terminology, but other object modeling languages and, if
-needed, the object code itself can be mapped to a UML model.

-
-
Table 45
REQ029/req/core/uml/object-model

-To be conformant to this UML requirements class, UML SHALL be used to express the
-object model, either as the core mechanism of the standard or as a normative adjunct
-to formally explain the standard in a model

-
-
Table 46
REQ030/req/core/uml/dependency-graph

-A UML model SHALL have an explicit dependency graph for the leaf packages and
-external packages used by the standard consistent with the way their classifiers use
-those of other packages
NOTE:    External packages having predated the current version of the standard will
-not normally have dependencies to packages within the standard.

-
-
-
-
Other dependencies (indirect) will arise from the transitive closure of the above
-direct dependencies. That means if 
-  
-    A
-  
- depends on 
-  
-    B
-  
-, and 
-  
-    B
-  
-
-depends on 
-  
-    C
-  
- then 
-  
-    A
-  
- depends on 
-  
-    C
-  
-. Since these indirect
-dependencies will show up in the cascade of included conformance tests based solely
-on the direct dependencies, we can ignore them for effects on structure.

-
-
Since a package can consist solely of other packages, there is always the capability
-to define in UML a single package that will correspond to a particular requirements
-class and its associated conformance class.

-
-
Table 47
REQ031/req/core/uml/leaf-model

-A UML leaf package SHALL be associated directly to only one requirements class.

-
-
Table 48
REQ032/req/core/uml/class-package

-Each requirements class shall be associated to a unique package in the model and
-include either directly or by a dependency any requirement associated to any of its
-subpackages.

-
-
The class definitions are the “requirements” of a UML expressed standard. Therefore the
-logical consequence of the above is to organize requirements classes based on leaf
-packages.

-
-
Table 49
REQ033/req/core/uml/to-leaf

-A requirements class SHALL be associated to some number of complete leaf packages
-and all classes and constraints in those packages.

-
-
If a requirement uses or refers to elements of more than one package, then one of
-the packages will be called the source of the requirement, and the other targets.
-The requirement with the same source package will always be associated to same
-requirements module and/or class.

-
-
Table 50
REQ034/req/core/uml/common-req-classe

-Classes that are common to all requirements classes SHALL be in a package
-associated to the core requirements class.

-
-
This is actually a derived requirement and is repeated here for emphasis.

-
-
This dependency of requirements classes will be consistent with the usual mechanism
-for describing the source and target of dependencies between packages. By Clause
-Table 32, only classes in the source requirements class will be affected by the
-requirement.

-
-
In UML, source and target dependency relations are defined in such a way that the
-source of the relation is dependent on the target of the relation.

-
-
Table 51
REQ035/req/core/uml/source-target
AIn the UML model, if a “source” package is dependent on a “target” package then
-their requirements class SHALL be equal or
BThe source package’s class SHALL be an extension of the target package’s class.

-
-
This means that the dependency graph of the UML packages parallels in some sense the
-extension diagram of the requirements/conformance classes. If all leaf
-packages of the model are moved into “requirements class packages” containing their
-corresponding modeling packages the model then satisfies the following
-recommendation:

-
-
Each requirements class in a conformant standard should be associated to one and only one UML package (which may contain sub-packages for a finer level of structure). If the core requirements class contains only recommendations, it may be an exception to this.

-
-
Requirement 1
Statement

-  If one leaf package is dependent on another leaf package, then the requirements class of the first SHALL be the same or an extension of the requirements class of the second.
-

-
-
Requirement 2
Statement

-  If two packages have a two-way dependency (a “co-dependency”), they SHALL be associated to the same requirements class.
-

+

Annex A
(normative)
Abstract Conformance Test Suite
A.1.  Conformance Test Class: The Core

 
-
For example, if two classes have a two-way navigable association, then these two
-classes must be (transitively) in the same conformance requirements class package.

-
-
The hierarchical structure of a UML model is based on UML classes, residing in UML
-packages. UML packages can then reside in larger UML packages. Although there is
-nothing to demand it, it is a common practice to move all classes down the hierarchy
-to leaf packages. Leaf packages are those that contain only classes (that is,
-contain no smaller subpackages). Classes can act as packages in the sense that a UML
-class can contain a locally defined class whose scope is the class itself. For our
-purposes, we will consider a class and its contained local classes to all be in the
-package of the original class.

+
A.1.1.  Requirements are atomic and tests cover all the parts of each of the requirement

 
-
Requirement 3
Statement

-  The UML model SHALL segregate all classes into leaf packages.
-

-

+
All the parts of a requirement, a requirement module, or requirements class shall be
+tested. Failure to meet any part of any requirement shall be a failure to pass the
+associated conformance test class.

 
-
10.2.3.  Requirements class: The XML schema extension to the core

-
-
This requirements class covers 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.

-
-
First, by the requirements above, the extension relationship of this conformance
-test class to the core must be made explicit.

-
-
Requirement 4
Statement

-  An implementation passing the XML schema conformance test class shall first pass the ModSpec core conformance test class.
-

-
-
Requirement 5
Statement

-  An implementation passing the XML schema conformance test class shall first pass the W3C Recommendation for XML schema.
-

-
-
Each XML schema file (usually *.xsd) carries a target namespace specification, recorded in the
-targetNamespace attribute of the <schema> element in the XML representation. In
-its implementation, this namespace is represented by a globally unique identifier, a
-URI. All schema components defined with that URI as its namespace designation are
-part of the same module in XML schema.

-
-
The XML Schema specification lists those resolution strategies for namespace and
-schema that a schema-aware process may use. They work in a predictable fashion
-independent of the choice of strategy if and only if the schemas are in a one to one
-correspondence to their namespace. A schema may be dependent on another schema and
-may contain “import” directives that load all such schemas whenever it is loaded.

-
-
When a process loads a schema as defined by its namespace URI
-identity, it must always get a linkage to all components in that namespace. If not,
-then at sometime in the future, the process will fail when it finds a reference to
-such a component that it missed. To prevent this sort of failure, when a
-schema-aware process first encounters a namespace URI it must always be associated
-to a schema location (a file) that contains or includes all schema components having
-the URI as their namespace. This is referred to as the “all-components schema
-document”.

-
-
In defining a XML schema (either completely, or partially in a standard) the
-fundamental component or module of XML schema is always the namespace and its
-associated schema; which is designated by a URI.

-
-
Requirement 6
Statement

-  If a standard conformant to the XML schema conformance class defines a set of data schemas, all components (e.g. elements, attributes, types …​) associated with a single conformance test class shall be scoped to a single XML namespace.
-

-
-
Requirement 7
Statement

-  The all-components schema document for an XML Schema shall indicate the URI of the associated conformance test class in the schema/annotation/appinfo element.
-

-
-
The mechanism for dependencies may either be by importation or by inclusion of
-schema components.

-
-
Example
In GML 3, the spatial schema (ISO 19107) and the general feature model (ISO 19109)
-are both satisfied by elements within the single GML namespace. A viable alternative
-would to have put the schema components for spatial schema and feature schema in
-separate namespaces.

+
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    2. 
+
  2. Test Method: Inspect the document to verify the above.
    
+
    3. 
+
  3. Reference: Table 2
    
+
    4. 
+
  4. Test Type: Conformance.
    
+
    5. 
+

 

 
-
This is a choice of design, and at the level of the ModSpec, the trade-off factors
-cannot be prejudged because the details of such cost-benefit trade-offs are not
-constant. Either of the above approaches may be used.

-
-
Requirement 8
Statement

-  If a standard conformant to the XML schema conformance class defines a direct dependency from one requirement class to another, then a standardization target of the corresponding conformance test class shall import a schema that has passed the associated conformance test class (dependency) or shall itself pass the associated conformance test class.
-

-
-
NOTE  1:    This implies that the value of the schemaLocation on the <import> element
-will refer to the all-components schema document.

-
-
An all-components schema document may be assembled by inclusion of documents that describe subsets of the components associated with the conformance test class.
-This allows schema designers to do some modularization within a namespace for
-convenience, notwithstanding the requirement for an all-components schema document.
NOTE  2:    A namespace variable is used if the requirements class is not defining a
-schema, but defining requirements for a schema to be the target of its conformance
-class. For example, GML defines requirements for application schemas, but does not a
-priori know the namespace of any application schema. The namespace for the
-application schema becomes a variable in the conformance test cases.

+
A.1.2.  All components have an assigned URI

 
+
Each component of the standard, including requirements, requirements modules,
+requirements classes, conformance test cases, conformance modules and conformance
+classes shall be assigned a URI as specified by the OGC Naming Authority or its
+equivalent.

 
+
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    2. 
+
  2. Test Method: Inspect the document to verify the above.
    
+
    3. 
+
  3. Reference: Table 3
    
+
    4. 
+
  4. Test Type: Conformance.
    
+
    5. 
+

+

 
-
Requirement 9
Statement

-  No requirements class in a specification conformant to the XML schema conformance class shall modify elements, types or any other requirement from a namespace to which it is not associated.
-

+
A.1.3.  Requirements on vocabulary are appropriately placed

 
-
Requirements may add constraints. This allows extensions to restrict:

+
Requirements on the use and interpretation of vocabulary shall be in the
+requirements class where that use or interpretation is used.

 
-
  1. Usage of existing elements, but only if their use was originally optional. This is
-similar to the rules for inheritance (such as in UML or other object models), where
-a class can eliminate an attribute from a superclass only if the superclass
-attribute includes a “0” in its multiplicity range.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
+
      2. 
+
    2. Test Method: Inspect the document to verify the above.
      
 
      3. 
-
    3. The type of existing elements, to sub-types of the original elements. This is
-similar to the rules for inheritance, where a class can re-define an attribute or
-association role from a superclass so that its type or class is a specialization of
-the original.
      
+
    4. Reference: Table 8
      
+
      5. 
+
    5. Test Type: Conformance.
      
 
      6. 
 
    
-
-
    In summary, effective modularization is enabled by following the pattern of one
-conformance class per XML namespace; i.e. the set of components in an XML namespace
-should be referred to as a whole. Subsetting of components in a single XML namespace
-for conformance purposes is not permitted.
    
 

 
-
10.2.4.  Optional Requirements class: Schematron extension to the ModSpec Core

-
-
Schematron (ISO/IEC 19757-3:2006) provides a notation with which many constraints on XML
-documents can be expressed. This requirements class covers any standard that
-uses Schematron to create patterns or constrains for an XML Schema. First the schema
-must be defined within the bounds of the XML schema requirements class.

-
-
Requirement 10
Statement

-  A standard passing the Schematron conformance test class shall also define or reference an XML schema that shall pass the XML schema conformance class from this standard.
-

+
A.1.4.  Requirements have a single target

 
-
Within a Schematron schema, the “pattern” and “schema” elements may be used in a way
-that corresponds with conformance tests and a conformance test class as follows:

+
Each requirement in a conformant standard shall have a single standardization
+target type.

 
-
Requirement 11
Statement

-  Each sch:pattern element shall implement constraints described in no more than one requirement. Each requirement shall be implemented by no more than one sch:pattern.
-

-
-
Requirement 12
Statement

-  Each sch:pattern element shall be contained within one sch:schema element.
-

-
-
Requirement 13
Statement

-  The value of the sch:schema/@fpi attribute shall be a URI that identifies this implementation
-

-
-
Requirement 14
Statement

-  The value of the sch:schema/@see attribute shall be the identifier for the requirements class that contains the requirement(s) implemented by the schema
-

-
-
Requirement 15
Statement

-  The value of the sch:schema/@fpi attribute shall be used on only one Schematron schema.
-

-

-
-
10.2.5.  Optional Requirements class: XML meta-schema extension tothe ModSpec Core

-
-
This requirements class covers any standard which has as one of its purposes
-the introduction of a new type of XML schema. Such a standard would normally
-define the characteristics of such schema, how its components are created and its
-intended uses.

-
-
First, by the requirements above, the extension relationship of this conformance
-test class to the core must be made explicit.

-
-
Requirement 16
Statement

-  A standard passing the XML meta-schema conformance test class shall first pass the core specification conformance test class.
-

-
-
Since the target specification will be defining requirements for XML schemas, it
-will require that the ModSpec be used.

-
-
Requirement 17
Statement

-  A standard passing the XML meta-schema conformance test class shall require that its specification targets (XML schema) pass the XML schema conformance class from the ModSpec.
-

-

-

Annex A
(normative)
Abstract Conformance Test Suite
A.1.  Conformance Test Class: The Core

-
-
A.1.1.  Requirements are atomic and tests cover all the parts of each of the requirement

-
-
All the parts of a requirement, a requirement module, or requirements class shall be
-tested. Failure to meet any part of any requirement shall be a failure to pass the
-associated conformance test class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 1
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.1.2.  All components have an assigned URI

-
-
Each component of the standard, including requirements, requirements modules,
-requirements classes, conformance test cases, conformance modules and conformance
-classes shall be assigned a URI as specified by the OGC Naming Authority or its
-equivalent.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 2
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.1.3.  Requirements on vocabulary are appropriately placed

-
-
Requirements on the use and interpretation of vocabulary shall be in the
-requirements class where that use or interpretation is used.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 7
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.1.4.  Requirements have a single target

-
-
Each requirement in a conformant standard shall have a single standardization
-target type.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 9
      
+
    5. Reference: Table 10
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.5.  Conformance test classes have a single target

 
-
All conformance tests in a single conformance test class in a conformant
+
All conformance tests in a single conformance test class in a conformant
 standard shall have the same standardization target.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 10
      
+
    5. Reference: Table 11
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.6.  Requirements are organized by clauses

 
-
The requirements shall be grouped together in clauses (numbered sections) of the
+
The requirements shall be grouped together in clauses (numbered sections) of the
 document in a strictly hierarchical manner, consistent with requirements modules and
 requirements classes.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Clause 9.2, Table 13
      
+
    5. Reference: Clause 8.2, Table 14
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.7.  Conformance test classes are consistent with requirements classes

 
-
The requirements structure of the document shall be in a logical correspondence to
+
The requirements structure of the document shall be in a logical correspondence to
 the test suite structure.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Clause 9.2, Table 14
      
+
    5. Reference: Clause 8.2, Table 15
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.8.  Requirement classes and the Conformance Test classes in correspondence

 
-
The requirements classes shall be in a one-to-one correspondence to the conformance
+
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.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 15
      
+
    5. Reference: Table 16
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.9.  No Optional Elements in Requirements classes

 
-
A Conformance class shall not contain any optional conformance tests.

+
A Conformance class shall not contain any optional conformance tests.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 16
      
+
    5. Reference: Table 17
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.10.  Certificate of conformance specifies all parameters used

 
-
A certificate of conformance shall specify all parameter values used to pass the
+
A certificate of conformance shall specify all parameter values used to pass the
 tests in its conformance test class.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 18
      
+
    5. Reference: Table 19
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.11.  Conformance class tests only one requirements class

 
-
A Conformance class shall explicitly test only requirements from a single
+
A Conformance class shall explicitly test only requirements from a single
 requirements class.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 19
      
+
    5. Reference: Table 20
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.12.  Conformance class specifies all dependencies

 
-
A Conformance class shall specify any other conformance class upon which it is
+
A Conformance class shall specify any other conformance class upon which it is
 dependent and that other conformance class shall be used to test the specified
 dependency.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 20
      
+
    5. Reference: Table 21
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.13.  Imported Conformance class tests are consistent with the specification

 
-
If a requirements class is imported from another standard for use within a
+
If a requirements class is imported from another standard for use within a
 standard conformant to this standard, 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.
 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.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 21
      
+
    5. Reference: Table 22
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.14.  Naming consistency

 
-
For the sake of consistency and readability, all requirements classes and all
+
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.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 22
      
+
    5. Reference: Table 23
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.15.  Requirements in one and only one requirements class

 
-
Each requirement in the standard shall be contained in one and only one requirements
+
Each requirement in the standard shall be contained in one and only one requirements
 class. Inclusion of any requirement in a requirements class by a conformance class
 shall imply inclusion of all requirements in its class (as a dependency).

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 23
      
+
    5. Reference: Table 24
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.16.  Co-dependent Requirements are in the same requirements class

 
-
If any two requirements or two requirements modules are co-dependent (each dependent
+
If any two requirements or two requirements modules are co-dependent (each dependent
 on the other) then they shall be in the same requirements class. If any two
 requirements classes are co-dependent, they shall be merged into a single class.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 25
      
+
    5. Reference: Table 26
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.17.  Modularity in implementation is possible

 
-
There shall be a natural structure on the requirements classes so that each may be
+
There shall be a natural structure on the requirements classes so that each may be
 implemented on top of any implementations of its dependencies and independent of its
 extensions.

 
-
All general recommendations shall be in the core.

+
All general recommendations shall be in the core.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 27
      
+
    5. Reference: Table 28
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.18.  Requirements follow rules of inheritance

 
-
No requirements class shall redefine the requirements of its dependencies, unless
+
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.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 28
      
+
    5. Reference: Table 29
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.19.  Profiles are expressed as sets of conformance classes

 
-
The conformance tests for a profile of a standard shall be defined as the union
+
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.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 29
      
+
    5. Reference: Table 30
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.20.  There is a named Core requirements class

 
-
Every standard shall define and identify a core set of requirements as a
+
Every standard shall define and identify a core set of requirements as a
 separate conformance class.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 30
      
+
    5. Reference: Table 31
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.21.  General conditions are in the core

 
-
Every other requirements class in a standard shall have a standardization
+
Every other requirements class in a standard shall have a standardization
 target type which is a subtype of that of the core and shall have the core as a
 direct dependency.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 32
      
+
    5. Reference: Table 33
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.22.  Every extension has a consistent target type

 
-
Every other requirements class in a standard shall have a standardization
+
Every other requirements class in a standard shall have a standardization
 target type which is a subtype of that of the core and shall have the core as a
 direct dependency.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 32
      
+
    5. Reference: Table 33
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.23.  A standard is a core plus some number of extensions

 
-
Each standard conformant to the ModSpec shall consist of the core and some
+
Each standard conformant to the ModSpec shall consist of the core and some
 number of requirements classes defined as extensions to that core.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 38
      
+
    5. Reference: Table 39
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.24.  Conformance to this ModSpec is required for any extensions

 
-
A standard conformant to the ModSpec shall require all conformant extensions
+
A standard conformant to the ModSpec shall require all conformant extensions
 to itself to be conformant to the ModSpec.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 39
      
+
    5. Reference: Table 40
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.25.  Future extensions cannot be restricted

 
-
A standard conformant to the ModSpec shall never restrict in any manner
+
A standard conformant to the ModSpec shall never restrict in any manner
 future, logically-valid extensions of its standardization targets.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 40
      
+
    5. Reference: Table 41
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.26.  Optional requirements are organized as requirements classes

 
-
The only optional requirements acceptable in a standard conformant to this
+
The only optional requirements acceptable in a standard conformant to this
 standard shall be expressible as a list of conformance classes to be passed.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Table 41
      
+
    5. Reference: Table 42
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

 
 
A.1.27.  Requirements classes intersect overlap only by reference

 
-
The common portion of any two requirements classes shall consist only of references
+
The common portion of any two requirements classes shall consist only of references
 to other requirements classes.

 
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 42
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
A.2.  Conformance test class: UML model extends The Standard

-
-
A.2.1.  Dependency on Core

-
-
An implementation passing the UML conformance test class shall first pass the core
-conformance test class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 44
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.2.  The UML model is normative

-
-
To be conformant to this UML conformance class, UML shall be used to express the
-object model, either as the core mechanism of the standard or as a normative adjunct
-to formally explain the standard in a model.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 45
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.3.  Dependency graph must be explicit

-
-
A UML model shall have an explicit dependency graph for the leaf packages and
-external packages used by the standard consistent with the way their classifiers use
-those of other packages.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 46
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.4.  Leaf packages in only one requirements class

-
-
A UML leaf package shall be associated directly to only one requirements class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 47
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.5.  Requirements class associated to a unique package

-
-
Each requirements class shall be associated to a unique package in the model and
-include either directly or by a dependency any requirement associated to any of its
-subpackages.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 48
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.6.  A requirements class contains complete leaf packages

-
-
A requirements class shall be associated to some number of complete leaf packages
-and all classes and constraints in those packages.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 49
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.7.  Classes common to all requirement classes are in the core

-
-
Classes that are common to all requirements classes shall be in a package associated
-to the core conformance/requirements class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 50.
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.8.  Package dependencies become requirements class extensions

-
-
In the UML model, if a “source” package is dependent on a “target” package then
-their requirements class shall be equal or the source package’s class shall be an
-extension of the target package’s class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Table 51.
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.9.  Dependencies in packages are reflected in dependencies in requirements classes

-
-
If one leaf package is dependent on another leaf package, then the requirements
-class of the first shall be the same or an extension of the requirements class of
-the second.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 1.
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.10.  Co-dependent packages are in the same requirements class

-
-
If two packages have a two-way dependency (a “co-dependency”), they shall be
-associated to the same requirements class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 2
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.2.11.  All classes are in leaf packages

-
-
The UML model shall segregate all classes into leaf packages.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 3
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
A.3.  Conformance test class: XML schema extends The Specification

-
-
A.3.1.  Dependency on Core

-
-
An implementation passing the XML schema conformance test class shall first pass the
-core standard conformance test class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 4
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.3.2.  Dependency on W3C XML schema

-
-
An implementation passing the XML schema conformance test class shall first pass the
-W3C Recommendation for XML schema.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 5
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.3.3.  A requirements class corresponds to a single XML namespace

-
-
If a standard conformant to the XML schema conformance class defines a set of
-data schemas, all components (e.g. elements, attributes, types …​) associated with
-a single conformance test class shall be scoped to a single XML namespace.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 6
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.3.4.  A reference to the URI of the test suite in AppInfo

-
-
The all-components schema document for an XML Schema shall indicate the URI of the
-associated conformance test class in the schema/annotation/appinfo element.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 7
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.3.5.  Direct dependencies become schema imports

-
-
If a standard conformant to the XML schema conformance class defines a direct
-dependency from one requirement class to another, then a standardization target of
-the corresponding conformance test class shall import a schema that has passed the
-associated conformance test class (dependency) or shall itself pass the associated
-conformance test class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 8
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.3.6.  No requirements class modifies or redefines elements in another namespace

-
-
No requirements class in a standard conformant to the XML schema conformance
-class shall modify elements, types or any other requirement from a namespace to
-which it is not associated.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 9
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
A.4.  Conformance test class: Schematron

-
-
A.4.1.  Dependency on XML Schema conformance test class

-
-
A standard passing the Schematron conformance test class shall also define or
-reference an XML schema that shall pass the XML schema conformance class from this
-standard.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 10
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.4.2.  Each schematron pattern element implements one requirement

-
-
Each sch:pattern element shall implement constraints described in no more than one
-requirement. Each requirement shall be implemented by no more than one sch:pattern.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 11
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.4.3.  Each schematron pattern is in one schematron element

-
-
Each sch:pattern element shall be contained within one sch:schema element.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 12
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.4.4.  Each schematron @fpi attribute is used only once

-
-
The value of the sch:schema/@fpi attribute shall be used on only one Schematron
-schema.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 13
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.4.5.  Each schematron @see attribute is used only once

-
-
The value of the sch:schema/@see attribute shall be the identifier for the
-requirements class that contains the requirement(s) implemented by the schema

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 14
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.4.6.  Each schematron fpi attribute is used only once

-
-
The value of the sch:schema/@fpi attribute shall be used on only one Schematron
-schema.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 15
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
A.5.  Conformance Class: XML meta-schema

-
-
A.5.1.  Supports the Specification class

-
-
A standard passing the XML meta-schema conformance test class shall first pass
-the core specification conformance test class.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
-
    2. 
-
  2. Test Method: Inspect the document to verify the above.
    
-
    3. 
-
  3. Reference: Requirement 16
    
-
    4. 
-
  4. Test Type: Conformance.
    
-
    5. 
-

-

-
-
A.5.2.  Each XML schema is conformant with the XML Schema class

-
-
A standard passing the XML meta-schema conformance test class shall require
-that its specification targets (XML schema) pass the XML schema conformance class
-from this standard.

-
-
  1. Test Purpose: Verify that this requirement is satisfied.
    
+
    1. Test Purpose: Verify that this requirement is satisfied.
      
 
      2. 
-
    2. Test Method: Inspect the document to verify the above.
      
+
    3. Test Method: Inspect the document to verify the above.
      
 
      4. 
-
    4. Reference: Requirement 17
      
+
    5. Reference: Table 43
      
 
      6. 
-
    6. Test Type: Conformance.
      
+
    7. Test Type: Conformance.
      
 
      8. 
 
    
 

-

Annex B
(normative)
OGC Only: Changes required in the OGC Standards
NOTE:    The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards
B.1.  New OGC standards and revisions to existing OGC standards

+

Annex B
(normative)
OGC Only: Changes required in the OGC Standards
NOTE:    The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards
B.1.  New OGC standards and revisions to existing OGC standards

 
 
Any new standard or major revision of an existing standard SHALL
 comply with the ModSpec in the structure of its internal models and its
@@ -3966,228 +3018,199 @@ 
4.28. state
 Rules”) or as specified in the authorities Policy and Procedures for an exception to
 procedure. In the OGC, a similar vote is required within the Executive Planning Committee or as specified
 in any Policy and Procedure document used by this committee.

-

Annex C
(informative)
Definitions
C.1.  Semantically ordered definitions

+

Annex C
(informative)
ModSpec UML Model, semantics, and Definitions
C.1.  Semantically ordered definitions

 
-
Clause 4 formally defines the terms used in the conformance tests in alphabetical
+
Clause 4 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:

 
-
  1. a standardization target type (Clause 4.27) is a type of entity about which a standard
+
    1. a standardization target type (Clause 4.27) is a type of entity about which a standard
 is written. An instance of a standardization target type (Clause 4.27) is a
 standardization target (Clause 4.26). A standard may address multiple targets in separate
 conformance classes.
      
 
      2. 
-
    2. a requirement (Clause 4.21) is a statement of a condition to be satisfied by a single
+
    3. a requirement (Clause 4.21) is a statement of a condition to be satisfied by a single
 standardization target type (Clause 4.27), and it must be stated in “normative” language.
      
 
      4. 
-
    4. a conformance test (Clause 4.4) checks if a set of
+
    5. a conformance test (Clause 4.3) checks if a set of
 requirements (Clause 4.21) are met (pass) or not met (fail) by a
-standardization target (Clause 4.26). The relationship between  conformance tests (Clause 4.4) and requirements (Clause 4.21) is many-to-many.
      
+standardization target (Clause 4.26). The relationship between  conformance tests (Clause 4.3) and requirements (Clause 4.21) is many-to-many.
      
 
      6. 
-
    6. all  conformance tests (Clause 4.4) are graded as pass or fail
+
    7. all  conformance tests (Clause 4.3) are graded as pass or fail
 against each instance of the standardization target (Clause 4.26).
      
 
      8. 
-
    8. a requirement (Clause 4.21) is associated to one conformance test (Clause 4.4).
      
+
    9. a requirement (Clause 4.21) is associated to one conformance test (Clause 4.3).
      
 
      10. 
-
    10. a recommendation (Clause 4.20) is a suggestion and is not associated to any
-conformance test (Clause 4.4).
      
+
    11. a recommendation (Clause 4.20) is a suggestion and is not associated to any
+conformance test (Clause 4.3).
      
 
      12. 
-
    12. a requirements class (Clause 4.22) is a set of one or more requirements (Clause 4.21)
+
    13. a requirements class (Clause 4.22) is a set of one or more requirements (Clause 4.21)
 all with the same standardization target type (Clause 4.27).
      
 
      14. 
-
    14. a conformance (test) class (Clause 4.7) is a collection of
-conformance tests (Clause 4.4) that are associated to and only to the
+
    15. a conformance (test) class (Clause 4.6) is a collection of
+conformance tests (Clause 4.3) that are associated to and only to the
 requirements in a corresponding requirements class (Clause 4.22).
      
 
      16. 
-
    16. a conformance (test) module (Clause 4.6) is also collection of
+
    17. a conformance (test) module (Clause 4.5) is also collection of
 term conformance test classes not resolved via ID conformance-test-classes that group
- conformance tests (Clause 4.4) on a single
+ conformance tests (Clause 4.3) on a single
 standardization target type (Clause 4.27).
      
 
      18. 
-
    18. a conformant implementation is a standardization target type (Clause 4.27) that has
-successfully passed all tests in a specified conformance (test) class (Clause 4.7) and received a certificate of conformance (Clause 4.3)
      
+
    19. a conformant implementation is a standardization target type (Clause 4.27) that has
+successfully passed all tests in a specified conformance (test) class (Clause 4.6) and received a certificate of conformance (Clause 4.2)
      
 
      20. 
-
    20. the core requirements class (Clause 4.9) of a standard is the minimal set of
+
    21. the core requirements class (Clause 4.8) of a standard is the minimal set of
 requirements (Clause 4.21) which must be supported by all conformant implementations. If a standard addresses multiple standardization target types (Clause 4.27), it may have a core for each target type.
      
 
      22. 
-
    22. an extension of a requirements class (Clause 4.22) is an additional requirements class (Clause 4.22)
+
    23. an extension of a requirements class (Clause 4.22) is an additional requirements class (Clause 4.22)
 (the extension) that adds additional requirements (Clause 4.21) to the first
 requirements class (Clause 4.22) (the base requirements class being extended). The
-extension is said to be dependent on the base. Any conformance test class (Clause 4.7)
+extension is said to be dependent on the base. Any conformance test class (Clause 4.6)
 must identify all its dependencies during the execution of conformance tests
 against a candidate standardization target (Clause 4.26).
      
 
      24. 
 
    
-
C.2.  UML Model

+
C.2.  UML Model

 
-

+
Figure C.1

 
-
Figure C.1 — Specification structure

-
-
Figure C.1 represents a UML model consistent with the specification model described
-in [cls-6-1]. The following subclauses describe the classes shown in this UML
+
Figure 1 represents a UML model consistent with the model described
+in Clause 8 of this document. The following subclauses describe the classes shown in this UML
 class diagram.

-
C.3.  Specification

-
-
C.4.  Specification

+
C.3.  Standard

 
-
For a draft standard (aka specification) to become an international standard, the document must be approved by an authority,
+
For a draft standard (aka specification) to become an international standard, the document must be approved by an authority,
 such as ISO or the OGC. The attributes of a standard describe its local name, its authority, the date of publication
 and its current status (such as CD, DIS, IS in ISO, or Draft, Candidate Standard, or Standard in OGC).

 
-
The attributes of a
+
The attributes of a
 Standard describe its local name, its authority, the date of
 publication and its current status (such as Draft,
 Candidate Standard or Standard in the OGC).

 
-
Table C.1 — Specification attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the standard.M1String
authorityStandards body or author of this standard.M1Principal
datePublication date of the standard.M1DateTime
statusPublication status of this standard.M1String

-
C.5.  Conformance Suite

-
-
C.6.  Conformance Class

-
-
C.7.  ConformanceClass

-
-
The requirements in the requirements classes of a standard must be
+
Table C.1 — Standard attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the standard.M1String
authorityStandards body or author of this standard.M1Principal
datePublication date of the standard.M1DateTime
statusPublication status of this standard.M1String

+
C.4.  ConformanceSuite

+
+
The unique conformance suite of a standard lists the tests (possibly grouped
+into conformance test modules consisting of some number of conformance
+test classes, each containing some number of conformance tests) that allow
+testing of an implementation of the standard for conformance with the
+requirements stated in the standard. Every standard needs one of these suites, or
+conformance cannot be claimed with proof. In ISO and the OGC, the conformance
+suite included in the standard is usually an abstract description of
+the tests which will be implemented. Other standards may use a more
+concrete description. For the purposes of the ModSpec, the precise
+nature of the conformance suite is not particularly important as long as
+it is not ambiguously stated.

+
+
Each conformance test within a conformance class should be against a
+single standardization target defined for that class. A conformance suite
+may contain several defined conformance classes for the same
+standardization target.

+
+
Table C.2 — ConformanceSuite attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
classesConformance classes that this conformance suite contains.MNConformanceClass

+
C.5.  ConformanceClass

+
+
The requirements in the requirements classes of a standard must be
 tested and the conformance classes are the containers for these tests’
-definition. The requirements classes will have interdependencies, and this
+definition. The requirements classes may have interdependencies, and this
 is reflected in the explicit dependencies between the conformance classes.
 If class “a” is dependent on class “b”, then to pass the test for “a” a
 standardization target must also pass the test for “b.” The class name is
 shared with its corresponding requirements class.

 
-
Table C.2 — ConformanceClass attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the conformance class.M1String
dependenciesConformance classes that this conformance class depends on.
+
Table C.3 — ConformanceClass attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the conformance class.M1String
dependenciesConformance classes that this conformance class depends on.
 These dependent conformance classes must be passed if this one is to be
 passed.ONConformanceClass
requirementsClassThe requirements class that this conformance class aims to test against.M1RequirementsClass

-
C.8.  Requirements class

+
C.6.  RequirementsClass

 
-
C.9.  RequirementsClass

-
-
Requirements classes (usually realized as clauses in the
+
Requirements classes (usually realized as clauses in the
 standard’s document) segment the requirements in the standard in a
 manner consistent with the conformance classes. Since the requirements
 class and the conformance class will eventually be referred to in a
 certification of conformance, they should have names, probably in the
 namespace defined by the standard’s name and authority.

 
-
Table C.3 — RequirementsClass attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the requirements class.M1String
dependenciesRequirements classes that this requirements class depends on.
+
Table C.4 — RequirementsClass attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the requirements class.M1String
dependenciesRequirements classes that this requirements class depends on.
 These dependent requirements classes must be satisfied for this
-requirements class to be satisfied.ONRequirementsClass
modulesRequirements modules that make up this requirements class.MNRequirementsModule
targetTypeType of standardization target.M1StandardizationTargetType

-
C.10.  Requirements module

-
-
C.11.  RequirementsModule

+requirements class to be satisfied.
ONRequirementsClass
modulesA set of one or more requirement(s) classes, recommendations, and permissions with the same standardization target.MNRequirementsModule
targetTypeType of standardization target.M1StandardizationTargetType

+
C.7.  RequirementsModule

 
-
A requirements modules (usually realized as groups of one or more
+
A requirements module (usually realized as groups of one or more
 requirements classes in the standard) group the
-requirements and recommendations in the standrd in a manner consistent with the
+requirements and recommendations in the standard in a manner consistent with the
 conformance test modules.

 
-
Table C.4 — RequirementsModule attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the requirements module.M1String
requirementsRequirements classes that this requirements module contains.MNRequirement

-
C.12.  Normative Statement

-
-
C.13.  NormativeStatement

+
Table C.5 — RequirementsModule attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the requirements module.M1String
requirementsRequirements classes, recommendations, and permissions that this requirements module contains.MNRequirement

+
C.8.  NormativeStatement

 
-
The normative statements, either requirements or recommendations of a
+
The normative statements, either requirements or recommendations of a
 standard, are organized into the requirements modules and classes, and may
 be tested by the conformance tests in their requirements class’s
 corresponding conformance class. If tested, the statement is a
 “Requirement”, and if not tested the statement is a “Recommendation”.

 
-
Table C.5 — NormativeStatement attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the normative statement.M1String

-
C.14.  Requirement

+
Table C.6 — NormativeStatement attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the normative statement.M1String

+
C.9.  Requirement

 
-
C.15.  Requirement

+
Normative statement that constitutes a requirement.

 
-
Normative statement that constitutes a requirement.

-
-
Table C.6 — Requirement attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
testsConformance tests that when passed confirm the satisfaction of this
+
Table C.7 — Requirement attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
testsConformance tests that when passed confirm the satisfaction of this
 requirement.
 
 NOTE: If this requirement is a requirement part, it may or may not have
 a corresponding conformance test.MNConformanceTest
partsCollection of requirements that are parts to this requirement.
 Satisfaction of all requirement parts are necessary for this requirement
 to be satisfied. Optional.ONRequirement

-
C.16.  Recommendation

-
-
C.17.  Recommendation

+
C.10.  Recommendation

 
-
A normative suggestion which will not be directly tested is a
+
A normative suggestion which will not be directly tested is a
 “Recommendation.” Recommendations have a variety of uses, for example:

 
-
  • Legal restriction, such as “not for commercial use” or “for planning
+
    • Legal restriction, such as “not for commercial use” or “for planning
 purposes.” These allow the specification to restrict use of its
 implementation to standardization targets for which it was designed.
      
 
      • 
-
    • Statement of best practices. These are included as suggestions for
+
    • Statement of best practices. These are included as suggestions for
 logical designs that may implement the requirements in the same module.
      
 
      • 
 
    
 
-
    Regardless of their use, Recommendations are not tested since they are not
+
    Regardless of their use, Recommendations are not tested since they are not
 required of all conformant implementations.
    
-
C.18.  Conformance test

+
C.11.  ConformanceTest

 
-
C.19.  ConformanceTest

-
-
A conformance test aims to satisfy a requirement and can potentially
+
A conformance test aims to satisfy a requirement and can potentially
 contain multiple test methods.

 
-
Table C.7 — ConformanceTest attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
abstractWhether this test is abstract or concrete. An abstract conformance test
+
Table C.8 — ConformanceTest attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
abstractWhether this test is abstract or concrete. An abstract conformance test
 is commonly called an abstract test.M1Boolean
testPurposePurpose of the conformance test.M1String
testTypeType of the conformance test.M1TestType
testMethodMethod to perform this conformance test.
 A method is considered a “part” of the test if there are multiple of them.ONConformanceTestMethod
referencesReferences to the specification(s) of the conformance test.ONRichText
requirementsCorresponding requirement or requirement part that this conformance
 test is supposed to test against.MNRequirement

-
C.20.  StandardizationTarget

-
-
C.21.  StandardizationTarget

+
C.12.  StandardizationTarget

 
-
Each conformance class (and hence requirements class) is targeted to a
+
Each conformance class (and hence requirements class) is targeted to a
 particular type of implementation. An implementation testable by a
 conformance class is a StandardizationTarget of that class, and (once the
 appropriate test have been passed) can carry a certificate indicating its
 conformance to a requirements class proved by the tests in the conformance
 class.

 
-
Table C.8 — StandardizationTarget attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
conformanceCertificatesconformance classes passed by this targetONString
typeType of the standardization target type.M1StandardizationTargetType

-
C.22.  StandardizationTargetType

-
-
C.23.  StandardizationTargetType

+
Table C.9 — StandardizationTarget attributes
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
conformanceCertificatesconformance classes passed by this targetONString
typeType of the standardization target type.M1StandardizationTargetType

+
C.13.  StandardizationTargetType

 
-

Bibliography

+

Annex D
(normative)
Acknowledgements
The following OGC Members were key contributors to Version 1 of the ModSpec
PersonOrganization Represented
Simon CoxCSIRO
David DankoEesi
James GreenwoodSeiCorp, Inc.
John R. HerringOracle USA
Andreas MatheusUniversity of the Bundeswehr — ITS
Richard PearsallUS National Geospatial-Intelligence Agency (NGA)
Clemens Porteleinteractive instruments GmbH
Barry ReffUS Department of Homeland Security (DHS)
Paul ScarponciniBentley Systems, Inc.
Arliss WhitesideBAE Systems — C3I Systems

Bibliography

 
-
To preserve a unique numeric identifier for all documents listed as references in
+
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 Clause 3.
[1]  ISO/IEC: ISO/IEC 9075:2003, ISO/IEC JTC 1, ISO/IEC 9075:2003 — Information Technology — Database Languages — SQL.. ISO, IEC (2003).
[2]  ISO/IEC: ISO/IEC TR 10000, ISO/IEC TR 10000: Information Technology — Framework and taxonomy of International Standardized Profiles. ISO, IEC
[3]  ISO/IEC: ISO/IEC 13249-3:2006, Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial. International Organization for Standardization, International Electrotechnical Commission, Geneva (2006). https://www.iso.org/standard/38651.html.
[4]  Object Management Group (OMG), February 2007, Unified Modeling Language: Infrastructure , version 2.1.1 , formal/07-02-06, available from OMG.org at http://www.omg.org/cgi-bin/doc?formal/07-02-06
[5]  Object Management Group (OMG), February 2007, Unified Modeling Language: Superstructure, version 2.1.1 , formal/07-02-05, available from OMG.org at http://www.omg.org/cgi-bin/doc?formal/07-02-05
[6]  W3C: W3C xmlschema11-1, W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. World Wide Web Consortium http://www.w3.org/TR/xmlschema11-1/.
[7]  W3C: W3C xmlschema11-2, W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. World Wide Web Consortium http://www.w3.org/TR/xmlschema11-2/.

-
-
+of normative reference in Clause 3.
[1]  ISO/IEC: ISO/IEC 9075:2003, ISO/IEC JTC 1, ISO/IEC 9075:2003 — Information Technology — Database Languages — SQL.. ISO, IEC (2003).
[2]  ISO/IEC: ISO/IEC TR 10000, ISO/IEC TR 10000: Information Technology — Framework and taxonomy of International Standardized Profiles. ISO, IEC
[3]  ISO/IEC: ISO/IEC 13249-3:2006, Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial. International Organization for Standardization, International Electrotechnical Commission, Geneva (2006). https://www.iso.org/standard/38651.html.
[4]  W3C: W3C xmlschema11-1, W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. World Wide Web Consortium http://www.w3.org/TR/xmlschema11-1/.
[5]  W3C: W3C xmlschema11-2, W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. World Wide Web Consortium http://www.w3.org/TR/xmlschema11-2/.

 
 
 
 
 
 
-
-
Bibliography for examples

-
-
The following documents are either standards or draft standards that in general
-follow the general rules of ISO for conformance test suites. The first two (GeoREL
-and the OWS5 discussion of WFS) meet most of the requirements of this standard.
[8]  John Herring: OGC 08-079, OWS5: OGC Web feature service, core and extensions. Open Geospatial Consortium (2008).
[9]  ISO: ISO 19101, Geographic information — Reference model. International Organization for Standardization, Geneva https://www.iso.org/standard/26002.html.
[10]  ISO: ISO 19107, Geographic information — Spatial schema. International Organization for Standardization, Geneva https://www.iso.org/standard/66175.html.
[11]  ISO: ISO 19111, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva https://www.iso.org/standard/74039.html.
[12]  ISO: ISO 19119, Geographic information — Services. International Organization for Standardization, Geneva https://www.iso.org/standard/59221.html.
[13]  ISO: ISO 19125, Geographic information — Simple features. ISO
[14]  ISO: ISO 19133, Geographic information — Location-based services — Tracking and navigation. International Organization for Standardization, Geneva https://www.iso.org/standard/32551.html.
[15]  ISO: ISO 19136, Geographic information — Geography Markup Language (GML). International Organization for Standardization, Geneva https://www.iso.org/standard/32554.html.
[16]  ISO: ISO 19141, Geographic information — Schema for moving features. International Organization for Standardization, Geneva https://www.iso.org/standard/41445.html.
[17]  ISO: ISO 19142, Geographic information — Web Feature Service. International Organization for Standardization, Geneva https://www.iso.org/standard/42136.html.
[18]  ISO: ISO 19143, Geographic information — Filter encoding. International Organization for Standardization, Geneva https://www.iso.org/standard/42137.html.
[19]  ISO: ISO 19148, Geographic information — Linear referencing. International Organization for Standardization, Geneva https://www.iso.org/standard/75150.html.
[20]  ISO: ISO 19149, Geographic information — Rights expression language for geographic information — GeoREL. International Organization for Standardization, Geneva https://www.iso.org/standard/32567.html.
[21]  ISO: ISO 19153, Geospatial Digital Rights Management Reference Model (GeoDRM RM). International Organization for Standardization, Geneva https://www.iso.org/standard/32571.html.
[22]  ISO: ISO 19156, Geographic information — Observations, measurements and samples. International Organization for Standardization, Geneva https://www.iso.org/standard/82463.html.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

-