From b3a52b1f1e40f96e8e1069aa7f553deeab280051 Mon Sep 17 00:00:00 2001 From: Chuck Heazel Date: Mon, 16 Dec 2024 22:14:50 -0500 Subject: [PATCH] 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):
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):
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:
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:
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:
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:
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.

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

-