diff --git a/.gitignore b/.gitignore index 496ee2c..eb2c7d1 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,4 @@ -.DS_Store \ No newline at end of file +.DS_Store +relaton/cache +iev/cache +*.err diff --git a/sources/document.err.html b/sources/document.err.html deleted file mode 100644 index 81d4bdf..0000000 --- a/sources/document.err.html +++ /dev/null @@ -1,1378 +0,0 @@ -./document.err.html errors - - -

./document.err.html errors

-

AsciiDoc Input

- - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
_moduleterm reference not in expected format:​Cambridge Dictionary
#<Asciidoctor::Block@582420 {context: :paragraph, content_model: :simple, style: nil, lines: 1}>
1
000414_7cd0aac3-3b23-4fe0-9e79-76ee7ac3af1dError: Term reference to conformance-tests missing: "conformance-tests" is not defined in document -
<refterm>conformance tests</refterm>
1
000688_a68cabbf-42dd-49b3-a33b-8f697cc09dbcError: Term reference to requirements missing: "requirements" is not defined in document -
<refterm>requirements</refterm>
1
000703_a211e04d-3017-4729-8386-0217eee2d9d3Error: Term reference to requirement-class missing: "requirement-class" is not defined in document -
<refterm>requirement class</refterm>
1
003005_9bbedde5-b984-4754-b084-9580b773bb67Error: Term reference to conformance-test-classes missing: "conformance-test-classes" is not defined in document -
<refterm>conformance test classes</refterm>
1
-

Anchors

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
000115_98dba55f-513e-396f-31a4-f8b75c176929Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000159_33fd6022-bfb3-74da-0b67-ed92735b6984Crossreference target Annex-B is undefined
<xref target="Annex-B"/>
1
000172_651796f5-b6a0-99f5-7e54-853cf3b65b94Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000193_63225180-37d8-b5d0-dcbe-58b8788328c2Crossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000204_7bc86d06-e3dd-d547-9d8b-ba4ab6ed4f0dCrossreference target cls-6 is undefined
<xref target="cls-6"/>
1
000337_24a00bc9-3781-2e6c-bbae-ae9e108a1c5eCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
000925_c24ae51e-2e3d-5f23-950c-376a3c582267Crossreference target annex-B-2 is undefined
<xref target="annex-B-2"/>
1
001203_82359971-bb71-490a-b5de-fbbc22d44eecnormalised identifier in ​ from term-indirect-dependency-(of-a-requirements-class)
<xref target="term-indirect-dependency-_of-a-requirements-class_"/>
2
001709_60082278-63f2-144f-8057-9d783a1e10aeCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
003032_c61630e4-cc0b-6003-6593-fb89389ef95dCrossreference target cls-6-1 is undefined
<xref target="cls-6-1"/>
1
-

Style

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
--Abstract is missing!
2
--Keywords are missing!
2
--Submitters is missing!
2
000043_fe677788-6b9c-198a-8437-43081ea8d1beTable should have title
<table id="_fe677788-6b9c-198a-8437-43081ea8d1be" 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> </tbody>
2
000055_efd73240-fcac-8f47-ef08-891532957519Table should have title
<table id="_efd73240-fcac-8f47-ef08-891532957519" unnumbered="true"> <tbody> <tr> <th valign="middle" align="center">Person</th>
-<th valign="middle" align="center">Organization Represented</th>
-</tr> <tr> <td valign="middle" align="left">Simon Cox</td>
-<td valign="middle" align="left">CSIRO and OGC Fellow</td>
-</tr> <tr> <td valign="middle" align="left">Chuck Heazel</td>
2
000073_bec1efc8-b35d-8234-bf37-20a60850f2ecTable should have title
<table id="_bec1efc8-b35d-8234-bf37-20a60850f2ec"> <tbody> <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>
-<td valign="middle" align="left">ESRI</td>
-</tr> <tr> <td valign="middle" align="left">James Greenwood</td>
2
000777_​conventionsHanging paragraph in clause
<clause id="_conventions" obligation="normative">
-<title>Conventions</title>
-<clause id="_symbols_and_abbreviated_terms" obligation="normative">
-<title>Symbols (and abbreviated terms)</title>
-<p id="_189b05f8-d8bd-86ff-6cae-0a71bf9b4a45">All symbols used in this document are either:</p>
2
001055_​requirements_class_​coreHanging paragraph in clause
<clause id="_requirements_class_core" obligation="normative">
-<title>Requirements Class: Core</title>
-<p id="_4e1f24e5-6a13-bc05-c478-2360e4a858df">The following requirements specify the rules for the content and structure of a modular standard. These requirements are also known as the <tt>core</tt> of the ModSpec.</p>
-
-<table id="req-1" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ001</strong> </td>
2
001059req-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
001071req-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
001084rec-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
001098per-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
001112per-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
001119per-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
001131req-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
001138per-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
001181req-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
001193req-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
001205per-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
001223per-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
001244req-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
001252req-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
001289req-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
001303req-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
001316per-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
001337req-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
001346req-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
001358req-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
001394req-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
001411req-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
001428req-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
001443rec-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
001457req-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
001472rec-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
001478req-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
001499req-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
001529req-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
001540req-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
001547req-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
001553req-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
001563rec-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
001569per-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
001575per-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
001581rec-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
001592per-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
001614req-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
001621req-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
001634req-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
001656req-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="_4155d57b-db97-9eb7-8ae3-115c7ffbf872"> <p id="_dfa8455f-84e5-c446-af14-a8d39abc10dc">Standards and implementations are restricted by this, but not instances of
2
001674req-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
001747_1a713ad5-d317-7e27-d321-9ea6cca0285bTable should have title
<table id="_1a713ad5-d317-7e27-d321-9ea6cca0285b" width="90%"> <colgroup> <col width="20%"/> <col width="80%"/> </colgroup> <tbody> <tr> <td colspan="2" valign="middle" align="left"> <strong>Requirements Class — UML extension to the core</strong> </td>
-</tr> <tr> <td colspan="2" valign="middle" align="left">/req/core/data-representation</td>
-</tr> <tr> <td valign="middle" align="left">Target</td>
-<td valign="middle" align="left">ModSpec Conformant UML Model</td>
-</tr> <tr> <td valign="middle" align="left">Dependency</td>
2
001780req-28Table should have title
<table id="req-28" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ028</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/conformance-with-core</strong> <br/>
-An implementation passing the UML conformance test class <em>SHALL</em> first pass the core
-conformance test class</td>
-</tr> </tbody>
2
001796req-29Table should have title
<table id="req-29" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ029</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/object-model</strong> <br/>
-To be conformant to this UML requirements class, UML <em>SHALL</em> be used to express the
-object model, either as the core mechanism of the standard or as a normative adjunct
-to formally explain the standard in a model</td>
2
001804req-30Table should have title
<table id="req-30" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ030</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/dependency-graph</strong> <br/>
-A UML model <em>SHALL</em> have an explicit dependency graph for the leaf packages and
-external packages used by the standard consistent with the way their classifiers use
-those of other packages</td>
2
001826req-31Table should have title
<table id="req-31" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ031</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/leaf-model</strong> <br/>
-A UML leaf package <em>SHALL</em> be associated directly to only one requirements class.</td>
-</tr> </tbody>
-</table>
2
001832req-32Table should have title
<table id="req-32" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ032</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/class-package</strong> <br/>
-Each requirements class shall be associated to a unique package in the model and
-include either directly or by a dependency any requirement associated to any of its
-subpackages.</td>
2
001844req-33Table should have title
<table id="req-33" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ033</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/to-leaf</strong> <br/>
-A requirements class <em>SHALL</em> be associated to some number of complete leaf packages
-and all classes and constraints in those packages.</td>
-</tr> </tbody>
2
001856req-34Table should have title
<table id="req-34" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ034</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/common-req-classe</strong> <br/>
-Classes that are common to all requirements classes <em>SHALL</em> be in a package
-associated to the core requirements class.</td>
-</tr> </tbody>
2
001873req-35Table should have title
<table id="req-35" width="90%"> <colgroup> <col width="25%"/> <col width="75%"/> </colgroup> <tbody> <tr> <td valign="middle" align="left"> <strong>REQ035</strong> </td>
-<td valign="middle" align="left"> <strong>/req/core/uml/source-target</strong> <br/> </td>
-</tr> <tr> <td valign="middle" align="center">A</td>
-<td valign="middle" align="left">In the UML model, if a “source” package is dependent on a “target” package then
-their requirements class <em>SHALL</em> be equal or</td>
2
002942annex-BHanging paragraph in clause
<annex id="annex-B" obligation="normative">
-<title>OGC Only: Changes required in the OGC Standards</title>
-<note id="_b37e62e1-9150-ac84-bf8a-eed002ecf6da"> <p id="_26a1a2db-74fd-baf5-c5e0-85ca8d2b73eb">The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards</p>
-</note>
-
2
-

Requirements

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
001891req-36Requirement req-36 has no corresponding Conformance test -
<requirement id="req-36" model="ogc" type="general"> <description> <p id="_2b1dca6f-0ca4-456a-5ae9-be8c8a3ada88"> <hi>If one leaf package is dependent on another leaf package, then the requirements class of the first <em>SHALL</em> be the same or an extension of the requirements class of the second.</hi> </p> </description>
-</requirement>
2
001894req-37Requirement req-37 has no corresponding Conformance test -
<requirement id="req-37" model="ogc" type="general"> <description> <p id="_04b1d6d3-d634-b0c8-c1e0-dff25a235a8c"> <hi>If two packages have a two-way dependency (a “co-dependency”), they <em>SHALL</em> be associated to the same requirements class.</hi> </p> </description>
-</requirement>
2
001909req-38Requirement req-38 has no corresponding Conformance test -
<requirement id="req-38" model="ogc" type="general"> <description> <p id="_998e0bdb-e14f-6584-1ae3-97acc460c987"> <hi>The UML model <em>SHALL</em> segregate all classes into leaf packages.</hi> </p> </description>
-</requirement>
2
001922req-39Requirement req-39 has no corresponding Conformance test -
<requirement id="req-39" model="ogc" type="general"> <description> <p id="_74ba1abe-92b5-50d8-36fa-c6c65629a870"> <hi>An implementation passing the XML schema conformance test class shall first pass the ModSpec core conformance test class.</hi> </p> </description>
-</requirement>
2
001925req-40Requirement req-40 has no corresponding Conformance test -
<requirement id="req-40" model="ogc" type="general"> <description> <p id="_00130f8e-1b05-56ff-603b-0b3900ea9313"> <hi>An implementation passing the XML schema conformance test class shall first pass the W3C Recommendation for XML schema.</hi> </p> </description>
-</requirement>
2
001953req-41Requirement req-41 has no corresponding Conformance test -
<requirement id="req-41" model="ogc" type="general"> <description> <p id="_7fb93eed-17c3-0843-d859-d4d62df7b6ee"> <hi>If a standard conformant to the XML schema conformance class defines a set of data schemas, all components (e.g. elements, attributes, types …​) associated with a single conformance test class shall be scoped to a single XML namespace.</hi> </p> </description>
-</requirement>
2
001956req-42Requirement req-42 has no corresponding Conformance test -
<requirement id="req-42" model="ogc" type="general"> <description> <p id="_e5e8f741-01d3-52c5-92e1-775328fab3c4"> <hi>The all-components schema document for an XML Schema shall indicate the URI of the associated conformance test class in the schema/annotation/appinfo element.</hi> </p> </description>
-</requirement>
2
001972req-43Requirement req-43 has no corresponding Conformance test -
<requirement id="req-43" model="ogc" type="general"> <description> <p id="_33096180-c983-0982-b24a-842660dad83a"> <hi>If a standard conformant to the XML schema conformance class defines a direct dependency from one requirement class to another, then a standardization target of the corresponding conformance test class shall import a schema that has passed the associated conformance test class (dependency) or shall itself pass the associated conformance test class.</hi> </p> </description>
-</requirement>
2
001990req-44Requirement req-44 has no corresponding Conformance test -
<requirement id="req-44" model="ogc" type="general"> <description> <p id="_eed94f28-352c-66c6-eef6-e5f6cafcd82f"> <hi>No requirements class in a specification conformant to the XML schema conformance class shall modify elements, types or any other requirement from a namespace to which it is not associated.</hi> </p> </description>
-</requirement>
2
002020req-45Requirement req-45 has no corresponding Conformance test -
<requirement id="req-45" model="ogc" type="general"> <description> <p id="_f0fe7523-316c-2353-5557-124c93604f05"> <hi>A standard passing the Schematron conformance test class shall also define or reference an XML schema that shall pass the XML schema conformance class from this standard.</hi> </p> </description>
-</requirement>
2
002026req-46Requirement req-46 has no corresponding Conformance test -
<requirement id="req-46" model="ogc" type="general"> <description> <p id="_4cc13f08-8445-04c9-2e4e-f74541132cf4"> <hi>Each sch:pattern element shall implement constraints described in no more than one requirement. Each requirement shall be implemented by no more than one sch:pattern.</hi> </p> </description>
-</requirement>
2
002029req-47Requirement req-47 has no corresponding Conformance test -
<requirement id="req-47" model="ogc" type="general"> <description> <p id="_a4360841-759a-881a-957d-d4faa000e889"> <hi>Each sch:pattern element shall be contained within one sch:schema element.</hi> </p> </description>
-</requirement>
2
002032req-48Requirement req-48 has no corresponding Conformance test -
<requirement id="req-48" model="ogc" type="general"> <description> <p id="_d98ef4cd-7697-d88d-815d-129bd7e148d7"> <hi>The value of the sch:schema/@fpi attribute shall be a URI that identifies this implementation</hi> </p> </description>
-</requirement>
2
002035req-49Requirement req-49 has no corresponding Conformance test -
<requirement id="req-49" model="ogc" type="general"> <description> <p id="_f83d696f-f532-2020-95f9-944fe8189f6e"> <hi>The value of the sch:schema/@see attribute shall be the identifier for the requirements class that contains the requirement(s) implemented by the schema</hi> </p> </description>
-</requirement>
2
002038req-50Requirement req-50 has no corresponding Conformance test -
<requirement id="req-50" model="ogc" type="general"> <description> <p id="_b838e944-9302-9fff-6c6d-eaab10ddc31e"> <hi>The value of the sch:schema/@fpi attribute shall be used on only one Schematron schema.</hi> </p> </description>
-</requirement>
2
002052req-51Requirement req-51 has no corresponding Conformance test -
<requirement id="req-51" model="ogc" type="general"> <description> <p id="_b578abe8-31dc-3def-df4b-5b81d4be4413"> <hi>A standard passing the XML meta-schema conformance test class shall first pass the core specification conformance test class.</hi> </p> </description>
-</requirement>
2
002058req-52Requirement req-52 has no corresponding Conformance test -
<requirement id="req-52" model="ogc" type="general"> <description> <p id="_83a2654f-67e3-4da6-ea3f-36773096dd74"> <hi>A standard passing the XML meta-schema conformance test class shall require that its specification targets (XML schema) pass the XML schema conformance class from the ModSpec.</hi> </p> </description>
-</requirement>
2
-

Document Attributes

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

Metanorma XML Syntax

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LineIDMessageContextSeverity
XML Line 000004:42attribute "format" not allowed here; expected attribute "locale",​ "script" or "type"
2
XML Line 000067:82element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000074:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000084:71element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000100:66element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000103:61element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000112:58element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000121:62element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000145:76element "acknowledgements" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000145:76found attribute "id", but no attributes allowed here
2
XML Line 000145:76found attribute "obligation", but no attributes allowed here
2
XML Line 000147:47found attribute "id", but no attributes allowed here
2
XML Line 000149:51found attribute "id", but no attributes allowed here
2
XML Line 000149:95found attribute "align", but no attributes allowed here
2
XML Line 000149:95found attribute "valign",​ but no attributes allowed here
2
XML Line 000150:34found attribute "align", but no attributes allowed here
2
XML Line 000150:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000151:43found attribute "align", but no attributes allowed here
2
XML Line 000151:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000152:34found attribute "align", but no attributes allowed here
2
XML Line 000152:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000153:43found attribute "align", but no attributes allowed here
2
XML Line 000153:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000154:34found attribute "align", but no attributes allowed here
2
XML Line 000154:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000155:43found attribute "align", but no attributes allowed here
2
XML Line 000155:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000156:34found attribute "align", but no attributes allowed here
2
XML Line 000156:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000157:43found attribute "align", but no attributes allowed here
2
XML Line 000157:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000158:34found attribute "align", but no attributes allowed here
2
XML Line 000158:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000159:43found attribute "align", but no attributes allowed here
2
XML Line 000159:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000160:34found attribute "align", but no attributes allowed here
2
XML Line 000160:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000161:43found attribute "align", but no attributes allowed here
2
XML Line 000161:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000162:34found attribute "align", but no attributes allowed here
2
XML Line 000162:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000163:43found attribute "align", but no attributes allowed here
2
XML Line 000163:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000164:34found attribute "align", but no attributes allowed here
2
XML Line 000164:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000165:43found attribute "align", but no attributes allowed here
2
XML Line 000165:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000166:34found attribute "align", but no attributes allowed here
2
XML Line 000166:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000167:43found attribute "align", but no attributes allowed here
2
XML Line 000167:43found attribute "valign",​ but no attributes allowed here
2
XML Line 000168:34found attribute "align", but no attributes allowed here
2
XML Line 000168:34found attribute "valign",​ but no attributes allowed here
2
XML Line 000171:112element "clause" not allowed here; expected the element end-tag or element "submitters"
2
XML Line 000335:102element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000335:234element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000609:112element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000609:229element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000624:109element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 000624:245element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 001146:11element "example" incomplete; expected element "dl", "figure",​ "formula", "ol", "p", "quote", "sourcecode" or "ul"
2
XML Line 002967:129element "concept" incomplete; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 002967:18element "strong" not allowed here; expected element "eref", "erefstack", "refterm", "renderterm", "termref" or "xref"
2
XML Line 003368:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003370:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003374:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003376:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003382:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003384:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003386:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003391:146found attribute "format",​ but no attributes allowed here
2
XML Line 003393:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003395:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003397:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003400:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003402:170found attribute "format",​ but no attributes allowed here
2
XML Line 003406:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003408:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003410:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003412:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003420:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003422:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003424:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003426:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003431:292attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003435:217element "link" missing required attribute "target"
2
XML Line 003435:82found attribute "format",​ but no attributes allowed here
2
XML Line 003436:217element "link" missing required attribute "target"
2
XML Line 003436:82found attribute "format",​ but no attributes allowed here
2
XML Line 003438:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003440:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003442:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003444:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003449:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003451:144found attribute "format",​ but no attributes allowed here
2
XML Line 003454:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003457:295found attribute "format",​ but no attributes allowed here
2
XML Line 003458:97found attribute "format",​ but no attributes allowed here
2
XML Line 003460:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003463:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003466:295found attribute "format",​ but no attributes allowed here
2
XML Line 003467:97found attribute "format",​ but no attributes allowed here
2
XML Line 003469:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003475:102attribute "unnumbered" not allowed here; expected attribute "id", "normative" or "obligation"
2
XML Line 003476:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003482:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003488:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003490:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003492:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003494:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003499:256attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003501:146found attribute "format",​ but no attributes allowed here
2
XML Line 003502:110found attribute "format",​ but no attributes allowed here
2
XML Line 003504:207element "link" missing required attribute "target"
2
XML Line 003504:51found attribute "format",​ but no attributes allowed here
2
XML Line 003508:206element "link" missing required attribute "target"
2
XML Line 003508:51found attribute "format",​ but no attributes allowed here
2
XML Line 003512:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003515:294found attribute "format",​ but no attributes allowed here
2
XML Line 003516:97found attribute "format",​ but no attributes allowed here
2
XML Line 003517:97found attribute "format",​ but no attributes allowed here
2
XML Line 003518:97found attribute "format",​ but no attributes allowed here
2
XML Line 003519:97found attribute "format",​ but no attributes allowed here
2
XML Line 003520:97found attribute "format",​ but no attributes allowed here
2
XML Line 003521:97found attribute "format",​ but no attributes allowed here
2
XML Line 003522:97found attribute "format",​ but no attributes allowed here
2
XML Line 003523:97found attribute "format",​ but no attributes allowed here
2
XML Line 003524:97found attribute "format",​ but no attributes allowed here
2
XML Line 003525:97found attribute "format",​ but no attributes allowed here
2
XML Line 003527:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003529:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003532:294found attribute "format",​ but no attributes allowed here
2
XML Line 003533:97found attribute "format",​ but no attributes allowed here
2
XML Line 003534:97found attribute "format",​ but no attributes allowed here
2
XML Line 003535:97found attribute "format",​ but no attributes allowed here
2
XML Line 003536:97found attribute "format",​ but no attributes allowed here
2
XML Line 003537:97found attribute "format",​ but no attributes allowed here
2
XML Line 003538:97found attribute "format",​ but no attributes allowed here
2
XML Line 003539:97found attribute "format",​ but no attributes allowed here
2
XML Line 003540:97found attribute "format",​ but no attributes allowed here
2
XML Line 003542:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003558:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003560:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003565:144attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003566:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003568:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003570:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003575:144found attribute "format",​ but no attributes allowed here
2
XML Line 003577:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003579:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003581:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003584:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003586:168found attribute "format",​ but no attributes allowed here
2
XML Line 003589:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003591:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003593:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003598:146found attribute "format",​ but no attributes allowed here
2
XML Line 003600:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003602:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003604:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003607:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003609:170found attribute "format",​ but no attributes allowed here
2
XML Line 003612:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003614:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003616:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003621:146found attribute "format",​ but no attributes allowed here
2
XML Line 003622:112found attribute "format",​ but no attributes allowed here
2
XML Line 003623:112found attribute "format",​ but no attributes allowed here
2
XML Line 003624:110found attribute "format",​ but no attributes allowed here
2
XML Line 003625:110found attribute "format",​ but no attributes allowed here
2
XML Line 003627:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003629:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003631:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003634:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003636:170found attribute "format",​ but no attributes allowed here
2
XML Line 003637:128found attribute "format",​ but no attributes allowed here
2
XML Line 003638:128found attribute "format",​ but no attributes allowed here
2
XML Line 003639:126found attribute "format",​ but no attributes allowed here
2
XML Line 003640:126found attribute "format",​ but no attributes allowed here
2
XML Line 003643:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003645:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003647:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003652:146found attribute "format",​ but no attributes allowed here
2
XML Line 003653:112found attribute "format",​ but no attributes allowed here
2
XML Line 003655:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003657:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003659:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003662:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003664:170found attribute "format",​ but no attributes allowed here
2
XML Line 003665:128found attribute "format",​ but no attributes allowed here
2
XML Line 003668:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 003672:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003674:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003676:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003678:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003684:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003686:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003688:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003690:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003693:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003697:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003699:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003701:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003706:144found attribute "format",​ but no attributes allowed here
2
XML Line 003708:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003710:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003712:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003715:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003717:168found attribute "format",​ but no attributes allowed here
2
XML Line 003720:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003722:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003724:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003730:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003732:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003734:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003737:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003741:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003743:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003745:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003751:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003753:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003755:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003758:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003762:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003764:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003766:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003772:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003774:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003776:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003779:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003783:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003785:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003787:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003792:146found attribute "format",​ but no attributes allowed here
2
XML Line 003794:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003796:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003798:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003801:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003803:170found attribute "format",​ but no attributes allowed here
2
XML Line 003806:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003808:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003810:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003812:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003818:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003820:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003822:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003824:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003827:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003831:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003833:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003839:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003841:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003844:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003848:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003850:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003852:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003857:146found attribute "format",​ but no attributes allowed here
2
XML Line 003859:75attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003861:74attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003863:68attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003866:293attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 003868:170found attribute "format",​ but no attributes allowed here
2
- diff --git a/sources/document.html b/sources/document.html deleted file mode 100644 index 93b9701..0000000 --- a/sources/document.html +++ /dev/null @@ -1,4223 +0,0 @@ - - -The ModSpec Model - A Standard for Designing and Writing Modular Standards - - - - - - - - - - - - - - - - - - - - - - -
-

Draft

-
- -
-

OGC Draft Standard

-
- - - -
- -
- - -
-
- -
- -
- The ModSpec Model - A Standard for Designing and Writing Modular Standards - -
-
- - - - - -
- - - - - - - Carl Reed, John Herring Editor - - -
- - - -
- - Version: 1.1.0
- - -
- -
- -
- -
-
- OGC Draft Standard -
- -
-

Draft

-
-
- -
- -
- - - -
- - - - - - -
Document number:08-131r3
Document type:OGC Draft Standard
Document subtype:Conceptual Model
Document stage:Draft
Document language:English
-
- -
- - -
-
-
-

-
- -

License Agreement

- -

Use of this document is subject to the license agreement at https://www.ogc.org/license

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

- - - - - -
- -
-


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

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:

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

NOTE 1:    Reading the Terms and Definitions clause will help understanding the content and -requirements stated in this document.

This OGC document, also known as the ModSpec:

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.

XI.  Acknowledgements

The following OGC Members were key contributors to Version 1 of the ModSpec

Table 1

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

    -
  2. -
  3. Standards using UML to state requirements, extending the core — see -Clause 9.2.2 and Annex A.2

    -
  4. -
  5. Standards using XML schema to state requirements, extending the core — see -Clause 9.2.3 and Annex A.3

    -
  6. -
  7. Standards using Schematron to state requirements, extending XML schema — see -Clause 9.2.4 and Annex A.4

    -
  8. -
  9. 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 9.2.5 and Annex A.5.

    -
  10. -

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:

The various subclauses of Clause 9 list requirements partially derived from the -core, but more specific to the conditions where a data model expressed in one of the -specified languages (UML or XML) is involved. These requirements classes are -extensions of the core presented in [cls-6].

3.  Normative references

-

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

- - - - -

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

- - -

For the purposes of this document, the following terms and definitions shall apply. -Terms not defined here take their meaning from computer science or from their -Standard English (common US and UK) meanings. The form of the definitions is -defined by ISO Directives.

- -

Many of these definitions depend upon the model given in [cls-6-1].

- - -

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

- - -

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

- -

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

- - -

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 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.7. conformance test class

conformance test level ALTERNATIVE

- - - -

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 (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.8. conformance suite

conformance test suite ALTERNATIVE

abstract test suite ALTERNATIVE

- - - - - -

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

- -

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)

- - -

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

- -

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

- - - - - -

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

-

uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more -of a “statement of fact” than a “normative” condition.

- - -

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), -conforming subsets, options and parameters of those base standards, or -profiles necessary to accomplish a particular function.

- - - - -

Note 1 to entry: In the usage of this Policy, a profile will be a set of requirements classes -or conformance classes (either preexisting or locally defined) of the base -standards.

This means that a standardization target (Clause 4.26) being conformant to a profile -implies that the same target is conformant to the standards referenced in the -profile (Clause 4.19).

[SOURCE: ISO/IEC 10000-1]

- -

4.20. recommendation

-

expression in the content of a standard conveying that among several -possibilities one is recommended as particularly suitable, without mentioning or -excluding others, or that a certain course of action is preferred but not -necessarily required, or that (in the negative form) a certain possibility or -course of action is deprecated but not prohibited

- - - - - - -

Note 1 to entry: Although using normative language, a recommendation (Clause 4.20) 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 -conditional).

Note 2 to entry: Recommendations are not tested and therefor have no related conformance test.

[SOURCE: ISO/IEC DIR 2]

- -

4.21. requirement

-

expression in the content of a standard conveying criteria to be fulfilled if -compliance with the standard is to be claimed and from which no deviation is permitted

- - - - -

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

- - -

Note 1 to entry: There is some confusion possible here, since the testing of indirect -dependencies seems to violate this definition. But the existence of an indirect -dependency implies that the test is actually a test of the existence of the -relationship from the original target to something that has a property -(satisfies a condition or requirement from another requirements class).

- -

4.23. requirements module

-

collection of term requirement class, display requirements classes not resolved via ID requirement-class, -recommendations (Clause 4.20) and permissions (Clause 4.18) with a -single standardization target (Clause 4.26)

- - -

4.24. specification

-

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

- - -

Note 1 to entry: This definition is included for completeness. See Clause 6.4.

This does not restrict what else a standard may contain, as long as it does -contain the three types of element cited.

- -

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

- -

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

- - -

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.

- -

4.28. statement

-

expression in a document conveying information

- - - - -

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

6.1.  Symbols (and abbreviated terms)

- -

All symbols used in this document are either:

- -
  1. Common mathematical symbols

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

6.2.  Identifiers

- -

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

- -

http://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.

- -

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

- -

http://www.opengis.net/spec/modspec/1.1

- -

An example might be:

- -

/req/core/crs

- -

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

- -

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

- -

http://www.opengis.net/spec/modspec/1.1/

- -

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

-

6.3.  Abbreviated terms

- -

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

- -

ERA

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

-

ISO

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

-

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

-
-

6.4.  Finding requirements and recommendations

- -

Each normative statement in the ModSpec is stated in one and only one place, -in a standard format, and has 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 abstract test suite -in Annex A. The reference to the requirement in the test case is done by a -requirements label (in the form “Req #”, where “#” is a number) associated to -the home of the statement described above. 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 -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.

-

7.  Fundamentals

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

    -
  4. -
  5. All requirements, recommendations, permissions, and models are introduced and defined first in -the numbered Clauses.

    -
  6. -
  7. All requirements are identifiable as requirements.

    -
  8. -
  9. All requirements in a document are uniquely numbered.

    -
  10. -
  11. All tests for conformance to those requirements are defined in the Conformance Test Suite.

    -
  12. -
  13. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.

    -
  14. -
  15. The tests, if conducted, determine to some degree of certainty whether an -implementation meets the requirements which the tests reference.

    -
  16. -
  17. 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”.

    -
  18. -
  19. Certificates of conformance (see Clause 4.1) are -awarded by a testing entity based on these conformance classes.

    -
  20. -
  21. There is a clear distinction between normative and informative parts of the text.

    -
  22. -
  23. Examples and notes are informative, and do not use “normative” -language.

    -
  24. -
- -

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

-

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

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

    -
  • -
-

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

- -

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. -
  3. A building block may interoperate with other, inter-dependent, building blocks.

    -
  4. -
  5. A good building block has the following characteristics:

    -
    1. Considers implementation and usage, and evolves to exploit technology and standards.

      -
    2. -
    3. May be assembled from other building blocks.

      -
    4. -
    5. May be a subassembly of other building blocks.

      -
    6. -
    7. Ideally a building block is re-usable and replaceable, and well specified.

      -
    8. -
    -
  6. -
  7. A building block may have multiple implementations but with different inter-dependent building blocks.

    -
  8. -
- -

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.4.  Standardization Context — Goals and Targets

- -

Every OGC Standard shall include a Standardization Goal. This is a concise statement of the problem that the Standard will help 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: -• 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 – 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 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 our 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.5.  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 8.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 2 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 14 and Table 15.

-

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

-

8.1.  Using the model

- -

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 -must model the standardization target to which they apply since they need to use -unambiguous language to specify requirements. Thus, the only thing they have in -common is that they define testable requirements against some -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 -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 -standard, leading to issues of separate interpretations of the same standard.

- - - -

The assumption is that each standard has a single -(root) standardization target type from which all extensions inherit. If this is not -true, then the standard can be logically factored into parts each corresponding -to a “root” standardization target type, and that the standard addresses each -such part separately (see the definition of requirements class in -Clause 4.22). In this sense, the next requirement divides -standard into parts more than restricting their content.

- -

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 -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 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 -tested for a particular certificate of conformance. The test may specify other types -as intermediaries or indirect dependencies (see -Clause 4.11).

- -

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 -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 -for data transmission. Since the client and server are different standardization -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 -common alternative is to introduce a new “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.
- -
- -

Figure 1 — Abstract superclass example

- -

Example — Abstract Superclass

- -
-

8.2.  The “standards” document

- -

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

- -

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

-

8.3.  Conformance Test Suite

- -

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 -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, -types, elements, or objects are defined and segregated into implementation -requirements 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.

-

8.4.  Requirements for Modularity

- -

8.4.1.  Each Conformance class tests a complete requirements class

- -

Table 17

REQ009/req/core/no-optional-tests
-A Conformance class SHALL not contain any optional conformance tests.
- -

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 18

PER007/per/core/conf-class-paramterized
-A Conformance class may be parameterized.
- -

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

- -

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 -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 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 -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 -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 -compliant to a particular profile of GML, then that profile of GML will be used to -validate that output. This means that the service is indirectly tested using the GML -standard. In other words, GML is an indirect dependency of the original service.

-
- -

Requirements classes may be optional as a whole, but not piecemeal. This means that -every implementation that passed a particular conformance class satisfies exactly -the same requirements and passes exactly the same conformance tests. Differences -between implementations will be determined by which conformance test classes are -passed, not by listing of which options within a class were tested. If a -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 -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 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 -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 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 -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.4.2.  Requirements classes contain all requirements tested by a conformance test case

- -

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 -class, it cannot be considered a requirement since no test has been defined for it.

- -

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 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 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 -poor design, but they often cannot be avoided because of other considerations (code -ownership for example).

- -

Table 27

REC003/rec/core/circular-dependencies
-Circular dependencies of all types should be avoided whenever possible.
- -

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

- - - -

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 -standardization target). Implementors who wish to sacrifice modularity for some -other benefit can still do what they want; the requirement here only states that if -the software requirements classes are properly separated, they can be implemented in -a “plug’n’play” fashion.

- -

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 -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 -or type) are all acceptable, redefinition (of an old class or type) is not.

- -

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 -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.4.3.  Profiles are defined as sets of conformance classes

- -

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 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.4.4.  There is a Defined Core

- -

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 32

REQ021/req/core/requirements-and-dependencies
-All general recommendations SHALL be in the core.
- -

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 34

REC004/rec/core/simple-core
-The core SHOULD be as simple as possible.
- -

Table 35

PER008/per/core/core-type
-The core MAY be partially or totally abstract.
- -

Table 36

PER009/per/core/req-class-another-standard
-The core requirements class MAY be a conformance class in another standard.
- -

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

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

- - -
- -

8.4.5.  Extensions are requirements classes

- -

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

- -

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

- -

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 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 -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 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 -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 -standardization targets to behave in a certain manner when presented with a logical -inconsistency, but that inconsistency must be fundamental to the internal logic of -the model, and not a possible extension. Thus, a standard may require a -standardization target to accept GML as a feature specification language, but cannot -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.4.6.  Optional requirements are organized as requirements classes

- -

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 -they are required by the schema or not.

- - - -

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.4.7.  Requirements classes intersect overlap only 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 -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 -conformance test class contains tests that all other conformance classes must pass.

- - -
-

9.  Mapping this standard to types of models

9.1.  Semantics

- -

The previous section defines requirements for conformance to the ModSpec, but -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 -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].

- -

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.

-

9.2.  Data Models

- -

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

-
- -

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

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 45

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 46

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 47

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 48

REQ031/req/core/uml/leaf-model
-A UML leaf package SHALL be associated directly to only one requirements class.
- -

Table 49

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 50

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 51

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 33, 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 52

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

- -

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.

- -

Requirement 3

Statement

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

-
- -

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

-
- -

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.

- - - -

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

- -

Requirements may add constraints. This allows extensions to restrict:

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

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

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.

-
- -

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

- -

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:

- -

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

-
- -

9.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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 2

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 3

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 8

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 10

    -
  6. -
  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 -standard shall have the same standardization target.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 11

    -
  6. -
  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 -document in a strictly hierarchical manner, consistent with requirements modules and -requirements classes.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Clause 8.2, Table 14

    -
  6. -
  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 test suite structure.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Clause 8.2, Table 15

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 16

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

A.1.9.  No Optional Elements in Requirements classes

- -

A Conformance class shall not contain any optional conformance tests.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 17

    -
  6. -
  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 -tests in its conformance test class.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 19

    -
  6. -
  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 -requirements class.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 20

    -
  6. -
  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 -dependent and that other conformance class shall be used to test the specified -dependency.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 21

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 22

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

A.1.14.  Naming consistency

- -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 23

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 24

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 26

    -
  6. -
  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 -implemented on top of any implementations of its dependencies and independent of its -extensions.

- -

All general recommendations shall be in the core.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 28

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

A.1.18.  Requirements follow rules of inheritance

- -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 29

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 30

    -
  6. -
  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 -separate conformance class.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 31

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 33

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 33

    -
  6. -
  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 -number of requirements classes defined as extensions to that core.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 39

    -
  6. -
  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 -to itself to be conformant to the ModSpec.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 40

    -
  6. -
  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 -future, logically-valid extensions of its standardization targets.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 41

    -
  6. -
  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 -standard shall be expressible as a list of conformance classes to be passed.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 42

    -
  6. -
  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 -to other requirements classes.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 43

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 45

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 46

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 47

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 48

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 49

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 50

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 51.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 52.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 1.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 2

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 3

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 4

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 5

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 6

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 7

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 8

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 9

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 10

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 11

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 12

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 13

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 14

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 15

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 16

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 17

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

- -

Any new standard, specification, or major revision of an existing standard SHALL -comply with the ModSpec in the structure of its internal models and its -conformance tests.

- -

Failure to conform by a candidate standard to the ModSpec should be specifically -noted and reasons given for such non-compliance in the conformance clauses of any -new or new version of such candidate standards.

- -

The adoption of such documents not compliant with the ModSpec shall be -considered as an authorized exception to the requirements of the ModSpec by the -approporiate authority, such as the OGC or ISO. The adoption of such -documents not compliant with the ModSpec shall be considered as an exception to -the requirements of the ModSpec by the authority (OGC) and shall be considered as an exception -to the rules of the authority such as the OGC and will require a two-thirds (2/3) majority (“Robert’s -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 Planning Committee or as specified -in any Policy and Procedure document used by this committee.

-

Annex C
(informative)
Definitions

C.1.  Semantically ordered definitions

- -

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 -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. -
  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. -
  5. a conformance test (Clause 4.4) 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.

    -
  6. -
  7. all conformance tests (Clause 4.4) are graded as pass or fail -against each instance of the standardization target (Clause 4.26).

    -
  8. -
  9. a requirement (Clause 4.21) is associated to one conformance test (Clause 4.4).

    -
  10. -
  11. a recommendation (Clause 4.20) is a suggestion and is not associated to any -conformance test (Clause 4.4).

    -
  12. -
  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. -
  15. a conformance (test) class (Clause 4.7) is a collection of -conformance tests (Clause 4.4) that are associated to and only to the -requirements in a corresponding requirements class (Clause 4.22).

    -
  16. -
  17. a conformance (test) module (Clause 4.6) 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 -standardization target type (Clause 4.27).

    -
  18. -
  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.7) and received a certificate of conformance (Clause 4.3)

    -
  20. -
  21. the core requirements class (Clause 4.9) 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. -
  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) -must identify all its dependencies during the execution of conformance tests -against a candidate standardization target (Clause 4.26).

    -
  24. -
-

C.2.  UML Model

- -
- -

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

-

C.3.  Specification

- -

C.4.  Specification

- -

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 -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 -tested and the conformance classes are the containers for these tests’ -definition. The requirements classes will 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. -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.9.  RequirementsClass

- -

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

- -

A requirements modules (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 -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

- -

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

- -

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

- -

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 -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 -logical designs that may implement the requirements in the same module.

    -
  • -
- -

Regardless of their use, Recommendations are not tested since they are not -required of all conformant implementations.

-

C.18.  Conformance test

- -

C.19.  ConformanceTest

- -

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

- -

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

- -

Bibliography

- -

To preserve a unique numeric identifier for all documents listed as references in -this standard, the numbering of references in this annex is continued from the list -of normative reference in 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/.

- - - - - - - - - -

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.

- - - - - - - - - - - - - - - - -
-
- - - - - - - - - - - - - - - - - - - diff --git a/sources/document.pdf b/sources/document.pdf deleted file mode 100644 index ddf2901..0000000 Binary files a/sources/document.pdf and /dev/null differ diff --git a/sources/document.pdf.err b/sources/document.pdf.err deleted file mode 100644 index a9f5064..0000000 --- a/sources/document.pdf.err +++ /dev/null @@ -1,7 +0,0 @@ -Page xi: Unresolved ID reference "cls-6" found. -Page 2: Unresolved ID reference "Annex-B" found. -Page 4: Unresolved ID reference "cls-6" found. -Page 8: Unresolved ID reference "cls-6-1" found. -Page 22: Unresolved ID reference "annex-B-2" found. -Page 41: Unresolved ID reference "cls-6-1" found. -Page 72: Unresolved ID reference "cls-6-1" found. diff --git a/sources/document.presentation.xml b/sources/document.presentation.xml deleted file mode 100644 index b2cac6c..0000000 --- a/sources/document.presentation.xml +++ /dev/null @@ -1,7373 +0,0 @@ - - - -The ModSpec Model - A Standard for Designing and Writing Modular Standards -08-131r308-131r32029-11-012029-11-012024-11-16 -TBD - -Carl Reed, John Herring - -Open Geospatial Consortium -OGC1.1.0enDraft2024 -Open Geospatial Consortium -OGCdraft-standardconceptual-modeltechnicalScopeSymbols and abbreviated termsAbbreviated termsSymbolsContentsIntroductionPrefaceAbstractAcknowledgementsTerms and definitionsTerms, definitions, symbols and abbreviated termsTerms, definitions and symbolsTerms, definitions and abbreviated termsNormative referencesBibliographyPrefaceSectionClauseAnnexAppendixcontinued

No terms and definitions are listed in this document.

-

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

-

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

-

For the purposes of this document, the following additional terms and definitions apply.

-
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.There are no normative references in this document.

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

-

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

-

For the purposes of this document, the terms and definitions given in % additionally apply.

-

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

-

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

-

For the purposes of this document, the terms and definitions given in % and the following additionally apply.

-
[NO INFORMATION AVAILABLE](%)%1 and %2%1, and %2%1 or %2%1, or %2%1 and %2%1 or %2%1 from %2%1 to %2%1, %2%1 %2spellout-ordinaldigits-ordinalNOTENoteNote % to entryListDefinition ListFigureDiagramFormulaFormulaTableRequirementRecommendationPermissionBoxRecommendation testRequirement testPermission testRecommendations classRequirements classPermissions classAbstract testConformance classKeyExampleExamplewherewhereWhole of textdraftinformativenormativemodifiedadaptedDEPRECATEDSOURCEandAll Parts{{ var1 | ordinal_word: '', '' }} editioneditionversionList of FiguresList of TablesList of RecommendationsJanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberObligationDangerWarningCautionImportantSafety PrecautionsEditorial NoteSectionClausePartParagraphChapterPageTableAnnexFigureExampleNoteFormulamfncommonsgdualplpreppartadjadvnounverbdeprecatessupersedesnarrowerbroaderequivalentcomparecontrastseesee alsoClauseClausesAnnexAnnexesAppendixAppendixesNoteNotesNote % to entryNotes % to entryListListsFigureFiguresFormulaFormulasTableTablesRequirementRequirementsRecommendationRecommendationsPermissionPermissionsExampleExamplesPartPartsSectionSectionsParagraphParagraphsChapterChaptersPagePagesALTERNATIVESubmittersContributorsRevision historyTable of FiguresNo security considerations have been made for this document.Submission DateApproval DatePublication DateAuthorEditorContributorDraftWork Item DraftCandidate SWG DraftCandidate OAB Review DraftCandidate Public RFC DraftCandidate TC Vote DraftApprovedPublishedDeprecatedRescindedRetiredenLatn
TOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2 - -The ModSpec Model - A Standard for Designing and Writing Modular Standards -08-131r308-131r32029-11-012029-11-012024-11-16 -TBD - -Carl Reed, John Herring - -Open Geospatial Consortium -OGC1.1.0enLatnDraft2024 -Open Geospatial Consortium -OGCdraft-standardconceptual-modeltechnicalTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2 - - - -Copyright notice -Copyright © 2024 Open Geospatial Consortium -To obtain additional rights of use, visit - - - - -Note -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 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. - - - - - - -License Agreement -Use of this document is subject to the license agreement at - - - - - - -Notice -This document is not an OGC Standard. This document is an OGC Draft Standard and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. - -Further, an OGC Draft Standard should not be referenced as required or mandatory technology in procurements. - - - - - - - -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.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. -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 -() or by creating an issue in the GitHub repository for this document (). - -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. - -Document editors -The following OGC Members participated in editing this document: - -Person -Organization Represented -Carl Reed -Carl Reed & Associates - - - -Document Contributors -The following OGC Members contributed and particpated in developing Version 2 of the ModSpec. - -Person -Organization Represented -Simon Cox -CSIRO and OGC Fellow -Chuck Heazel -Heazeltech -Clemens Portele -interactive instruments GmbH -Jeff Yutzler -ImageMatters - - - -Revision history -This is the second normative version of this document. - -Future work -Improvements to this document will be made based on implementation and changing technical requirements. Planned extensions include: - -ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL. - -ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using JSON. - - - -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, -and the Conformance Test Suite ). - -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. - -Introduction -Reading the Terms and Definitions clause will help understanding the content and -requirements stated in this document. - - -This OGC document, also known as the ModSpec: - -Specifies rules for the internal structure and organization of a standard. - -Defines requirements for specifying the structure of a standards document as organized sets of criteria, those that are to be tested (“requirements”) and those that are not tested (“recommendations” and “permissions”). - -Designed to enable the clear and concise specification of requirements (the shalls or musts in a standard) that fully supports the ability to define implementable conformance tests. - - - -The goal of this approach is to enable implementations of a standard to be tested and deemed conformant or not.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. - -Acknowledgements -The following OGC Members were key contributors to Version 1 of the ModSpec - -Simon Cox -CSIRO -David Danko -ESRI -James Greenwood -SeiCorp, Inc. -John R. Herring -Oracle USA -Andreas Matheus -University of the Bundeswehr — ITS -Richard Pearsall -US National Geospatial-Intelligence Agency (NGA) -Clemens Portele -interactive instruments GmbH -Barry Reff -US Department of Homeland Security (DHS) -Paul Scarponcini -Bentley Systems, Inc. -Arliss Whiteside -BAE Systems — C3I Systems - - - - Security considerations - No security considerations have been made for this document. - - - - - - - - - - - - - - - - - -Scope -The ModSpec defines characteristics and structure for the specification of Standards -that will encourage implementation by minimizing difficulty determining -requirements, mimicking implementation structure and maximizing usability and -interoperability.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. - - - - - defines the UML model upon which the ModSpec is -based. Annex B 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. - - - -Conformance -Conformance to the ModSpec by technical implementation standards -can be tested by inspection. The test suite is in . - -There are five (5) conformance classes for this document: - -Standards documents in general (the core) — see and - -Standards using UML to state requirements, extending the core — see - and - -Standards using XML schema to state requirements, extending the core — see - and - -Standards using Schematron to state requirements, extending XML schema — see - and - -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 and . - - - -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: - - specifies the core requirements which shall be met by all conformant -standards. - - gives information on how the ModSpec is to be applied to requirements, -conformance clauses, UML models, or XML Schemas. - - - -The various subclauses of list requirements partially derived from the -core, but more specific to the conditions where a data model expressed in one of the -specified languages (UML or XML) is involved. These requirements classes are -extensions of the core presented in . - - - - - -Terms and definitions - -For the purposes of this document, the following terms and definitions shall apply. -Terms not defined here take their meaning from computer science or from their -Standard English (common US and UK) meanings. The form of the definitions is -defined by ISO Directives. - -Many of these definitions depend upon the model given in . - - - -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 - - - -building block - - -a requirements class or a requirements module and their associated compliance test class or compliance test module. - - - -certificate of conformance - - -evidence of conformance to all or part of a standard, awarded for passing one or -more of the conformance test classconformance test classes specified in -that standard - - - “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 . - -Each certificate of conformance is awarded to a standardization targetstandardization target. - - - -conformance test - - -test, abstract or real, of a single requirementrequirements contained -within a standard, or set of standards - - - -conformance test case - - -test for a particular requirement or a set of related requirements - - - When no ambiguity, the word “case” may be omitted. i.e. -conformance testconformance test is the same as -conformance test caseconformance test case. - - - -conformance test module - - -set of related for against a given requirements module all with the same standardization target - - - - - When there is no ambiguity, the word “test” may be omitted. i.e. conformance test moduleconformance test module -is the same as conformance module. Conformance modules may be nested in a hierarchical way. - - - -conformance test class - - -conformance test level - - - - - -set of term conformance tests, display conformance test not resolved via ID conformance-tests that must be passed to receive a single certificate of conformancecertificate of conformance - - - When no ambiguity is possible, the word “test” may be left out, so conformance test classconformance test class -maybe called a conformance class. - -In the ModSpec, the set of requirementrequirements tested by the -conformance tests within a conformance class is a -requirements classrequirements class and its dependencies. Optional requirementrequirements will -be in a separate requirements classrequirements class with other requirementrequirements -that are part of the same option. Each requirements classrequirements class 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 classrequirements class’s requirementrequirements. - -All requirementrequirements in a conformance class -will have the same standardization targetstandardization target. - - - -conformance suite - - -conformance test suite - - -abstract test suite - - - - - - - -set of conformance classes that define tests for all requirementrequirements of a standard or abstract specification - - - The conformance suiteconformance suite 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 requirementrequirement is mandatory within its conformance class and each requirementrequirement is tested in at least one conformance testconformance test. - - - -core requirements class - - -unique requirements classrequirements class that must be satisfied by any conformant -standardization targetstandardization targets associated to the -standard - - - The core requirements classrequirements 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 classconformance test class, and thus would have to be contained in any other -core. The core may be empty, or all or part of another standard or related -set of standards. - -The “core” can refer to this requirements classrequirements class, its associated -conformance test classconformance test class or the software module that implements that -requirements class. - - - -direct dependency (of a requirements class) - - -another requirements classrequirements class (the dependency) whose requirementrequirements are defined to also be -requirementrequirements of this -requirements classrequirements class - - - A direct dependency (of a requirements class) direct dependency -of the current requirements classrequirements class will have the same -standardization targetstandardization target as the current -requirements classrequirements class. This is another ways of saying that the current -requirements classrequirements class extends, or uses all the aspects of the -direct dependency (of a requirements class) direct dependency. -Any tests associated with this -direct dependency (of a requirements class)dependency can be applied to this -requirements classrequirements class. - -When testing a -direct dependency (of a requirements class) direct dependency, the -standardization targetstandardization target is directly subject to the test in the specified -conformance test classconformance test class of the direct dependency (of a requirements class) direct dependency. - - - -indirect dependency (of a requirements class) - - -requirements classrequirements class with a different -standardization targetstandardization target which is used, produced or associated to by the -implementation of this requirements classrequirements class - - - In this instance, as opposed to the -direct dependency (of a requirements class)direct dependency, -the test against the consumable or product used -or produced by the requirements classrequirements class does not directly test the -requirements classrequirements class, but tests only its side effects. Hence, a particular -type of feature service could be required to produce valid XML documents, but -the test of validity for the XML document is not directly testing the service, -but only indirectly testing the validity of its output. -direct dependency (of a requirements class) Direct dependencies -test the same standardization targetstandardization target, but -indirect dependency (of a requirements class) indirect dependencies -test related but different standardization targetstandardization 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 conformancecertificate of conformance of a particular kind. - - - -extension (of a requirements class) - - -requirements classrequirements class which has a -direct dependency (of a requirements class) direct dependency on another -requirements classrequirements class - - - Here extension (of a requirements class)extension is -defined on requirements classrequirements class so that their implementation may be -software extensions in a manner analogous to the extension relation between the -requirements classrequirements classes. - - - -general recommendation - - -recommendation applying to all entities in a standard - - - -home (of a requirement or recommendation) - - -official statement of a requirementrequirement or recommendationrecommendation that is the -precedent for any other version repeated or rephrased elsewhere in a standard - - - 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. - - - -model - - -abstract model - - -conceptual model - - - - - - - -theoretical construct that represents something, with a set of variables and a -set of logical and quantitative relationships between them. - - - -module - - -one of a set of separate parts that can be joined together to form a larger object - - - - -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. - - - -permission - - -uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more -of a “statement of fact” than a “normative” condition. - - - -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 classconformance test classes, -conforming subsets, options and parameters of those base standards, or -profiles necessary to accomplish a particular function. - - - - - In the usage of this Policy, a profile will be a set of requirements classes -or conformance classes (either preexisting or locally defined) of the base -standards. - -This means that a standardization targetstandardization target being conformant to a profile -implies that the same target is conformant to the standards referenced in the -profileprofile. - - - -recommendation - - -expression in the content of a standard conveying that among several -possibilities one is recommended as particularly suitable, without mentioning or -excluding others, or that a certain course of action is preferred but not -necessarily required, or that (in the negative form) a certain possibility or -course of action is deprecated but not prohibited - - - - - - - Although using normative language, a recommendationrecommendation is not -a requirementrequirement. The usual form replaces the “shall” (imperative or -command) of a requirementrequirement with a “should” (suggestive or -conditional). -Recommendations are not tested and therefor have no related conformance test. - - - -requirement - - -expression in the content of a standard conveying criteria to be fulfilled if -compliance with the standard is to be claimed and from which no deviation is permitted - - - - - Each requirementrequirement is a normative criterion for a single -type of standardization target. In the ModSpec, requirements are -associated to conformance test conformance tests that can be used to prove -compliance to the underlying criteria by the standardization targetstandardization target. - -The implementation of a requirementrequirement 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 requirementrequirements allows us to -use set descriptions of both the standard and its implementations. - -requirementRequirements 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. - - - -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 classconformance test class - - - There is some confusion possible here, since the testing of indirect -dependencies seems to violate this definition. But the existence of an indirect -dependency implies that the test is actually a test of the existence of the -relationship from the original target to something that has a property -(satisfies a condition or requirement from another requirements class). - - - -requirements module - - -collection of term requirement class, display requirements classes not resolved via ID requirement-class, -recommendationrecommendations and permissionpermissions with a -single standardization targetstandardization target - - - -specification - - -document containing recommendationrecommendations, -requirementrequirements and conformance test conformance tests for -those requirementrequirements - - - This definition is included for completeness. See . - -This does not restrict what else a standard may contain, as long as it does -contain the three types of element cited. - - - -standard - - -document that has been approved by a legitimate Standards Body - - - This definition is included for completeness. standardStandard and -specificationspecification can apply to the same document. While specificationspecification is -always valid, standardstandard only applies after the adoption of the document by a -legitimate standards organization. - - - -standardization target - - -entity to which some requirementrequirements of a standardstandard apply - - - - - The standardization targetstandardization target is the entity which may receive a -certificate of conformancecertificate of conformance for a requirements classrequirements class. -Need to add examples! The standardization target of the CDB version 2.0 CRS Requirements Classes is to ensure that an implementation clearly defines (with metadata) the CRS for a CDB compliant datastore. - - - -standardization target type - - -type of entity or set of entities to which the requirementrequirements of a -standardstandard apply - - - 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. - - - -statement - - -expression in a document conveying information - - - - - Includes all statements in a document not part of the normative -requirementrequirements, -recommendationrecommendations or -conformance test conformance tests. Included for completeness. - - - - -Conventions - -Symbols (and abbreviated terms) -All symbols used in this document are either: - -Common mathematical symbols - -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. - - - - - -Identifiers -The normative provisions in this standard are denoted by the URI namespace - - - -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: - - - -An example might be: - -/req/core/crs - -All conformance tests that appear in this document are denoted by partial URIs which are relative to the namespace shown above. - -For the sake of brevity, the use of “conf” in a requirement URI denotes: - - - -The same convenstion is used for permissions (per) and recommendations (rec). - - - -Abbreviated terms -In this document the following abbreviations and acronyms are used or introduced: - -ERAEntity, Relation, Attribute (pre-object modeling technique) - -ISOInternational Organization for Standardization (from Greek for “same”) - -OCLObject Constraint Language (part of UML) - -OGCOpen Geospatial Consortium () - -OMGObject Management Group () - -OOPObject Oriented Programming - -OOPLOOP Language (such as C++ or Java) - -SQLISO/IEC 9075 query language for relational databases, not originally an acronym, but now often cited as “Structured Query Language” - -TCTechnical Committee (usually either in ISO or OGC) - -UMLUnified Modeling Language (an object modeling language) - -XMLeXtensible Markup Language - - - -Finding requirements and recommendations -Each normative statement in the ModSpec is stated in one and only one place, -in a standard format, and has 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 abstract test suite -in . The reference to the requirement in the test case is done by a -requirements label (in the form “Req #”, where “#” is a number) associated to -the home of the statement described above. 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 -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. - - - - -Fundamentals - -The ModSpec and the “Form” of a standard -For OGC Standards, the assumptions is that documents are in a commonly used -logical form (template). - - -This form should be specified by the following descriptions: - -A standards document contains Clauses (corresponding to numbered sections as they might -appear in a table of contents) which describe its standardization target and its requirements. - -A standard contains Annexes or is associated to other documents (both a -logical type of Clause), one of which is the Conformance Test Suite (which may be an -abstract description of the test suites to be implemented separately). In OGC Documents, this is Annex A – Abstract Test Suite. - -All requirements, recommendations, permissions, and models are introduced and defined first in -the numbered Clauses. - -All requirements are identifiable as requirements. - -All requirements in a document are uniquely numbered. - -All tests for conformance to those requirements are defined in the Conformance Test Suite. - -Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules. - -The tests, if conducted, determine to some degree of certainty whether an -implementation meets the requirements which the tests reference. - -The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard -does not do this, it is has by default only one “conformance class”. - -Certificates of conformance (see ) are -awarded by a testing entity based on these conformance classes. - -There is a clear distinction between normative and informative parts of the text. - -Examples and notes are informative, and do not use “normative” -language. - - - -In informative sections, the word “will” implies that something is an implication of a requirement. The “will” statements are -not requirements, but explain the consequence of requirements. - -The ModSpec defines a “requirement” of a standard as an atomic testable -criterion. See the formal definition of requirement in - -A UML representation of important properties of this model is given in . - - - -ModSpec document structure -Version 2.0 of the ModSpec is split into a Core standard and multiple Parts. These are: - -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 - - - - - -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: - -A building block is a package of functionality defined to meet business or domain needs. - -A building block may interoperate with other, inter-dependent, building blocks. - -A good building block has the following characteristics: -Considers implementation and usage, and evolves to exploit technology and standards. - -May be assembled from other building blocks. - -May be a subassembly of other building blocks. - -Ideally a building block is re-usable and replaceable, and well specified. - - - -A building block may have multiple implementations but with different inter-dependent building blocks. - - - -These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work.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. - - - - - - -Standardization Context — Goals and Targets -Every OGC Standard shall include a Standardization Goal. This is a concise statement of the problem that the Standard will help 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: -• 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 – 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 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 our standards to quickly understand the scope of a Standard and to select those Standards appropriate for their needs. It also will help keep Standards developers focused on the intended use of their standards, avoiding standards which are overly broad and/or unfocused. - - - -Conformance, Requirements, and key information -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 -). 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 . - -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 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 and . - - - - -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. - -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. - -This further means that failure to pass the test specified for a part of requirement is a -failure to pass the requirement. - - - - -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. - -In the OGC, the enforcement of this requirement and its associated recommendation is the purview of -the OGC Naming Authority or its equivalents. - - - - -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 ) 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. - -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 -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. - -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. - - - -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. - -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. - - - -PER004 -/per/core/external-vocabs-core -Importation of external vocabularies and schemas MAY be in the core. - - - -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. - - - -Using the model -The primary difficulty in speaking about standards (or candidate -standards)This is purposely written as “as not yet adopted” standards, since it is during the authoring process that the ModSpec must be considered, not post facto. - 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 -must model the standardization target to which they apply since they need to use -unambiguous language to specify requirements. Thus, the only thing they have in -common is that they define testable requirements against some -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.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 -standard, leading to issues of separate interpretations of the same standard. - - - - -The assumption is that each standard has a single -(root) standardization target type from which all extensions inherit. If this is not -true, then the standard can be logically factored into parts each corresponding -to a “root” standardization target type, and that the standard addresses each -such part separately (see the definition of requirements class in -). In this sense, the next requirement divides -standard into parts more than restricting their content. - -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 -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. - -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 -tested for a particular certificate of conformance. The test may specify other types -as intermediaries or indirect dependencies (see -). - -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 -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 -for data transmission. Since the client and server are different standardization -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 -common alternative is to introduce a new “superclass”. - -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 . - - - - -Abstract superclass example - - - -Abstract Superclass - - - - -The “standards” document -Each standard document is comprised of a set of requirements and their associated conformance tests. - -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. - - - -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 -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 -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. - - - -Conformance Test Suite -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.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, -types, elements, or objects are defined and segregated into implementation -requirements classes. - -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. - - - -Requirements for Modularity - -Each Conformance class tests a complete requirements class -REQ009 -/req/core/no-optional-tests -A Conformance class SHALL not contain any optional conformance tests. - - - -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. - -PER007 -/per/core/conf-class-paramterized -A Conformance class may be parameterized. - - - -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 -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, -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. - -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. - -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 -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. - -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 -conformance class of another standard. - - -Indirect dependency on schema -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 -compliant to a particular profile of GML, then that profile of GML will be used to -validate that output. This means that the service is indirectly tested using the GML -standard. In other words, GML is an indirect dependency of the original service. - - -Requirements classes may be optional as a whole, but not piecemeal. This means that -every implementation that passed a particular conformance class satisfies exactly -the same requirements and passes exactly the same conformance tests. Differences -between implementations will be determined by which conformance test classes are -passed, not by listing of which options within a class were tested. If a -standard’s authors wish to make a particular requirement optional, -forces them to include it in a separate requirements class (and therefore in a -separate conformance test class) which can be left untested.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. - - - - -REQ013 -/req/core/imported-requirements-class -A -If a requirements class is imported from another standard for use within a -standard conformant to the ModSpec, and if any imported requirement is -“optional,” then that requirement SHALL be factored out as a separate requirements -class in the profile of that imported standard used in the conformant standard. -B -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.# - - - -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. - -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 -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. - - - -Requirements classes contain all requirements tested by a conformance test case -REQ015 -/req/core/req-in-only-one-rec-class -A -Each requirement in the standard SHALL be contained in one and only one -requirements class. -B -Inclusion 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 -class, it cannot be considered a requirement since no test has been defined for it. - -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 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. - -REQ016 -/req/core/co-dependent-requirements -A -If any two requirements are co-dependent (each -dependent on the other) then they shall be in the same requirements class. -B -If 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 -poor design, but they often cannot be avoided because of other considerations (code -ownership for example). - -REC003 -/rec/core/circular-dependencies -Circular dependencies of all types should be avoided whenever possible. - - - -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. - -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 -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 -standardization target). Implementors who wish to sacrifice modularity for some -other benefit can still do what they want; the requirement here only states that if -the software requirements classes are properly separated, they can be implemented in -a “plug’n’play” fashion. - -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 -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 -or type) are all acceptable, redefinition (of an old class or type) is not. - - 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 -purposes. However, it is not possible to write a standard “by example” that -leads to conformance tests. Examples are therefore non-normative, by definition. - - - -Profiles are defined as sets of conformance classes -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 -). The base for creating a profile can be defined as the union of all -requirements classes. - -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. - - - - - -There is a Defined Core -REQ020 -/req/core/core-requirements-separate -Every standard SHALL define and identify a core set of requirements as a -separate conformance class. - - - -REQ021 -/req/core/requirements-and-dependencies -All general recommendations SHALL be in the core. - - - -REQ022 -/req/core/requirements-and-dependencies -A -Every other requirements class in a standard SHALL a standardization -target type which is a subtype of that of the core -B -And every requirement class SHALL have the core as a direct dependency. - - - -REC004 -/rec/core/simple-core -The core SHOULD be as simple as possible. - - - -PER008 -/per/core/core-type -The core MAY be partially or totally abstract. - - - -PER009 -/per/core/req-class-another-standard -The core requirements class MAY be a conformance class in another standard. - - - -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 . - - - -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. - -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. - -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.” - - - - - - -Extensions are requirements classes -A common mechanism to extend the functionality of a standard is to define -extensions, which may be either local or encompass other standards. - -Standards should use extensions as required and feasible, but should never hinder them. - -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. - - - -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 -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. - -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 -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 -standardization targets to behave in a certain manner when presented with a logical -inconsistency, but that inconsistency must be fundamental to the internal logic of -the model, and not a possible extension. Thus, a standard may require a -standardization target to accept GML as a feature specification language, but cannot -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. - - - -Optional requirements are organized as requirements classes -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. - -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 -they are required by the schema or not. - - - - -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. - - - -Requirements classes intersect overlap only by reference -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 -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 .All general recommendations are in the core requirements class. The core -conformance test class contains tests that all other conformance classes must pass. - - - - - - - - -Mapping this standard to types of models - -Semantics -The previous section defines requirements for conformance to the ModSpec, but -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 -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 . - -As suggested in Clause , the structure of the normative clauses in a -standard should parallel the structure of the conformance test classes in -that standard. The structure of the normative clauses in a well written -standard will follow the structure of its model. This means that all three are -parallel. - - - -Data Models - -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 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. -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. - - - -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. - -Requirements Class — UML extension to the core -/req/core/data-representation -Target -ModSpec Conformant UML Model -Dependency -OGC 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. - -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 - - -A will directly -reference the conformance/requirements class associated to another package - - B - - -B, -if and only if - - A - - -A is dependent on - - B - - -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. - -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 - - - -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 - -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 - - -A depends on - - B - - -B, and - - B - - -B -depends on - - C - - -C then - - A - - -A depends on - - C - - -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. - -REQ031 -/req/core/uml/leaf-model -A UML leaf package SHALL be associated directly to only one requirements class. - - - -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. - -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. - -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 -, 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. - -REQ035 -/req/core/uml/source-target -A -In the UML model, if a “source” package is dependent on a “target” package then -their requirements class SHALL be equal or -B -The 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. - - 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. - - - If two packages have a two-way dependency (a “co-dependency”), they SHALL be associated to the same requirements class. - - -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. - - The UML model SHALL segregate all classes into leaf packages. - - - - -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. - - An implementation passing the XML schema conformance test class shall first pass the ModSpec core conformance test class. - - - 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. - - 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. - - - 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. - -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. - - -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. - - 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. - - -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.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. - - - - - 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. - - -Requirements may add constraints. This allows extensions to restrict: - -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. - -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. - - - -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. - - - -Optional Requirements class: Schematron extension to the ModSpec Core -Schematron () 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. - - 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. - - -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 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. - - - Each sch:pattern element shall be contained within one sch:schema element. - - - The value of the sch:schema/@fpi attribute shall be a URI that identifies this implementation - - - 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 - - - The value of the sch:schema/@fpi attribute shall be used on only one Schematron schema. - - - - -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. - - 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. - - 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. - - - - - - - - - - - - - -Abstract Conformance Test Suite - -Conformance Test Class: The Core - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Requirements have a single target -Each requirement in a conformant standard shall have a single standardization -target type. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Conformance test classes have a single target -All conformance tests in a single conformance test class in a conformant -standard shall have the same standardization target. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Requirements are organized by clauses -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: , - -Test Type: Conformance. - - - - - -Conformance test classes are consistent with requirements classes -The requirements structure of the document shall be in a logical correspondence to -the test suite structure. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: , - -Test Type: Conformance. - - - - - -Requirement classes and the Conformance Test classes in correspondence -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -No Optional Elements in Requirements classes -A Conformance class shall not contain any optional conformance tests. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Certificate of conformance specifies all parameters used -A certificate of conformance shall specify all parameter values used to pass the -tests in its conformance test class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Conformance class tests only one requirements class -A Conformance class shall explicitly test only requirements from a single -requirements class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Conformance class specifies all 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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Imported Conformance class tests are consistent with the specification -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Naming consistency -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Requirements in one and only one requirements class -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). - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Co-dependent Requirements are in the same requirements class -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Modularity in implementation is possible -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Requirements follow rules of inheritance -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Profiles are expressed as sets of conformance classes -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -There is a named Core requirements class -Every standard shall define and identify a core set of requirements as a -separate conformance class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -General conditions are in the core -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Every extension has a consistent target type -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -A standard is a core plus some number of extensions -Each standard conformant to the ModSpec shall consist of the core and some -number of requirements classes defined as extensions to that core. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Conformance to this ModSpec is required for any extensions -A standard conformant to the ModSpec shall require all conformant extensions -to itself to be conformant to the ModSpec. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Future extensions cannot be restricted -A standard conformant to the ModSpec shall never restrict in any manner -future, logically-valid extensions of its standardization targets. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Optional requirements are organized as requirements classes -The only optional requirements acceptable in a standard conformant to this -standard shall be expressible as a list of conformance classes to be passed. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Requirements classes intersect overlap only by reference -The common portion of any two requirements classes shall consist only of references -to other requirements classes. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - - -Conformance test class: UML model extends The Standard - -Dependency on Core -An implementation passing the UML conformance test class shall first pass the core -conformance test class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Leaf packages in only one requirements class -A UML leaf package shall be associated directly to only one requirements class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: . - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: . - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: . - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -All classes are in leaf packages -The UML model shall segregate all classes into leaf packages. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - - -Conformance test class: XML schema extends The Specification - -Dependency on Core -An implementation passing the XML schema conformance test class shall first pass the -core standard conformance test class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Dependency on W3C XML schema -An implementation passing the XML schema conformance test class shall first pass the -W3C Recommendation for XML schema. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - - -Conformance test class: Schematron - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Each schematron pattern is in one schematron element -Each sch:pattern element shall be contained within one sch:schema element. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Each schematron @fpi attribute is used only once -The value of the sch:schema/@fpi attribute shall be used on only one Schematron -schema. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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 - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -Each schematron fpi attribute is used only once -The value of the sch:schema/@fpi attribute shall be used on only one Schematron -schema. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - - -Conformance Class: XML meta-schema - -Supports the Specification class -A standard passing the XML meta-schema conformance test class shall first pass -the core specification conformance test class. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -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. - -Test Purpose: Verify that this requirement is satisfied. - -Test Method: Inspect the document to verify the above. - -Reference: - -Test Type: Conformance. - - - - - -OGC Only: Changes required in the OGC Standards -The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards - - - -New OGC standards and revisions to existing OGC standards -Any new standard, specification, or major revision of an existing standard SHALL -comply with the ModSpec in the structure of its internal models and its -conformance tests. - -Failure to conform by a candidate standard to the ModSpec should be specifically -noted and reasons given for such non-compliance in the conformance clauses of any -new or new version of such candidate standards. - -The adoption of such documents not compliant with the ModSpec shall be -considered as an authorized exception to the requirements of the ModSpec by the -approporiate authority, such as the OGC or ISO. The adoption of such -documents not compliant with the ModSpec shall be considered as an exception to -the requirements of the ModSpec by the authority (OGC) and shall be considered as an exception -to the rules of the authority such as the OGC and will require a two-thirds (2/3) majority (“Robert’s -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 Planning Committee or as specified -in any Policy and Procedure document used by this committee. - - -Definitions - -Semantically ordered definitions - formally defines the terms used in the conformance tests in alphabetical -order. It may be easier to understand the more significant terms in the following -less formal definitions arranged in a bottom-up order: - -a standardization target typestandardization target type is a type of entity about which a standard -is written. An instance of a standardization target typestandardization target type is a -standardization targetstandardization target. A standard may address multiple targets in separate -conformance classes. - -a requirementrequirement is a statement of a condition to be satisfied by a single -standardization target typestandardization target type, and it must be stated in “normative” language. - -a conformance testconformance test checks if a set of -requirementrequirements are met (pass) or not met (fail) by a -standardization targetstandardization target. The relationship between conformance test conformance tests and requirementrequirements is many-to-many. - -all conformance test conformance tests are graded as pass or fail -against each instance of the standardization targetstandardization target. - -a requirementrequirement is associated to one conformance testconformance test. - -a recommendationrecommendation is a suggestion and is not associated to any -conformance testconformance test. - -a requirements classrequirements class is a set of one or more requirementrequirements -all with the same standardization target typestandardization target type. - -a conformance test classconformance (test) class is a collection of -conformance testconformance tests that are associated to and only to the -requirements in a corresponding requirements classrequirements class. - -a conformance test moduleconformance (test) module is also collection of -term conformance test classes not resolved via ID conformance-test-classes that group -conformance test conformance tests on a single -standardization target typestandardization target type. - -a conformant implementation is a standardization target typestandardization target type that has -successfully passed all tests in a specified conformance test classconformance (test) class and received a certificate of conformancecertificate of conformance - -the core requirements classcore requirements class of a standard is the minimal set of -requirementrequirements which must be supported by all conformant implementations. If a standard addresses multiple standardization target typestandardization target types, it may have a core for each target type. - -an extension of a requirements classrequirements class is an additional requirements classrequirements class -(the extension) that adds additional requirementrequirements to the first -requirements classrequirements class (the base requirements class being extended). The -extension is said to be dependent on the base. Any conformance test classconformance test class -must identify all its dependencies during the execution of conformance tests -against a candidate standardization targetstandardization target. - - - - - -UML Model - -Specification structure - - - represents a UML model consistent with the specification model described -in . The following subclauses describe the classes shown in this UML -class diagram. - - - -Specification - - - -Specification -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 -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). - - -Specification attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -name -Name of the standard. -M -1 -String -authority -Standards body or author of this standard. -M -1 -Principal -date -Publication date of the standard. -M -1 -DateTime -status -Publication status of this standard. -M -1 -String - - - - - -Conformance Suite - - - -Conformance Class - - - -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 -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. - - -ConformanceClass attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -name -Name of the conformance class. -M -1 -String -dependencies -Conformance classes that this conformance class depends on. -These dependent conformance classes must be passed if this one is to be -passed. -O -N -ConformanceClass -requirementsClass -The requirements class that this conformance class aims to test against. -M -1 -RequirementsClass - - - - - -Requirements class - - - -RequirementsClass -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. - - -RequirementsClass attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -name -Name of the requirements class. -M -1 -String -dependencies -Requirements classes that this requirements class depends on. -These dependent requirements classes must be satisfied for this -requirements class to be satisfied. -O -N -RequirementsClass -modules -Requirements modules that make up this requirements class. -M -N -RequirementsModule -targetType -Type of standardization target. -M -1 -StandardizationTargetType - - - - - -Requirements module - - - -RequirementsModule -A requirements modules (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 -conformance test modules. - - -RequirementsModule attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -name -Name of the requirements module. -M -1 -String -requirements -Requirements classes that this requirements module contains. -M -N -Requirement - - - - - -Normative Statement - - - -NormativeStatement -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”. - - -NormativeStatement attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -name -Name of the normative statement. -M -1 -String - - - - - -Requirement - - - -Requirement -Normative statement that constitutes a requirement. - - -Requirement attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -tests -Conformance 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. -M -N -ConformanceTest -parts -Collection of requirements that are parts to this requirement. -Satisfaction of all requirement parts are necessary for this requirement -to be satisfied. Optional. -O -N -Requirement - - - - - -Recommendation - - - -Recommendation -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 -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 -logical designs that may implement the requirements in the same module. - - - -Regardless of their use, Recommendations are not tested since they are not -required of all conformant implementations. - - - -Conformance test - - - -ConformanceTest -A conformance test aims to satisfy a requirement and can potentially -contain multiple test methods. - - -ConformanceTest attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -abstract -Whether this test is abstract or concrete. An abstract conformance test -is commonly called an abstract test. -M -1 -Boolean -testPurpose -Purpose of the conformance test. -M -1 -String -testType -Type of the conformance test. -M -1 -TestType -testMethod -Method to perform this conformance test. -A method is considered a “part” of the test if there are multiple of them. -O -N -ConformanceTestMethod -references -References to the specification(s) of the conformance test. -O -N -RichText -requirements -Corresponding requirement or requirement part that this conformance -test is supposed to test against. -M -N -Requirement - - - - - -StandardizationTarget - - - -StandardizationTarget -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. - - -StandardizationTarget attributes -Name -Definition -Mandatory / Optional / Conditional -Max Occur -Data Type - -conformanceCertificates -conformance classes passed by this target -O -N -String -type -Type of the standardization target type. -M -1 -StandardizationTargetType - - - - - -StandardizationTargetType - - - -StandardizationTargetType - - -Normative referencesThe 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 10000-1ISO/IEC 10000-110000-1 -ISO - -IEC - - 2024-11-17 -ISO/IEC Directives, Part 2 - -Principles and rules for the structure and drafting of ISO and IEC documents - https://www.iso.org/sites/directives/current/part2/index.xhtml ISO/IEC DIR 2ISO/IEC DIR 2 9 en Latn 2021 -International Organization for Standardization - ISO www.iso.org 2024-11-17 -ISO/IEC Directives, Part 2 - -Principles and rules for the structure and drafting of ISO and IEC documents - https://www.iso.org/sites/directives/current/part2/index.xhtml ISO/IEC DIR 2 2021-05-01 9 en Latn 2021 -International Organization for Standardization - ISO www.iso.org - - 2024-11-17 -Geographic information - -Conformance and testing - -Geographic information — Conformance and testing - https://www.iso.org/standard/76457.html https://www.iso.org/obp/ui/en/#!iso:std:76457:en https://www.iso.org/contents/data/standard/07/64/76457.detail.rss ISO 19105 iso-reference ISO 19105(E) URN urn:iso:std:iso:19105:stage-60.60ISO 19105 19105 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn 60 60 2022 -ISO - ISO 19105:2000 ISO 19105:2000 - 2024-11-17 -Geographic information - -Conformance and testing - -Geographic information — Conformance and testing - https://www.iso.org/standard/76457.html https://www.iso.org/obp/ui/en/#!iso:std:76457:en https://www.iso.org/contents/data/standard/07/64/76457.detail.rss ISO 19105:2022 ISO 19105:2022(E) urn:iso:std:iso:19105:stage-60.60 19105 2022-07 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn This document specifies the framework, concepts and methodology for conformance testing and criteria to be achieved to claim conformance to the family of applicable standardization documents regarding geographic information and relevant application domains. This document provides a framework for specifying abstract test suites composed of abstract test cases grouped in conformance classes and for defining the procedures to be followed during conformance testing. Conformance can be claimed for data or software products or services or by specifications including any profile or functional standard. The structure of, and relationships between, conformance classes as defined in this document underly a systematic approach to configuration management involving managing dependencies within and between modules. 60 60 2022 -ISO - ISO 19105:2000 ISO 19105:2000 - Geneva - Geneva - 2024-11-17 -Information technology - -Open Distributed Processing - -Unified Modeling Language (UML) Version 1.4.2 - -Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 - https://www.iso.org/standard/32620.html https://www.iso.org/obp/ui/en/#!iso:std:32620:en https://www.iso.org/contents/data/standard/03/26/32620.detail.rss ISO/IEC 19501 iso-reference ISO/IEC 19501(E) URN urn:iso:std:iso-iec:19501:stage-90.60ISO/IEC 19501 19501 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr Latn 90 60 2005 -ISO/IEC - 2024-11-17 -Information technology - -Open Distributed Processing - -Unified Modeling Language (UML) Version 1.4.2 - -Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 - https://www.iso.org/standard/32620.html https://www.iso.org/obp/ui/en/#!iso:std:32620:en https://www.iso.org/contents/data/standard/03/26/32620.detail.rss ISO/IEC 19501:2005 ISO/IEC 19501:2005(E) urn:iso:std:iso-iec:19501:stage-90.60 19501 2005-04 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr Latn ISO/IEC 19501:2004 describes the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components. 90 60 2005 -ISO/IEC - Geneva - Geneva -OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2, OMG Document Number: formal/2007-11-04, Standard document URL: OMG UML/2.1.2/InfrastructureOMG UML/2.1.2/Infrastructure2.1.2/Infrastructure -OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, OMG Document Number: formal/2007-11-02; Standard document URL: OMG UML/2.1.2/SuperstructureOMG UML/2.1.2/Superstructure2.1.2/Superstructure - 2024-11-17 -Information technology - -Document Schema Definition Languages (DSDL) - -Part 3: Rule-based validation — Schematron - -Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron - https://www.iso.org/standard/40833.html https://www.iso.org/contents/data/standard/04/08/40833.detail.rss ISO/IEC 19757-3:2006 iso-reference ISO/IEC 19757-3:2006(E) URN urn:iso:std:iso-iec:19757:-3:stage-95.99ISO/IEC 19757-3:2006 19757 2006-06 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr Latn ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. 95 99 2006 -ISO/IEC - ISO/IEC 19757-3:2016 ISO/IEC 19757-3:2016 2016-01-14 - Geneva - 2024-11-17 -XML Schema Part 1: Structures Second Edition - https://www.w3.org/TR/xmlschema-1/ W3C xmlschema-1W3C xmlschema-1 xmlschema-1 -World Wide Web Consortium - W3C https://www.w3.org/ en Latn Recommendation W3C REC-xmlschema-1-20010502 https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ W3C REC-xmlschema-1-20010502 - W3C REC-xmlschema-1-20041028 https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ W3C REC-xmlschema-1-20041028 - -W3C REC - xmlschema-1 - 2024-11-17 -XML Schema Part 2: Datatypes Second Edition - https://www.w3.org/TR/xmlschema-2/ W3C xmlschema-2W3C xmlschema-2 xmlschema-2 -World Wide Web Consortium - W3C https://www.w3.org/ en Latn Recommendation W3C REC-xmlschema-2-20010502 https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ W3C REC-xmlschema-2-20010502 - W3C REC-xmlschema-2-20041028 https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ W3C REC-xmlschema-2-20041028 - -W3C REC - xmlschema-2 - -Bibliography -To preserve a unique numeric identifier for all documents listed as references in -this standard, the numbering of references in this annex is continued from the list -of normative reference in . -ISO/IEC JTC 1, ISO/IEC 9075:2003 — Information Technology — Database Languages — SQL. -ISO/IEC 9075:2003ISO/IEC 9075:200390752003 -ISO - -IEC - -ISO/IEC TR 10000: Information Technology — Framework and taxonomy of International Standardized Profiles -ISO/IEC TR 10000ISO/IEC TR 1000010000 -ISO - -IEC - 2024-11-17 -Information technology - -Database languages - -SQL multimedia and application packages — Part 3: Spatial - -Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial - https://www.iso.org/standard/38651.html https://www.iso.org/contents/data/standard/03/86/38651.detail.rss ISO/IEC 13249-3:2006 iso-reference ISO/IEC 13249-3:2006(E) URN urn:iso:std:iso-iec:13249:-3:stage-95.99ISO/IEC 13249-3:2006 13249 2006-11 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 3 en fr Latn ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. 95 99 2006 -ISO/IEC - ISO/IEC 13249-3:2003 ISO/IEC 13249-3:2003 - ISO/IEC 13249-3:2011 ISO/IEC 13249-3:2011 2011-04-07 - Geneva - Object Management Group (OMG), February 2007, Unified Modeling Language: Infrastructure , version 2.1.1 , formal/07-02-06, available from OMG.org at - OMG UML/2.1.1/InfrastructureOMG UML/2.1.1/Infrastructure - 2.1.1/Infrastructure - - Object Management Group (OMG), February 2007, Unified Modeling Language: Superstructure, version 2.1.1 , formal/07-02-05, available from OMG.org at - OMG UML/2.1.1/SuperstructureOMG UML/2.1.1/Superstructure - 2.1.1/Superstructure - 2024-11-17 -W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - http://www.w3.org/TR/xmlschema11-1/ W3C xmlschema11-1W3C xmlschema11-1 xmlschema11-1 -World Wide Web Consortium - W3C https://www.w3.org/ en Latn Working Draft W3C WD-xmlschema11-1-20040716 http://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/ W3C WD-xmlschema11-1-20040716 - W3C WD-xmlschema11-1-20050224 http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ W3C WD-xmlschema11-1-20050224 - W3C WD-xmlschema11-1-20060330 http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ W3C WD-xmlschema11-1-20060330 - W3C WD-xmlschema11-1-20060831 http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ W3C WD-xmlschema11-1-20060831 - W3C WD-xmlschema11-1-20070830 http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ W3C WD-xmlschema11-1-20070830 - W3C WD-xmlschema11-1-20080620 http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/ W3C WD-xmlschema11-1-20080620 - W3C WD-xmlschema11-1-20090130 http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/ W3C WD-xmlschema11-1-20090130 - W3C CR-xmlschema11-1-20090430 http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ W3C CR-xmlschema11-1-20090430 - W3C WD-xmlschema11-1-20091203 http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/ W3C WD-xmlschema11-1-20091203 - W3C CR-xmlschema11-1-20110721 http://www.w3.org/TR/2011/CR-xmlschema11-1-20110721/ W3C CR-xmlschema11-1-20110721 - W3C PR-xmlschema11-1-20120119 http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ W3C PR-xmlschema11-1-20120119 - -W3C WD - xmlschema11-1 2024-11-17 -W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - http://www.w3.org/TR/xmlschema11-2/ W3C xmlschema11-2W3C xmlschema11-2 xmlschema11-2 -World Wide Web Consortium - W3C https://www.w3.org/ en Latn Working Draft W3C WD-xmlschema11-2-20040716 http://www.w3.org/TR/2004/WD-xmlschema11-2-20040716/ W3C WD-xmlschema11-2-20040716 - W3C WD-xmlschema11-2-20050224 http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/ W3C WD-xmlschema11-2-20050224 - W3C WD-xmlschema11-2-20060217 http://www.w3.org/TR/2006/WD-xmlschema11-2-20060217/ W3C WD-xmlschema11-2-20060217 - W3C WD-xmlschema11-2-20080620 http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/ W3C WD-xmlschema11-2-20080620 - W3C WD-xmlschema11-2-20090130 http://www.w3.org/TR/2009/WD-xmlschema11-2-20090130/ W3C WD-xmlschema11-2-20090130 - W3C CR-xmlschema11-2-20090430 http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ W3C CR-xmlschema11-2-20090430 - W3C WD-xmlschema11-2-20091203 http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/ W3C WD-xmlschema11-2-20091203 - W3C CR-xmlschema11-2-20110721 http://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/ W3C CR-xmlschema11-2-20110721 - W3C PR-xmlschema11-2-20120119 http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ W3C PR-xmlschema11-2-20120119 - -W3C WD - 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. 2024-11-17 -OWS5: OGC Web feature service, core and extensions - -OWS5: OGC Web feature service, core and extensions - https://portal.ogc.org/files/?artifact_id=28176 OGC 08-079OGC 08-079 2008-09-12 - John Herring - -Open Geospatial Consortium - en Latn This standard specifies the behavior of a service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations and transaction operations. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Retrieval operations allow features to be retrieved from the opaque underlying data store based upon constraints on spatial and non-spatial feature properties defined by the client. Transaction operations allow features to be created, changed and deleted from the opaque underlying data store. 2024-11-17 -Geographic information - -Reference model - -Geographic information — Reference model - https://www.iso.org/standard/26002.html https://www.iso.org/contents/data/standard/02/60/26002.detail.rss ISO 19101 iso-reference ISO 19101(E) URN urn:iso:std:iso:19101:stage-95.99ISO 19101 19101 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 95 99 2002 -ISO - ISO 19101-1:2014 ISO 19101-1:2014 2014-11-12 - 2024-11-17 -Geographic information - -Reference model - -Geographic information — Reference model - https://www.iso.org/standard/26002.html https://www.iso.org/contents/data/standard/02/60/26002.detail.rss ISO 19101:2002 ISO 19101:2002(E) urn:iso:std:iso:19101:stage-95.99 19101 2002-07 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn This International Standard defines the framework for standardization in the field of geographic information and sets forth the basic principles by which this standardization takes place. This framework identifies the scope of the standardization activity being undertaken and the context in which it takes place. The framework provides the method by which what is to be standardized can be determined and describes how the contents of the standards are related. Although structured in the context of information technology and information technology standards, this International Standard is independent of any application development method or technology implementation approach. 95 99 2002 -ISO - ISO 19101-1:2014 ISO 19101-1:2014 2014-11-12 - Geneva - Geneva 2024-11-17 -Geographic information - -Spatial schema - -Geographic information — Spatial schema - https://www.iso.org/standard/66175.html https://www.iso.org/obp/ui/en/#!iso:std:66175:en https://www.iso.org/contents/data/standard/06/61/66175.detail.rss ISO 19107 iso-reference ISO 19107(E) URN urn:iso:std:iso:19107:stage-90.20ISO 19107 19107 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn 90 20 2019 -ISO - ISO 19107:2003 ISO 19107:2003 - 2024-11-17 -Geographic information - -Spatial schema - -Geographic information — Spatial schema - https://www.iso.org/standard/66175.html https://www.iso.org/obp/ui/en/#!iso:std:66175:en https://www.iso.org/contents/data/standard/06/61/66175.detail.rss ISO 19107:2019 ISO 19107:2019(E) urn:iso:std:iso:19107:stage-90.20 19107 2019-12 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn This document specifies conceptual schemas for describing the spatial characteristics of geographic entities, and a set of spatial operations consistent with these schemas. It treats “vector” geometry and topology. It defines standard spatial operations for use in access, query, management, processing and data exchange of geographic information for spatial (geometric and topological) objects. Because of the nature of geographic information, these geometric coordinate spaces will normally have up to three spatial dimensions, one temporal dimension and any number of other spatially dependent parameters as needed by the applications. In general, the topological dimension of the spatial projections of the geometric objects will be at most three. 90 20 2019 -ISO - ISO 19107:2003 ISO 19107:2003 - Geneva - Geneva 2024-11-17 -Geographic information - -Referencing by coordinates - -Geographic information — Referencing by coordinates - https://www.iso.org/standard/74039.html https://www.iso.org/obp/ui/en/#!iso:std:74039:en https://www.iso.org/contents/data/standard/07/40/74039.detail.rss ISO 19111 iso-reference ISO 19111(E) URN urn:iso:std:iso:19111:stage-90.92ISO 19111 19111 -International Organization for Standardization - ISO www.iso.org 3 en fr Latn 90 92 2019 -ISO - ISO 19111-2:2009 ISO 19111-2:2009 - ISO 19111:2007 ISO 19111:2007 - ISO/AWI 19111 ISO/AWI 19111 - ISO 19111:2019/Amd 1:2021 ISO 19111:2019/Amd 1:2021 2024-09-16 - ISO 19111:2019/Amd 2:2023 ISO 19111:2019/Amd 2:2023 2024-09-16 - 2024-11-17 -Geographic information - -Referencing by coordinates - -Geographic information — Referencing by coordinates - https://www.iso.org/standard/74039.html https://www.iso.org/obp/ui/en/#!iso:std:74039:en https://www.iso.org/contents/data/standard/07/40/74039.detail.rss ISO 19111:2019 ISO 19111:2019(E) urn:iso:std:iso:19111:stage-90.92 19111 2019-01 -International Organization for Standardization - ISO www.iso.org 3 en fr Latn This document defines the conceptual schema for the description of referencing by coordinates. It describes the minimum data required to define coordinate reference systems. This document supports the definition of: — spatial coordinate reference systems where coordinate values do not change with time. The system may: — — be geodetic and apply on a national or regional basis, or — — apply locally such as for a building or construction site, or — — apply locally to an image or image sensor; — — be referenced to a moving platform such as a car, a ship, an aircraft or a spacecraft. Such a coordinate reference system can be related to a second coordinate reference system which is referenced to the Earth through a transformation that includes a time element; — spatial coordinate reference systems in which coordinate values of points on or near the surface of the earth change with time due to tectonic plate motion or other crustal deformation. Such dynamic systems include time evolution, however they remain spatial in nature; — parametric coordinate reference systems which use a non-spatial parameter that varies monotonically with height or depth; — temporal coordinate reference systems which use dateTime, temporal count or temporal measure quantities that vary monotonically with time; — mixed spatial, parametric or temporal coordinate reference systems. The definition of a coordinate reference system does not change with time, although in some cases some of the defining parameters can include a rate of change of the parameter. The coordinate values within a dynamic and in a temporal coordinate reference system can change with time. This document also describes the conceptual schema for defining the information required to describe operations that change coordinate values. In addition to the minimum data required for the definition of the coordinate reference system or coordinate operation, the conceptual schema allows additional descriptive information — coordinate reference system metadata — to be provided. This document is applicable to producers and users of geographic information. Although it is applicable to digital geographic data, the principles described in this document can be extended to many other forms of spatial data such as maps, charts and text documents. 90 92 2019 -ISO - ISO 19111-2:2009 ISO 19111-2:2009 - ISO 19111:2007 ISO 19111:2007 - ISO/AWI 19111 ISO/AWI 19111 - ISO 19111:2019/Amd 1:2021 ISO 19111:2019/Amd 1:2021 2024-09-16 - ISO 19111:2019/Amd 2:2023 ISO 19111:2019/Amd 2:2023 2024-09-16 - Geneva - Geneva 2024-11-17 -Geographic information - -Services - -Geographic information — Services - https://www.iso.org/standard/59221.html https://www.iso.org/obp/ui/en/#!iso:std:59221:en https://www.iso.org/contents/data/standard/05/92/59221.detail.rss ISO 19119 iso-reference ISO 19119(E) URN urn:iso:std:iso:19119:stage-90.93ISO 19119 19119 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn 90 93 2016 -ISO - ISO 19119:2005 ISO 19119:2005 - ISO 19119:2005/Amd 1:2008 ISO 19119:2005/Amd 1:2008 - 2024-11-17 -Geographic information - -Services - -Geographic information — Services - https://www.iso.org/standard/59221.html https://www.iso.org/obp/ui/en/#!iso:std:59221:en https://www.iso.org/contents/data/standard/05/92/59221.detail.rss ISO 19119:2016 ISO 19119:2016(E) urn:iso:std:iso:19119:stage-90.93 19119 2016-01 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn ISO 19119:2016 defines requirements for how platform neutral and platform specific specification of services shall be created, in order to allow for one service to be specified independently of one or more underlying distributed computing platforms. ISO 19119:2016 defines requirements for a further mapping from platform neutral to platform specific service specifications, in order to enable conformant and interoperable service implementations. ISO 19119:2016 addresses the Meta:Service foundation of the ISO geographic information reference model described in ISO 19101‑1:2014, Clause 6 and Clause 8, respectively. ISO 19119:2016 defines how geographic services shall be categorised according to a service taxonomy based on architectural areas and allows also for services to be categorised according to a usage life cycle perspective, as well as according to domain specific and user defined service taxonomies, providing support for easier publication and discovery of services. 90 93 2016 -ISO - ISO 19119:2005 ISO 19119:2005 - ISO 19119:2005/Amd 1:2008 ISO 19119:2005/Amd 1:2008 - Geneva - Geneva -Geographic information — Simple features -ISO 19125ISO 1912519125 -ISO - 2024-11-17 -Geographic information - -Location-based services - -Tracking and navigation - -Geographic information — Location-based services — Tracking and navigation - https://www.iso.org/standard/32551.html https://www.iso.org/obp/ui/en/#!iso:std:32551:en https://www.iso.org/contents/data/standard/03/25/32551.detail.rss ISO 19133 iso-reference ISO 19133(E) URN urn:iso:std:iso:19133:stage-90.93ISO 19133 19133 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 90 93 2005 -ISO - 2024-11-17 -Geographic information - -Location-based services - -Tracking and navigation - -Geographic information — Location-based services — Tracking and navigation - https://www.iso.org/standard/32551.html https://www.iso.org/obp/ui/en/#!iso:std:32551:en https://www.iso.org/contents/data/standard/03/25/32551.detail.rss ISO 19133:2005 ISO 19133:2005(E) urn:iso:std:iso:19133:stage-90.93 19133 2005-10 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19133:2005 describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. It is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment. 90 93 2005 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Geography Markup Language (GML) - -Geographic information — Geography Markup Language (GML) - https://www.iso.org/standard/32554.html https://www.iso.org/contents/data/standard/03/25/32554.detail.rss ISO 19136 iso-reference ISO 19136(E) URN urn:iso:std:iso:19136:stage-95.99ISO 19136 19136 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 95 99 2007 -ISO - ISO 19136-1:2020 ISO 19136-1:2020 2020-01-09 - 2024-11-17 -Geographic information - -Geography Markup Language (GML) - -Geographic information — Geography Markup Language (GML) - https://www.iso.org/standard/32554.html https://www.iso.org/contents/data/standard/03/25/32554.detail.rss ISO 19136:2007 ISO 19136:2007(E) urn:iso:std:iso:19136:stage-95.99 19136 2007-09 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features. ISO 19136:2007 defines the XML Schema syntax, mechanisms and conventions that: — provide an open, vendor-neutral framework for the description of geospatial application schemas for the transport and storage of geographic information in XML; — allow profiles that support proper subsets of GML framework descriptive capabilities; — support the description of geospatial application schemas for specialized domains and information communities; — enable the creation and maintenance of linked geographic application schemas and datasets; — support the storage and transport of application schemas and data sets; — increase the ability of organizations to share geographic application schemas and the information they describe. Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport. NOTE If an ISO 19109 conformant application schema described in UML is used as the basis for the storage and transportation of geographic information, ISO 19136 provides normative rules for the mapping of such an application schema to a GML application schema in XML Schema and, as such, to an XML encoding for data with a logical structure in accordance with the ISO 19109 conformant application schema. 95 99 2007 -ISO - ISO 19136-1:2020 ISO 19136-1:2020 2020-01-09 - Geneva - Geneva 2024-11-17 -Geographic information - -Schema for moving features - -Geographic information — Schema for moving features - https://www.iso.org/standard/41445.html https://www.iso.org/obp/ui/en/#!iso:std:41445:en https://www.iso.org/contents/data/standard/04/14/41445.detail.rss ISO 19141 iso-reference ISO 19141(E) URN urn:iso:std:iso:19141:stage-90.93ISO 19141 19141 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 90 93 2008 -ISO - 2024-11-17 -Geographic information - -Schema for moving features - -Geographic information — Schema for moving features - https://www.iso.org/standard/41445.html https://www.iso.org/obp/ui/en/#!iso:std:41445:en https://www.iso.org/contents/data/standard/04/14/41445.detail.rss ISO 19141:2008 ISO 19141:2008(E) urn:iso:std:iso:19141:stage-90.93 19141 2008-06 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19141:2008 defines a method to describe the geometry of a feature that moves as a rigid body. Such movement has the following characteristics. — The feature moves within any domain composed of spatial objects as specified in ISO 19107. — The feature may move along a planned route, but it may deviate from the planned route. — Motion may be influenced by physical forces, such as orbital, gravitational, or inertial forces. — Motion of a feature may influence or be influenced by other features, for example: The moving feature might follow a predefined route (e.g. road), perhaps part of a network, and might change routes at known points (e.g. bus stops, waypoints). Two or more moving features may be “pulled” together or pushed apart (e.g. an airplane will be refuelled during flight, a predator detects and tracks a prey, refugee groups join forces). Two or more moving features may be constrained to maintain a given spatial relationship for some period (e.g. tractor and trailer, convoy). ISO 19141:2008 does not address other types of change to the feature. Examples of changes that are not adressed include the following: — The deformation of features. — The succession of either features or their associations. — The change of non-spatial attributes of features. — The feature’s geometric representation cannot be embedded in a geometric complex that contains the geometric representations of other features, since this would require the other features’ representations to be updated as the feature moves. Because ISO 19141:2008 is concerned with the geometric description of feature movement, it does not specify a mechanism for describing feature motion in terms of geographic identifiers. This is done, in part, in ISO 19133. 90 93 2008 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Web Feature Service - -Geographic information — Web Feature Service - https://www.iso.org/standard/42136.html https://www.iso.org/obp/ui/en/#!iso:std:42136:en https://www.iso.org/contents/data/standard/04/21/42136.detail.rss ISO 19142 iso-reference ISO 19142(E) URN urn:iso:std:iso:19142:stage-90.93ISO 19142 19142 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 90 93 2010 -ISO - 2024-11-17 -Geographic information - -Web Feature Service - -Geographic information — Web Feature Service - https://www.iso.org/standard/42136.html https://www.iso.org/obp/ui/en/#!iso:std:42136:en https://www.iso.org/contents/data/standard/04/21/42136.detail.rss ISO 19142:2010 ISO 19142:2010(E) urn:iso:std:iso:19142:stage-90.93 19142 2010-12 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19142:2010 specifies the behaviour of a web feature service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations, locking operations, transaction operations and operations to manage stored parameterized query expressions. 90 93 2010 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Filter encoding - -Geographic information — Filter encoding - https://www.iso.org/standard/42137.html https://www.iso.org/obp/ui/en/#!iso:std:42137:en https://www.iso.org/contents/data/standard/04/21/42137.detail.rss ISO 19143 iso-reference ISO 19143(E) URN urn:iso:std:iso:19143:stage-90.93ISO 19143 19143 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 90 93 2010 -ISO - 2024-11-17 -Geographic information - -Filter encoding - -Geographic information — Filter encoding - https://www.iso.org/standard/42137.html https://www.iso.org/obp/ui/en/#!iso:std:42137:en https://www.iso.org/contents/data/standard/04/21/42137.detail.rss ISO 19143:2010 ISO 19143:2010(E) urn:iso:std:iso:19143:stage-90.93 19143 2010-10 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19143:2010 describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. These components are modular and intended to be used together or individually by other International Standards which reference ISO 19143:2010. ISO 19143:2010 defines an abstract component, named AbstractQueryExpression, from which other specifications can subclass concrete query elements to implement query operations. It also defines an additional abstract query component, named AbstractAdhocQueryExpresison, which is derived from AbstractQueryExpression and from which other specifications can subclass concrete query elements which follow the following query pattern:  — An abstract query element from which service specifications can subclass a concrete query element that implements a query operation that allows a client to specify a list of resource types, an optional projection clause, an optional selection clause, and an optional sorting clause to query a subset of resources that satisfy the selection clause. This pattern is referred to as an ad hoc query pattern since the server in not aware of the query until it is submitted for processing. This is in contrast to a stored query expression, which is stored and can be invoked by name or identifier. ISO 19143:2010 also describes an XML and KVP encoding of a system-neutral representation of a select clause. The XML representation is easily validated, parsed and transformed into a server-specific language required to retrieve or modify object instances stored in some persistent object store. ISO 19143:2010 defines the XML encoding for the following predicates. — A standard set of logical predicates: and, or and not. — A standard set of comparison predicates: equal to, not equal to, less than, less than or equal to, greater than, greater than or equal to, like, is null and between. — A standard set of spatial predicates: equal, disjoint, touches, within, overlaps, crosses, intersects, contains, within a specified distance, beyond a specified distance and BBOX. — A standard set of temporal predicates: after, before, begins, begun by, contains, during, ends, equals, meets, met by, overlaps and overlapped by. — A predicate to test whether the identifier of an object matches the specified value. ISO 19143:2010 defines the XML encoding of metadata that allows a service to declare which conformance classes, predicates, operators, operands and functions it supports. This metadata is referred to as Filter Capabilities. 90 93 2010 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Linear referencing - -Geographic information — Linear referencing - https://www.iso.org/standard/75150.html https://www.iso.org/obp/ui/en/#!iso:std:75150:en https://www.iso.org/contents/data/standard/07/51/75150.detail.rss ISO 19148 iso-reference ISO 19148(E) URN urn:iso:std:iso:19148:stage-60.60ISO 19148 19148 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn 60 60 2021 -ISO - ISO 19148:2012 ISO 19148:2012 - 2024-11-17 -Geographic information - -Linear referencing - -Geographic information — Linear referencing - https://www.iso.org/standard/75150.html https://www.iso.org/obp/ui/en/#!iso:std:75150:en https://www.iso.org/contents/data/standard/07/51/75150.detail.rss ISO 19148:2021 ISO 19148:2021(E) urn:iso:std:iso:19148:stage-60.60 19148 2021-04 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn This document specifies a conceptual schema for locations relative to a one-dimensional object as measurement along (and optionally offset from) that object. It defines a description of the data and operations required to use and support linear referencing. This document is applicable to transportation, utilities, environmental protection, location-based services and other applications which define locations relative to linear objects. For ease of reading, most examples discussed in this document come from the transportation domain. 60 60 2021 -ISO - ISO 19148:2012 ISO 19148:2012 - Geneva - Geneva 2024-11-17 -Geographic information - -Rights expression language for geographic information - -GeoREL - -Geographic information — Rights expression language for geographic information — GeoREL - https://www.iso.org/standard/32567.html https://www.iso.org/contents/data/standard/03/25/32567.detail.rss ISO 19149 iso-reference ISO 19149(E) URN urn:iso:std:iso:19149:stage-95.99ISO 19149 19149 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 95 99 2011 -ISO - 2024-11-17 -Geographic information - -Rights expression language for geographic information - -GeoREL - -Geographic information — Rights expression language for geographic information — GeoREL - https://www.iso.org/standard/32567.html https://www.iso.org/contents/data/standard/03/25/32567.detail.rss ISO 19149:2011 ISO 19149:2011(E) urn:iso:std:iso:19149:stage-95.99 19149 2011-11 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19149:2011 defines an XML-based vocabulary or language to express rights for geographic information in order that digital licenses can be created for such information and related services. This language, GeoREL, is an extension of the rights expression language in ISO/IEC 21000-5 and is to be used to compose digital licenses. Each digital license will unambiguously express those particular rights that the owners (or their agent) of a digital geographic resource extend to the holders of that license. The digital rights management system in which these licenses are used can then offer ex ante (before the fact) protection for all such resources. NOTE The proper use of a GeoREL includes the preservation of rights access by formula expressed in usage licenses. Thus, data in the public or private domain, when protected, remain in their respective domains if the usage rights granted so state. These “rights” are not always covered by copyright law, and are often the result of contracts between individuals that specify the proper and allowed uses of resources, as opposed to the threat of copyright litigations which is an ex post facto (after the fact) remediation measure, not an ex ante protection measure. ISO 19149:2011 is not a reflection of, or extension of, copyright law. Mechanisms for the enforcement and preservation of those contract rights are specified in ISO/IEC 21000, and it is not the intention of ISO 19149:2011 to replace nor redefine those mechanisms, but to use them as previously standardized. 95 99 2011 -ISO - Geneva - Geneva 2024-11-17 -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - https://www.iso.org/standard/32571.html https://www.iso.org/contents/data/standard/03/25/32571.detail.rss ISO 19153 iso-reference ISO 19153(E) URN urn:iso:std:iso:19153:stage-95.99ISO 19153 19153 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn 95 99 2014 -ISO - 2024-11-17 -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - https://www.iso.org/standard/32571.html https://www.iso.org/contents/data/standard/03/25/32571.detail.rss ISO 19153:2014 ISO 19153:2014(E) urn:iso:std:iso:19153:stage-95.99 19153 2014-02 -International Organization for Standardization - ISO www.iso.org 1 en fr Latn ISO 19153:2014 is a reference model for digital rights management (DRM) functionality for geospatial resources (GeoDRM). As such, it is connected to the general DRM market in that geospatial resources shall be treated as nearly as possible like other resources, such as music, text, or services. It is not the intention to reinvent a market nor the technology that already exists and is thriving, but to make sure that a larger market has access to geospatial resources through a mechanism that it understands and that is similar to and consistent with the ones already in use. ISO 19153:2014 does not replace any previous standards, but it is dependent upon them. Each resource and service standard that exists or will exist becomes a resource description in ISO 19153:2014, and hopefully will be subject to the same protection that is afforded to other resources. This International Standard defines: —  A conceptual model for digital rights management of geospatial resources, providing a framework and reference for more detailed specification in this area. —  A metadata model for the expression of rights that associate users to the acts that they can perform against a particular geospatial resource, and associated information used in the enforcement and granting of those rights, such as owner metadata, available rights, and issuer of those rights. —  Requirements that are placed on rights management systems for the enforcement of those rights. A rights management system shall be necessary and sufficient: it shall implement only those restrictions necessary to enforce the rights defined therein, and it shall be sufficient to enforce those rights. —  How this is to work conceptually in the larger DRM context to ensure the ubiquity of geospatial resources in the general services market. A resource in this context is a data file, or service for geographic information or process. This abstract descriptive standard builds on and complements the existing standards, and defines at an abstract level a rights model to enable the digital rights management of standards-based geospatial resources. Future GeoDRM standards will be written to implement the concepts defined in ISO 19153:2014. 95 99 2014 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Observations, measurements and samples - -Geographic information — Observations, measurements and samples - https://www.iso.org/standard/82463.html https://www.iso.org/obp/ui/en/#!iso:std:82463:en https://www.iso.org/contents/data/standard/08/24/82463.detail.rss ISO 19156 iso-reference ISO 19156(E) URN urn:iso:std:iso:19156:stage-60.60ISO 19156 19156 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn 60 60 2023 -ISO - ISO 19156:2011 ISO 19156:2011 - 2024-11-17 -Geographic information - -Observations, measurements and samples - -Geographic information — Observations, measurements and samples - https://www.iso.org/standard/82463.html https://www.iso.org/obp/ui/en/#!iso:std:82463:en https://www.iso.org/contents/data/standard/08/24/82463.detail.rss ISO 19156:2023 ISO 19156:2023(E) urn:iso:std:iso:19156:stage-60.60 19156 2023-04 -International Organization for Standardization - ISO www.iso.org 2 en fr Latn This document defines a conceptual schema for observations, for features involved in the observation process, and for features involved in sampling when making observations. These provide models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. Observations commonly involve sampling of an ultimate feature-of-interest. This document defines a common set of sample types according to their spatial, material (for ex situ observations) or statistical nature. The schema includes relationships between sample features (sub-sampling, derived samples). This document concerns only externally visible interfaces and places no restriction on the underlying implementations other than what is needed to satisfy the interface specifications in the actual situation. 60 60 2023 -ISO - ISO 19156:2011 ISO 19156:2011 - Geneva - Geneva - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : - - - - -sourcecode table td { padding: 5px; } -sourcecode table pre { margin: 0; } -sourcecode, sourcecode .w { - color: #444444; -} -sourcecode .cp { - color: #CC00A3; -} -sourcecode .cs { - color: #CC00A3; -} -sourcecode .c, sourcecode .ch, sourcecode .cd, sourcecode .cm, sourcecode .cpf, sourcecode .c1 { - color: #1E90FF; -} -sourcecode .kc { - color: #C34E00; -} -sourcecode .kd { - color: #0000FF; -} -sourcecode .kr { - color: #007575; -} -sourcecode .k, sourcecode .kn, sourcecode .kp, sourcecode .kt, sourcecode .kv { - color: #0000FF; -} -sourcecode .s, sourcecode .sb, sourcecode .sc, sourcecode .ld, sourcecode .sd, sourcecode .s2, sourcecode .se, sourcecode .sh, sourcecode .si, sourcecode .sx, sourcecode .sr, sourcecode .s1, sourcecode .ss { - color: #009C00; -} -sourcecode .sa { - color: #0000FF; -} -sourcecode .nb, sourcecode .bp { - color: #C34E00; -} -sourcecode .nt { - color: #0000FF; -} - - - - -Copyright notice -

Copyright © 2024 Open Geospatial Consortium
-To obtain additional rights of use, visit -

-
- - -Note -

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

-
-
- - - - -License Agreement -

Use of this document is subject to the license agreement at

-
-
- - - - -Notice -

This document is not an OGC Standard. This document is an OGC Draft Standard and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard.

- -

Further, an OGC Draft Standard should not be referenced as required or mandatory technology in procurements.

-
-
- - - - -
Contents - -I.<tab/>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 -encouraged. Such suggestions may be submitted through the OGC Change Request System -() or by creating an issue in the GitHub repository for this document ().

-
- II.<tab/>Security considerations -

No security considerations have been made for this document.

-III.<tab/>Submitting Organizations -

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

-
  • TBD
-
- -IV.<tab/>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.<tab/>Document editors -

The following OGC Members participated in editing this document:

- - - - - - -
PersonOrganization Represented
Carl ReedCarl Reed & Associates
-
-VI.<tab/>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.<tab/>Revision history -

This is the second normative version of this document.

-
-VIII.<tab/>Future work -

Improvements to this document will be made based on implementation and changing technical requirements. Planned extensions include:

- -
  • ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL.

    -
  • -
  • ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using JSON.

    -
  • -
-
-IX.<tab/>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.<tab/>Introduction -NOTE 1

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

-
- -

This OGC document, also known as the ModSpec:

- -
  • Specifies rules for the internal structure and organization of a standard.

    -
  • -
  • Defines requirements for specifying the structure of a standards document as organized sets of criteria, those that are to be tested (“requirements”) and those that are not tested (“recommendations” and “permissions”).

    -
  • -
  • Designed to enable the clear and concise specification of requirements (the shalls or musts in a standard) that fully supports the ability to define implementable conformance tests.

    -
  • -
- -

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.

-
-XI.<tab/>Acknowledgements -

The following OGC Members were key contributors to Version 1 of the ModSpec

- -Table 1 - - - - - - - - - - - - - - - - - - - - -
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.<tab/>Scope -

The ModSpec defines characteristics and structure for the specification of Standards -that will encourage implementation by minimizing difficulty determining -requirements, mimicking implementation structure and maximizing usability and -interoperability.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 -of understanding. These two sections can be read first to aid in the understanding of -the rest of the document.

-
- - -2.<tab/>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

    -
  2. -
  3. Standards using UML to state requirements, extending the core — see -Clause 9.2.2 and Annex A.2

    -
  4. -
  5. Standards using XML schema to state requirements, extending the core — see -Clause 9.2.3 and Annex A.3

    -
  6. -
  7. Standards using Schematron to state requirements, extending XML schema — see -Clause 9.2.4 and Annex A.4

    -
  8. -
  9. 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 9.2.5 and Annex A.5.

    -
  10. -
- -

This document contains normative language and thus places requirements on -conformance, or mechanism for adoption, of candidate standards to which the ModSpec -applies. In particular:

- -
  • [cls-6] specifies the core requirements which shall be met by all conformant -standards.

    -
  • -
  • Clause 9 gives information on how the ModSpec is to be applied to requirements, -conformance clauses, UML models, or XML Schemas.

    -
  • -
- -

The various subclauses of Clause 9 list requirements partially derived from the -core, but more specific to the conditions where a data model expressed in one of the -specified languages (UML or XML) is involved. These requirements classes are -extensions of the core presented in [cls-6].

-
- - - - -4.<tab/>Terms and definitions - -

For the purposes of this document, the following terms and definitions shall apply. -Terms not defined here take their meaning from computer science or from their -Standard English (common US and UK) meanings. The form of the definitions is -defined by ISO Directives.

- -

Many of these definitions depend upon the model given in [cls-6-1].

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

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

- -

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 -within a standard, or set of standards

-
- -4.5.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 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.7.conformance test classconformance test level ALTERNATIVE - - - -

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 (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.8.conformance suiteconformance test suite ALTERNATIVEabstract test suite ALTERNATIVE - - - - - -

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

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

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

-
- -4.13.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 -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 -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.modelabstract model ALTERNATIVEconceptual model ALTERNATIVE - - - - - -

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

uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more -of a “statement of fact” than a “normative” condition.

-
- -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), -conforming subsets, options and parameters of those base standards, or -profiles necessary to accomplish a particular function.

- - - - - Note 1 to entry

In the usage of this Policy, a profile will be a set of requirements classes -or conformance classes (either preexisting or locally defined) of the base -standards.

- -

This means that a standardization target (Clause 4.26) being conformant to a profile -implies that the same target is conformant to the standards referenced in the -profile (Clause 4.19).

-
[SOURCE: ISO/IEC 10000-1]
- -4.20.recommendation -

expression in the content of a standard conveying that among several -possibilities one is recommended as particularly suitable, without mentioning or -excluding others, or that a certain course of action is preferred but not -necessarily required, or that (in the negative form) a certain possibility or -course of action is deprecated but not prohibited

- - - - - - - Note 1 to entry

Although using normative language, a recommendation (Clause 4.20) 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 -conditional).

-
Note 2 to entry

Recommendations are not tested and therefor have no related conformance test.

-
[SOURCE: ISO/IEC DIR 2]
- -4.21.requirement -

expression in the content of a standard conveying criteria to be fulfilled if -compliance with the standard is to be claimed and from which no deviation is permitted

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

- - - Note 1 to entry

There is some confusion possible here, since the testing of indirect -dependencies seems to violate this definition. But the existence of an indirect -dependency implies that the test is actually a test of the existence of the -relationship from the original target to something that has a property -(satisfies a condition or requirement from another requirements class).

-
- -4.23.requirements module -

collection of term requirement class, display requirements classes not resolved via ID requirement-class, -recommendations (Clause 4.20) and permissions (Clause 4.18) with a -single standardization target (Clause 4.26)

-
- -4.24.specification -

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

- - - Note 1 to entry

This definition is included for completeness. See Clause 6.4.

- -

This does not restrict what else a standard may contain, as long as it does -contain the three types of element cited.

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

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

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

-
- -4.28.statement -

expression in a document conveying information

- - - - - 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.<tab/>Conventions - -6.1.<tab/>Symbols (and abbreviated terms) -

All symbols used in this document are either:

- -
  1. Common mathematical symbols

    -
  2. -
  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. -
-
- - -6.2.<tab/>Identifiers -

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

- -

- -

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:

- -

- -

An example might be:

- -

/req/core/crs

- -

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

- -

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

- -

- -

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

-
- - -6.3.<tab/>Abbreviated terms -

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

- -
ERA

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

-
-
ISO

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

-
-
OCL

Object Constraint Language (part of UML)

-
-
OGC

Open Geospatial Consortium ()

-
-
OMG

Object Management Group ()

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

-
-
- -6.4.<tab/>Finding requirements and recommendations -

Each normative statement in the ModSpec is stated in one and only one place, -in a standard format, and has 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 abstract test suite -in Annex A. The reference to the requirement in the test case is done by a -requirements label (in the form “Req #”, where “#” is a number) associated to -the home of the statement described above. 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 -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.

-
-
- - -7.<tab/>Fundamentals - -7.1.<tab/>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. -
  3. 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.

    -
  4. -
  5. All requirements, recommendations, permissions, and models are introduced and defined first in -the numbered Clauses.

    -
  6. -
  7. All requirements are identifiable as requirements.

    -
  8. -
  9. All requirements in a document are uniquely numbered.

    -
  10. -
  11. All tests for conformance to those requirements are defined in the Conformance Test Suite.

    -
  12. -
  13. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.

    -
  14. -
  15. The tests, if conducted, determine to some degree of certainty whether an -implementation meets the requirements which the tests reference.

    -
  16. -
  17. 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”.

    -
  18. -
  19. Certificates of conformance (see Clause 4.1) are -awarded by a testing entity based on these conformance classes.

    -
  20. -
  21. There is a clear distinction between normative and informative parts of the text.

    -
  22. -
  23. Examples and notes are informative, and do not use “normative” -language.

    -
  24. -
- -

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

-
- - -7.2.<tab/>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

    -
  • -
-
- - -7.3.<tab/>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. -
  3. A building block may interoperate with other, inter-dependent, building blocks.

    -
  4. -
  5. A good building block has the following characteristics:

    -
    1. Considers implementation and usage, and evolves to exploit technology and standards.

      -
    2. -
    3. May be assembled from other building blocks.

      -
    4. -
    5. May be a subassembly of other building blocks.

      -
    6. -
    7. Ideally a building block is re-usable and replaceable, and well specified.

      -
    8. -
    -
  6. -
  7. A building block may have multiple implementations but with different inter-dependent building blocks.

    -
  8. -
- -

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.4.<tab/>Standardization Context — Goals and Targets -

Every OGC Standard shall include a Standardization Goal. This is a concise statement of the problem that the Standard will help 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: -• 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 – 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 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 our 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.5.<tab/>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 8.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 2 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 14 and Table 15.

-
-
- - -8.<tab/>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 2 - - -NOTE

This further means that failure to pass the test specified for a part of requirement is a -failure to pass the requirement.

-
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.
- - - -Table 3 - - -NOTE

In the OGC, the enforcement of this requirement and its associated recommendation is the purview of -the OGC Naming Authority or its equivalents.

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

-
- - -8.1.<tab/>Using the model -

The primary difficulty in speaking about standards (or candidate -standards)

This is purposely written as “as not yet adopted” standards, since it is during the authoring process that the ModSpec must be considered, not post facto.

- 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 -must model the standardization target to which they apply since they need to use -unambiguous language to specify requirements. Thus, the only thing they have in -common is that they define testable requirements against some -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 -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 -standard, leading to issues of separate interpretations of the same standard.

-

- - - -

The assumption is that each standard has a single -(root) standardization target type from which all extensions inherit. If this is not -true, then the standard can be logically factored into parts each corresponding -to a “root” standardization target type, and that the standard addresses each -such part separately (see the definition of requirements class in -Clause 4.22). In this sense, the next requirement divides -standard into parts more than restricting their content.

- -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 -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 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 -tested for a particular certificate of conformance. The test may specify other types -as intermediaries or indirect dependencies (see -Clause 4.11).

- -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 -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 -for data transmission. Since the client and server are different standardization -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 -common alternative is to introduce a new “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.
- -
-Figure 1 — Abstract superclass example -
- - -Example — Abstract Superclass - -
- - -8.2.<tab/>The “standards” document -

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

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

-
- - -8.3.<tab/>Conformance Test Suite -

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 -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, -types, elements, or objects are defined and segregated into implementation -requirements 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.

-
- - -8.4.<tab/>Requirements for Modularity - -8.4.1.<tab/>Each Conformance class tests a complete requirements class -Table 17 - - -
REQ009/req/core/no-optional-tests
-A Conformance class SHALL not contain any optional conformance tests.
- -

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 18 - - -
PER007/per/core/conf-class-paramterized
-A Conformance class may be parameterized.
- -

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

- -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 -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 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 -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 -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 -compliant to a particular profile of GML, then that profile of GML will be used to -validate that output. This means that the service is indirectly tested using the GML -standard. In other words, GML is an indirect dependency of the original service.

-
- -

Requirements classes may be optional as a whole, but not piecemeal. This means that -every implementation that passed a particular conformance class satisfies exactly -the same requirements and passes exactly the same conformance tests. Differences -between implementations will be determined by which conformance test classes are -passed, not by listing of which options within a class were tested. If a -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 -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 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 -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 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 -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.4.2.<tab/>Requirements classes contain all requirements tested by a conformance test case -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 -class, it cannot be considered a requirement since no test has been defined for it.

- -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 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 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 -poor design, but they often cannot be avoided because of other considerations (code -ownership for example).

- -Table 27 - - -
REC003/rec/core/circular-dependencies
-Circular dependencies of all types should be avoided whenever possible.
- -Table 28 - - -NOTE

The only certain manner to test this requirement maybe to create a reference -implementation.

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

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 -standardization target). Implementors who wish to sacrifice modularity for some -other benefit can still do what they want; the requirement here only states that if -the software requirements classes are properly separated, they can be implemented in -a “plug’n’play” fashion.

- -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 -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 -or type) are all acceptable, redefinition (of an old class or type) is not.

- -

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 -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.4.3.<tab/>Profiles are defined as sets of conformance classes -

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 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.4.4.<tab/>There is a Defined Core -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 32 - - -
REQ021/req/core/requirements-and-dependencies
-All general recommendations SHALL be in the core.
- -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 34 - - -
REC004/rec/core/simple-core
-The core SHOULD be as simple as possible.
- -Table 35 - - -
PER008/per/core/core-type
-The core MAY be partially or totally abstract.
- -Table 36 - - -
PER009/per/core/req-class-another-standard
-The core requirements class MAY be a conformance class in another standard.
- -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 22.
- -

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

-
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.
- - -
- - -8.4.5.<tab/>Extensions are requirements classes -

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

- -

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

- -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 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 -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 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 -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 -standardization targets to behave in a certain manner when presented with a logical -inconsistency, but that inconsistency must be fundamental to the internal logic of -the model, and not a possible extension. Thus, a standard may require a -standardization target to accept GML as a feature specification language, but cannot -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.4.6.<tab/>Optional requirements are organized as requirements classes -Table 42 - - -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 -they are required by the schema or not.

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

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.4.7.<tab/>Requirements classes intersect overlap only 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 -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 -conformance test class contains tests that all other conformance classes must pass.

-

- - -
-
-
- - -9.<tab/>Mapping this standard to types of models - -9.1.<tab/>Semantics -

The previous section defines requirements for conformance to the ModSpec, but -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 -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].

- -

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.

-
- - -9.2.<tab/>Data Models - -9.2.1.<tab/>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 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. -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.

-
- - -9.2.2.<tab/>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 44 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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 45 - - -
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 - - -A will directly -reference the conformance/requirements class associated to another package - - B - - -B, -if and only if - - A - - -A is dependent on - - B - - -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 46 - - -
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 47 - - -NOTE

External packages having predated the current version of the standard will -not normally have dependencies to packages within the standard.

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

Other dependencies (indirect) will arise from the transitive closure of the above -direct dependencies. That means if - - A - - -A depends on - - B - - -B, and - - B - - -B -depends on - - C - - -C then - - A - - -A depends on - - C - - -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 48 - - -
REQ031/req/core/uml/leaf-model
-A UML leaf package SHALL be associated directly to only one requirements class.
- -Table 49 - - -
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 50 - - -
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 51 - - -
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 33, 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 52 - - - - - - -
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. -

- -

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.

- -

Requirement 3

Statement

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

-
- - -9.2.3.<tab/>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.

-
- -

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.

-

- - - -

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

- -

Requirements may add constraints. This allows extensions to restrict:

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

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

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.

-
- - -9.2.4.<tab/>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. -

- -

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:

- -

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

-
- - -9.2.5.<tab/>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. -

-
-
-
- - - - - - - - - -3.<tab/>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, IECISO/IEC 10000-1ISO/IEC 10000-1 -ISO/IEC DIR 2, ISO/IEC Directives, Part 2. https://www.iso.org/sites/directives/current/part2/index.xhtml.https://www.iso.org/sites/directives/current/part2/index.xhtmlISO/IEC DIR 2ISO/IEC DIR 2 -ISO: ISO 19105, Geographic information — Conformance and testing. International Organization for Standardization, Geneva https://www.iso.org/standard/76457.html.https://www.iso.org/standard/76457.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:76457:enhttps://www.iso.org/contents/data/standard/07/64/76457.detail.rssISO 19105iso-reference ISO 19105(E)URN urn:iso:std:iso:19105:stage-60.60ISO 19105 60 60 -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.https://www.iso.org/standard/32620.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:32620:enhttps://www.iso.org/contents/data/standard/03/26/32620.detail.rssISO/IEC 19501iso-reference ISO/IEC 19501(E)URN urn:iso:std:iso-iec:19501:stage-90.60ISO/IEC 19501 90 60 -OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2, OMG Document Number: formal/2007-11-04, Standard document URL: OMG UML/2.1.2/InfrastructureOMG UML/2.1.2/Infrastructure2.1.2/Infrastructure -OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, OMG Document Number: formal/2007-11-02; Standard document URL: OMG UML/2.1.2/SuperstructureOMG UML/2.1.2/Superstructure2.1.2/Superstructure -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.https://www.iso.org/standard/40833.htmlhttps://www.iso.org/contents/data/standard/04/08/40833.detail.rssISO/IEC 19757-3:2006iso-reference ISO/IEC 19757-3:2006(E)URN urn:iso:std:iso-iec:19757:-3:stage-95.99ISO/IEC 19757-3:2006 95 99 -W3C: W3C xmlschema-1, XML Schema Part 1: Structures Second Edition. World Wide Web Consortium https://www.w3.org/TR/xmlschema-1/.https://www.w3.org/TR/xmlschema-1/W3C xmlschema-1W3C xmlschema-1 Recommendation -W3C: W3C xmlschema-2, XML Schema Part 2: Datatypes Second Edition. World Wide Web Consortium https://www.w3.org/TR/xmlschema-2/.https://www.w3.org/TR/xmlschema-2/W3C xmlschema-2W3C xmlschema-2 Recommendation -
-<strong>Annex A</strong><br/>(normative)<br/><strong>Abstract Conformance Test Suite</strong> - -A.1.<tab/>Conformance Test Class: The Core - -A.1.1.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 2

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.2.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 3

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.3.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 8

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.4.<tab/>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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 10

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.5.<tab/>Conformance test classes have a single target -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 11

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.6.<tab/>Requirements are organized by clauses -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Clause 8.2, Table 14

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.7.<tab/>Conformance test classes are consistent with requirements classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Clause 8.2, Table 15

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.8.<tab/>Requirement classes and the Conformance Test classes in correspondence -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 16

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.9.<tab/>No Optional Elements in Requirements classes -

A Conformance class shall not contain any optional conformance tests.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 17

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.10.<tab/>Certificate of conformance specifies all parameters used -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 19

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.11.<tab/>Conformance class tests only one requirements class -

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

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 20

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.12.<tab/>Conformance class specifies all 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.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 21

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.13.<tab/>Imported Conformance class tests are consistent with the specification -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 22

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.14.<tab/>Naming consistency -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 23

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.15.<tab/>Requirements in one and only one requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 24

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.16.<tab/>Co-dependent Requirements are in the same requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 26

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.17.<tab/>Modularity in implementation is possible -

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.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 28

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.18.<tab/>Requirements follow rules of inheritance -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 29

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.19.<tab/>Profiles are expressed as sets of conformance classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 30

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.20.<tab/>There is a named Core requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 31

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.21.<tab/>General conditions are in the core -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 33

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.22.<tab/>Every extension has a consistent target type -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 33

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.23.<tab/>A standard is a core plus some number of extensions -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 39

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.24.<tab/>Conformance to this ModSpec is required for any 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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 40

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.25.<tab/>Future extensions cannot be restricted -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 41

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.26.<tab/>Optional requirements are organized as requirements classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 42

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.1.27.<tab/>Requirements classes intersect overlap only by reference -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 43

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -A.2.<tab/>Conformance test class: UML model extends The Standard - -A.2.1.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 45

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.2.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 46

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.3.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 47

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.4.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 48

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.5.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 49

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.6.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 50

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.7.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 51.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.8.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Table 52.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.9.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 1.

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.10.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 2

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.2.11.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 3

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -A.3.<tab/>Conformance test class: XML schema extends The Specification - -A.3.1.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 4

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.3.2.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 5

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.3.3.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 6

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.3.4.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 7

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.3.5.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 8

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.3.6.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 9

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -A.4.<tab/>Conformance test class: Schematron - -A.4.1.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 10

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.4.2.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 11

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.4.3.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 12

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.4.4.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 13

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.4.5.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 14

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.4.6.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 15

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -A.5.<tab/>Conformance Class: XML meta-schema - -A.5.1.<tab/>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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 16

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A.5.2.<tab/>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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: Requirement 17

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
-
-<strong>Annex B</strong><br/>(normative)<br/><strong>OGC Only: Changes required in the OGC Standards</strong> -NOTE

The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards

-
- - -B.1.<tab/>New OGC standards and revisions to existing OGC standards -

Any new standard, specification, or major revision of an existing standard SHALL -comply with the ModSpec in the structure of its internal models and its -conformance tests.

- -

Failure to conform by a candidate standard to the ModSpec should be specifically -noted and reasons given for such non-compliance in the conformance clauses of any -new or new version of such candidate standards.

- -

The adoption of such documents not compliant with the ModSpec shall be -considered as an authorized exception to the requirements of the ModSpec by the -approporiate authority, such as the OGC or ISO. The adoption of such -documents not compliant with the ModSpec shall be considered as an exception to -the requirements of the ModSpec by the authority (OGC) and shall be considered as an exception -to the rules of the authority such as the OGC and will require a two-thirds (2/3) majority (“Robert’s -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 Planning Committee or as specified -in any Policy and Procedure document used by this committee.

-
-
-<strong>Annex C</strong><br/>(informative)<br/><strong>Definitions</strong> - -C.1.<tab/>Semantically ordered definitions -

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 -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. -
  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. -
  5. a conformance test (Clause 4.4) 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.

    -
  6. -
  7. all conformance tests (Clause 4.4) are graded as pass or fail -against each instance of the standardization target (Clause 4.26).

    -
  8. -
  9. a requirement (Clause 4.21) is associated to one conformance test (Clause 4.4).

    -
  10. -
  11. a recommendation (Clause 4.20) is a suggestion and is not associated to any -conformance test (Clause 4.4).

    -
  12. -
  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. -
  15. a conformance (test) class (Clause 4.7) is a collection of -conformance tests (Clause 4.4) that are associated to and only to the -requirements in a corresponding requirements class (Clause 4.22).

    -
  16. -
  17. a conformance (test) module (Clause 4.6) 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 -standardization target type (Clause 4.27).

    -
  18. -
  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.7) and received a certificate of conformance (Clause 4.3)

    -
  20. -
  21. the core requirements class (Clause 4.9) 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. -
  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) -must identify all its dependencies during the execution of conformance tests -against a candidate standardization target (Clause 4.26).

    -
  24. -
-
- - -C.2.<tab/>UML Model -
-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 -class diagram.

-
- - -C.3.<tab/>Specification - - - -C.4.<tab/>Specification -

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 -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.<tab/>Conformance Suite - - - -C.6.<tab/>Conformance Class - - - -C.7.<tab/>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 -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. -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.<tab/>Requirements class - - - -C.9.<tab/>RequirementsClass -

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. -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.<tab/>Requirements module - - - -C.11.<tab/>RequirementsModule -

A requirements modules (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 -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.<tab/>Normative Statement - - - -C.13.<tab/>NormativeStatement -

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.<tab/>Requirement - - - -C.15.<tab/>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 -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.<tab/>Recommendation - - - -C.17.<tab/>Recommendation -

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 -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 -logical designs that may implement the requirements in the same module.

    -
  • -
- -

Regardless of their use, Recommendations are not tested since they are not -required of all conformant implementations.

-
- - -C.18.<tab/>Conformance test - - - -C.19.<tab/>ConformanceTest -

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 -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.<tab/>StandardizationTarget - - - -C.21.<tab/>StandardizationTarget -

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.<tab/>StandardizationTargetType - - - -C.23.<tab/>StandardizationTargetType - -
-Bibliography -

To preserve a unique numeric identifier for all documents listed as references in -this standard, the numbering of references in this annex is continued from the list -of normative reference in Clause 3.

ISO/IEC: ISO/IEC 9075:2003, ISO/IEC JTC 1, ISO/IEC 9075:2003 — Information Technology — Database Languages — SQL.. ISO, IEC (2003).[1]ISO/IEC 9075:2003ISO/IEC 9075:2003[1]ISO/IEC: ISO/IEC TR 10000, ISO/IEC TR 10000: Information Technology — Framework and taxonomy of International Standardized Profiles. ISO, IEC[2]ISO/IEC TR 10000ISO/IEC TR 10000[2]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.https://www.iso.org/standard/38651.htmlhttps://www.iso.org/contents/data/standard/03/86/38651.detail.rss[3]ISO/IEC 13249-3:2006iso-reference ISO/IEC 13249-3:2006(E)URN urn:iso:std:iso-iec:13249:-3:stage-95.99ISO/IEC 13249-3:2006 95 99 [3] - Object Management Group (OMG), February 2007, Unified Modeling Language: Infrastructure , version 2.1.1 , formal/07-02-06, available from OMG.org at [4] - OMG UML/2.1.1/InfrastructureOMG UML/2.1.1/Infrastructure - 2.1.1/Infrastructure -[4] - Object Management Group (OMG), February 2007, Unified Modeling Language: Superstructure, version 2.1.1 , formal/07-02-05, available from OMG.org at [5] - OMG UML/2.1.1/SuperstructureOMG UML/2.1.1/Superstructure - 2.1.1/Superstructure -[5]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/.http://www.w3.org/TR/xmlschema11-1/[6]W3C xmlschema11-1W3C xmlschema11-1 Working Draft [6]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/.http://www.w3.org/TR/xmlschema11-2/[7]W3C xmlschema11-2W3C xmlschema11-2 Working Draft [7] - - - - - - - - - - -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.

John Herring: OGC 08-079, OWS5: OGC Web feature service, core and extensions. Open Geospatial Consortium (2008).https://portal.ogc.org/files/?artifact_id=28176[8]OGC 08-079OGC 08-079[8]ISO: ISO 19101, Geographic information — Reference model. International Organization for Standardization, Geneva https://www.iso.org/standard/26002.html.https://www.iso.org/standard/26002.htmlhttps://www.iso.org/contents/data/standard/02/60/26002.detail.rss[9]ISO 19101iso-reference ISO 19101(E)URN urn:iso:std:iso:19101:stage-95.99ISO 19101 95 99 [9]ISO: ISO 19107, Geographic information — Spatial schema. International Organization for Standardization, Geneva https://www.iso.org/standard/66175.html.https://www.iso.org/standard/66175.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:66175:enhttps://www.iso.org/contents/data/standard/06/61/66175.detail.rss[10]ISO 19107iso-reference ISO 19107(E)URN urn:iso:std:iso:19107:stage-90.20ISO 19107 90 20 [10]ISO: ISO 19111, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva https://www.iso.org/standard/74039.html.https://www.iso.org/standard/74039.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:74039:enhttps://www.iso.org/contents/data/standard/07/40/74039.detail.rss[11]ISO 19111iso-reference ISO 19111(E)URN urn:iso:std:iso:19111:stage-90.92ISO 19111 90 92 [11]ISO: ISO 19119, Geographic information — Services. International Organization for Standardization, Geneva https://www.iso.org/standard/59221.html.https://www.iso.org/standard/59221.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:59221:enhttps://www.iso.org/contents/data/standard/05/92/59221.detail.rss[12]ISO 19119iso-reference ISO 19119(E)URN urn:iso:std:iso:19119:stage-90.93ISO 19119 90 93 [12]ISO: ISO 19125, Geographic information — Simple features. ISO[13]ISO 19125ISO 19125[13]ISO: ISO 19133, Geographic information — Location-based services — Tracking and navigation. International Organization for Standardization, Geneva https://www.iso.org/standard/32551.html.https://www.iso.org/standard/32551.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:32551:enhttps://www.iso.org/contents/data/standard/03/25/32551.detail.rss[14]ISO 19133iso-reference ISO 19133(E)URN urn:iso:std:iso:19133:stage-90.93ISO 19133 90 93 [14]ISO: ISO 19136, Geographic information — Geography Markup Language (GML). International Organization for Standardization, Geneva https://www.iso.org/standard/32554.html.https://www.iso.org/standard/32554.htmlhttps://www.iso.org/contents/data/standard/03/25/32554.detail.rss[15]ISO 19136iso-reference ISO 19136(E)URN urn:iso:std:iso:19136:stage-95.99ISO 19136 95 99 [15]ISO: ISO 19141, Geographic information — Schema for moving features. International Organization for Standardization, Geneva https://www.iso.org/standard/41445.html.https://www.iso.org/standard/41445.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:41445:enhttps://www.iso.org/contents/data/standard/04/14/41445.detail.rss[16]ISO 19141iso-reference ISO 19141(E)URN urn:iso:std:iso:19141:stage-90.93ISO 19141 90 93 [16]ISO: ISO 19142, Geographic information — Web Feature Service. International Organization for Standardization, Geneva https://www.iso.org/standard/42136.html.https://www.iso.org/standard/42136.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:42136:enhttps://www.iso.org/contents/data/standard/04/21/42136.detail.rss[17]ISO 19142iso-reference ISO 19142(E)URN urn:iso:std:iso:19142:stage-90.93ISO 19142 90 93 [17]ISO: ISO 19143, Geographic information — Filter encoding. International Organization for Standardization, Geneva https://www.iso.org/standard/42137.html.https://www.iso.org/standard/42137.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:42137:enhttps://www.iso.org/contents/data/standard/04/21/42137.detail.rss[18]ISO 19143iso-reference ISO 19143(E)URN urn:iso:std:iso:19143:stage-90.93ISO 19143 90 93 [18]ISO: ISO 19148, Geographic information — Linear referencing. International Organization for Standardization, Geneva https://www.iso.org/standard/75150.html.https://www.iso.org/standard/75150.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:75150:enhttps://www.iso.org/contents/data/standard/07/51/75150.detail.rss[19]ISO 19148iso-reference ISO 19148(E)URN urn:iso:std:iso:19148:stage-60.60ISO 19148 60 60 [19]ISO: ISO 19149, Geographic information — Rights expression language for geographic information — GeoREL. International Organization for Standardization, Geneva https://www.iso.org/standard/32567.html.https://www.iso.org/standard/32567.htmlhttps://www.iso.org/contents/data/standard/03/25/32567.detail.rss[20]ISO 19149iso-reference ISO 19149(E)URN urn:iso:std:iso:19149:stage-95.99ISO 19149 95 99 [20]ISO: ISO 19153, Geospatial Digital Rights Management Reference Model (GeoDRM RM). International Organization for Standardization, Geneva https://www.iso.org/standard/32571.html.https://www.iso.org/standard/32571.htmlhttps://www.iso.org/contents/data/standard/03/25/32571.detail.rss[21]ISO 19153iso-reference ISO 19153(E)URN urn:iso:std:iso:19153:stage-95.99ISO 19153 95 99 [21]ISO: ISO 19156, Geographic information — Observations, measurements and samples. International Organization for Standardization, Geneva https://www.iso.org/standard/82463.html.https://www.iso.org/standard/82463.htmlhttps://www.iso.org/obp/ui/en/#!iso:std:82463:enhttps://www.iso.org/contents/data/standard/08/24/82463.detail.rss[22]ISO 19156iso-reference ISO 19156(E)URN urn:iso:std:iso:19156:stage-60.60ISO 19156 60 60 [22] - - - - - - - - - - - - - - - - -
-
-
diff --git a/sources/document.xml b/sources/document.xml deleted file mode 100644 index 09d9a7c..0000000 --- a/sources/document.xml +++ /dev/null @@ -1,3889 +0,0 @@ - - - -The ModSpec Model - A Standard for Designing and Writing Modular Standards -08-131r308-131r32029-11-012029-11-012024-11-16 -TBD - -Carl Reed, John Herring - -Open Geospatial Consortium -OGC1.1.0enDraft2024 -Open Geospatial Consortium -OGCdraft-standardconceptual-modeltechnicalTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2 - - - -Copyright notice -

Copyright © 2024 Open Geospatial Consortium
-To obtain additional rights of use, visit -

-
- - -Note -

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

-
-
- - - - -License Agreement -

Use of this document is subject to the license agreement at

-
-
- - - - -Notice -

This document is not an OGC Standard. This document is an OGC Draft Standard and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard.

- -

Further, an OGC Draft Standard should not be referenced as required or mandatory technology in procurements.

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

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.

-

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 -() or by creating an issue in the GitHub repository for this document ().

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

-
-Document editors -

The following OGC Members participated in editing this document:

- - - - - - -
PersonOrganization Represented
Carl ReedCarl Reed & Associates
-
-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
-
-Revision history -

This is the second normative version of this document.

-
-Future work -

Improvements to this document will be made based on implementation and changing technical requirements. Planned extensions include:

- -
  • ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using RDFS, SHACL, and OWL.

    -
  • -
  • ModSpec Part providing requirements and recommendations for specifying requirements and conformance tests using JSON.

    -
  • -
-
-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, -and the Conformance Test Suite ).

- -

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.

-
-Introduction -

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

-
- -

This OGC document, also known as the ModSpec:

- -
  • Specifies rules for the internal structure and organization of a standard.

    -
  • -
  • Defines requirements for specifying the structure of a standards document as organized sets of criteria, those that are to be tested (“requirements”) and those that are not tested (“recommendations” and “permissions”).

    -
  • -
  • Designed to enable the clear and concise specification of requirements (the shalls or musts in a standard) that fully supports the ability to define implementable conformance tests.

    -
  • -
- -

The goal of this approach is to enable implementations of a standard to be tested and deemed conformant or not.

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.

-
-Acknowledgements -

The following OGC Members were key contributors to Version 1 of the ModSpec

- - - - - - - - - - - - - - - - - - - - - - -
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
-
- Security considerations -

No security considerations have been made for this document.

-
- - - - - - - - - - - - - - - - -Scope -

The ModSpec defines characteristics and structure for the specification of Standards -that will encourage implementation by minimizing difficulty determining -requirements, mimicking implementation structure and maximizing usability and -interoperability.

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.

-

- - - -

defines the UML model upon which the ModSpec is -based. Annex B 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.

-
- - -Conformance -

Conformance to the ModSpec by technical implementation standards -can be tested by inspection. The test suite is in .

- -

There are five (5) conformance classes for this document:

- -
  1. Standards documents in general (the core) — see and

    -
  2. -
  3. Standards using UML to state requirements, extending the core — see - and

    -
  4. -
  5. Standards using XML schema to state requirements, extending the core — see - and

    -
  6. -
  7. Standards using Schematron to state requirements, extending XML schema — see - and

    -
  8. -
  9. 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 and .

    -
  10. -
- -

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:

- -
  • specifies the core requirements which shall be met by all conformant -standards.

    -
  • -
  • gives information on how the ModSpec is to be applied to requirements, -conformance clauses, UML models, or XML Schemas.

    -
  • -
- -

The various subclauses of list requirements partially derived from the -core, but more specific to the conditions where a data model expressed in one of the -specified languages (UML or XML) is involved. These requirements classes are -extensions of the core presented in .

-
- - - - -Terms and definitions - -

For the purposes of this document, the following terms and definitions shall apply. -Terms not defined here take their meaning from computer science or from their -Standard English (common US and UK) meanings. The form of the definitions is -defined by ISO Directives.

- -

Many of these definitions depend upon the model given in .

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

-
- - -building block - - -

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

-
- - -certificate of conformance - - -

evidence of conformance to all or part of a standard, awarded for passing one or -more of the conformance test classconformance test classes specified in -that standard

- - -

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

- -

Each certificate of conformance is awarded to a standardization targetstandardization target.

-
- - -conformance test - - -

test, abstract or real, of a single requirementrequirements contained -within a standard, or set of standards

-
- - -conformance test case - - -

test for a particular requirement or a set of related requirements

- - -

When no ambiguity, the word “case” may be omitted. i.e. -conformance testconformance test is the same as -conformance test caseconformance test case.

-
- - -conformance test module - - -

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

- - - - -

When there is no ambiguity, the word “test” may be omitted. i.e. conformance test moduleconformance test module -is the same as conformance module. Conformance modules may be nested in a hierarchical way.

-
- - -conformance test class - - -conformance test level - - - - - -

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

- - -

When no ambiguity is possible, the word “test” may be left out, so conformance test classconformance test class -maybe called a conformance class.

- -

In the ModSpec, the set of requirementrequirements tested by the -conformance tests within a conformance class is a -requirements classrequirements class and its dependencies. Optional requirementrequirements will -be in a separate requirements classrequirements class with other requirementrequirements -that are part of the same option. Each requirements classrequirements class 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 classrequirements class’s requirementrequirements.

- -

All requirementrequirements in a conformance class -will have the same standardization targetstandardization target.

-
- - -conformance suite - - -conformance test suite - - -abstract test suite - - - - - - - -

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

- - -

The conformance suiteconformance suite 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 requirementrequirement is mandatory within its conformance class and each requirementrequirement is tested in at least one conformance testconformance test.

-
- - -core requirements class - - -

unique requirements classrequirements class that must be satisfied by any conformant -standardization targetstandardization targets associated to the -standard

- - -

The core requirements classrequirements 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 classconformance test class, and thus would have to be contained in any other -core. The core may be empty, or all or part of another standard or related -set of standards.

- -

The “core” can refer to this requirements classrequirements class, its associated -conformance test classconformance test class or the software module that implements that -requirements class.

-
- - -direct dependency (of a requirements class) - - -

another requirements classrequirements class (the dependency) whose requirementrequirements are defined to also be -requirementrequirements of this -requirements classrequirements class

- - -

A direct dependency (of a requirements class) direct dependency -of the current requirements classrequirements class will have the same -standardization targetstandardization target as the current -requirements classrequirements class. This is another ways of saying that the current -requirements classrequirements class extends, or uses all the aspects of the -direct dependency (of a requirements class) direct dependency. -Any tests associated with this -direct dependency (of a requirements class)dependency can be applied to this -requirements classrequirements class.

- -

When testing a -direct dependency (of a requirements class) direct dependency, the -standardization targetstandardization target is directly subject to the test in the specified -conformance test classconformance test class of the direct dependency (of a requirements class) direct dependency.

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

requirements classrequirements class with a different -standardization targetstandardization target which is used, produced or associated to by the -implementation of this requirements classrequirements class

- - -

In this instance, as opposed to the -direct dependency (of a requirements class)direct dependency, -the test against the consumable or product used -or produced by the requirements classrequirements class does not directly test the -requirements classrequirements class, but tests only its side effects. Hence, a particular -type of feature service could be required to produce valid XML documents, but -the test of validity for the XML document is not directly testing the service, -but only indirectly testing the validity of its output. -direct dependency (of a requirements class) Direct dependencies -test the same standardization targetstandardization target, but -indirect dependency (of a requirements class) indirect dependencies -test related but different standardization targetstandardization 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 conformancecertificate of conformance of a particular kind.

-
- - -extension (of a requirements class) - - -

requirements classrequirements class which has a -direct dependency (of a requirements class) direct dependency on another -requirements classrequirements class

- - -

Here extension (of a requirements class)extension is -defined on requirements classrequirements class so that their implementation may be -software extensions in a manner analogous to the extension relation between the -requirements classrequirements classes.

-
- - -general recommendation - - -

recommendation applying to all entities in a standard

-
- - -home (of a requirement or recommendation) - - -

official statement of a requirementrequirement or recommendationrecommendation that is the -precedent for any other version repeated or rephrased elsewhere in a standard

- - -

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.

-
- - -model - - -abstract model - - -conceptual model - - - - - - - -

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

-
- - -module - - -

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

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

-
- - -permission - - -

uses “may” and is used to prevent a requirement from being “over interpreted” and as such is considered to be more -of a “statement of fact” than a “normative” condition.

-
- - -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 classconformance test classes, -conforming subsets, options and parameters of those base standards, or -profiles necessary to accomplish a particular function.

- - - - -

In the usage of this Policy, a profile will be a set of requirements classes -or conformance classes (either preexisting or locally defined) of the base -standards.

- -

This means that a standardization targetstandardization target being conformant to a profile -implies that the same target is conformant to the standards referenced in the -profileprofile.

-
- - -recommendation - - -

expression in the content of a standard conveying that among several -possibilities one is recommended as particularly suitable, without mentioning or -excluding others, or that a certain course of action is preferred but not -necessarily required, or that (in the negative form) a certain possibility or -course of action is deprecated but not prohibited

- - - - - - -

Although using normative language, a recommendationrecommendation is not -a requirementrequirement. The usual form replaces the “shall” (imperative or -command) of a requirementrequirement with a “should” (suggestive or -conditional).

-

Recommendations are not tested and therefor have no related conformance test.

-
- - -requirement - - -

expression in the content of a standard conveying criteria to be fulfilled if -compliance with the standard is to be claimed and from which no deviation is permitted

- - - - -

Each requirementrequirement is a normative criterion for a single -type of standardization target. In the ModSpec, requirements are -associated to conformance test conformance tests that can be used to prove -compliance to the underlying criteria by the standardization targetstandardization target.

- -

The implementation of a requirementrequirement 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 requirementrequirements allows us to -use set descriptions of both the standard and its implementations.

- -

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

-
- - -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 classconformance test class

- - -

There is some confusion possible here, since the testing of indirect -dependencies seems to violate this definition. But the existence of an indirect -dependency implies that the test is actually a test of the existence of the -relationship from the original target to something that has a property -(satisfies a condition or requirement from another requirements class).

-
- - -requirements module - - -

collection of term requirement class, display requirements classes not resolved via ID requirement-class, -recommendationrecommendations and permissionpermissions with a -single standardization targetstandardization target

-
- - -specification - - -

document containing recommendationrecommendations, -requirementrequirements and conformance test conformance tests for -those requirementrequirements

- - -

This definition is included for completeness. See .

- -

This does not restrict what else a standard may contain, as long as it does -contain the three types of element cited.

-
- - -standard - - -

document that has been approved by a legitimate Standards Body

- - -

This definition is included for completeness. standardStandard and -specificationspecification can apply to the same document. While specificationspecification is -always valid, standardstandard only applies after the adoption of the document by a -legitimate standards organization.

-
- - -standardization target - - -

entity to which some requirementrequirements of a standardstandard apply

- - - - -

The standardization targetstandardization target is the entity which may receive a -certificate of conformancecertificate of conformance for a requirements classrequirements class.

-

Need to add examples! The standardization target of the CDB version 2.0 CRS Requirements Classes is to ensure that an implementation clearly defines (with metadata) the CRS for a CDB compliant datastore.

-
- - -standardization target type - - -

type of entity or set of entities to which the requirementrequirements of a -standardstandard apply

- - -

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.

-
- - -statement - - -

expression in a document conveying information

- - - - -

Includes all statements in a document not part of the normative -requirementrequirements, -recommendationrecommendations or -conformance test conformance tests. Included for completeness.

-
-
- - -Conventions - -Symbols (and abbreviated terms) -

All symbols used in this document are either:

- -
  1. Common mathematical symbols

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

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

- -

- -

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:

- -

- -

An example might be:

- -

/req/core/crs

- -

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

- -

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

- -

- -

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

-
- - -Abbreviated terms -

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

- -
ERA

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

-
-
ISO

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

-
-
OCL

Object Constraint Language (part of UML)

-
-
OGC

Open Geospatial Consortium ()

-
-
OMG

Object Management Group ()

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

-
-
- -Finding requirements and recommendations -

Each normative statement in the ModSpec is stated in one and only one place, -in a standard format, and has 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 abstract test suite -in . The reference to the requirement in the test case is done by a -requirements label (in the form “Req #”, where “#” is a number) associated to -the home of the statement described above. 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 -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.

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

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

    -
  4. -
  5. All requirements, recommendations, permissions, and models are introduced and defined first in -the numbered Clauses.

    -
  6. -
  7. All requirements are identifiable as requirements.

    -
  8. -
  9. All requirements in a document are uniquely numbered.

    -
  10. -
  11. All tests for conformance to those requirements are defined in the Conformance Test Suite.

    -
  12. -
  13. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.

    -
  14. -
  15. The tests, if conducted, determine to some degree of certainty whether an -implementation meets the requirements which the tests reference.

    -
  16. -
  17. 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”.

    -
  18. -
  19. Certificates of conformance (see ) are -awarded by a testing entity based on these conformance classes.

    -
  20. -
  21. There is a clear distinction between normative and informative parts of the text.

    -
  22. -
  23. Examples and notes are informative, and do not use “normative” -language.

    -
  24. -
- -

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

- -

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

- -

A UML representation of important properties of this model is given in .

-
- - -ModSpec document structure -

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

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

    -
  • -
-
- - -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. -
  3. A building block may interoperate with other, inter-dependent, building blocks.

    -
  4. -
  5. A good building block has the following characteristics:

    -
    1. Considers implementation and usage, and evolves to exploit technology and standards.

      -
    2. -
    3. May be assembled from other building blocks.

      -
    4. -
    5. May be a subassembly of other building blocks.

      -
    6. -
    7. Ideally a building block is re-usable and replaceable, and well specified.

      -
    8. -
    -
  6. -
  7. A building block may have multiple implementations but with different inter-dependent building blocks.

    -
  8. -
- -

These characteristics are slightly modified from the Open Group definitions to accommodate the use of the building block concept in standards work.

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.

-

- - -
- - -Standardization Context — Goals and Targets -

Every OGC Standard shall include a Standardization Goal. This is a concise statement of the problem that the Standard will help 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: -• 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 – 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 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 our standards to quickly understand the scope of a Standard and to select those Standards appropriate for their needs. It also will help keep Standards developers focused on the intended use of their standards, avoiding standards which are overly broad and/or unfocused.

-
- - -Conformance, Requirements, and key information -

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

- -

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

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

- - - - -

This further means that failure to pass the test specified for a part of requirement is a -failure to pass the requirement.

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

In the OGC, the enforcement of this requirement and its associated recommendation is the purview of -the OGC Naming Authority or its equivalents.

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

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

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

- - - - -
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.
- - - - -
PER004/per/core/external-vocabs-core
-Importation of external vocabularies and schemas MAY be in the core.
- -

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.

-
- - -Using the model -

The primary difficulty in speaking about standards (or candidate -standards)

This is purposely written as “as not yet adopted” standards, since it is during the authoring process that the ModSpec must be considered, not post facto.

- 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 -must model the standardization target to which they apply since they need to use -unambiguous language to specify requirements. Thus, the only thing they have in -common is that they define testable requirements against some -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.

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 -standard, leading to issues of separate interpretations of the same standard.

-

- - - -

The assumption is that each standard has a single -(root) standardization target type from which all extensions inherit. If this is not -true, then the standard can be logically factored into parts each corresponding -to a “root” standardization target type, and that the standard addresses each -such part separately (see the definition of requirements class in -). In this sense, the next requirement divides -standard into parts more than restricting their content.

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

- - - - -
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 -tested for a particular certificate of conformance. The test may specify other types -as intermediaries or indirect dependencies (see -).

- - - - -
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 -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 -for data transmission. Since the client and server are different standardization -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 -common alternative is to introduce a new “superclass”.

- - - - -
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 .
- -
-Abstract superclass example -
- - -Abstract Superclass - -
- - -The “standards” document -

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

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

-
- - -Conformance Test Suite -

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.

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, -types, elements, or objects are defined and segregated into implementation -requirements classes.

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

-
- - -Requirements for Modularity - -Each Conformance class tests a complete requirements class - - - -
REQ009/req/core/no-optional-tests
-A Conformance class SHALL not contain any optional conformance tests.
- -

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.

- - - - -
PER007/per/core/conf-class-paramterized
-A Conformance class may be parameterized.
- -

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

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

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

- - - - -
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 -conformance class of another standard.

- - -Indirect dependency on schema -

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 -compliant to a particular profile of GML, then that profile of GML will be used to -validate that output. This means that the service is indirectly tested using the GML -standard. In other words, GML is an indirect dependency of the original service.

-
- -

Requirements classes may be optional as a whole, but not piecemeal. This means that -every implementation that passed a particular conformance class satisfies exactly -the same requirements and passes exactly the same conformance tests. Differences -between implementations will be determined by which conformance test classes are -passed, not by listing of which options within a class were tested. If a -standard’s authors wish to make a particular requirement optional, -forces them to include it in a separate requirements class (and therefore in a -separate conformance test class) which can be left untested.

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.

-

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

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

-
- - -Requirements classes contain all requirements tested by a conformance test case - - - - - - - -
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 -class, it cannot be considered a requirement since no test has been defined for it.

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

- - - - - - - - -
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 -poor design, but they often cannot be avoided because of other considerations (code -ownership for example).

- - - - -
REC003/rec/core/circular-dependencies
-Circular dependencies of all types should be avoided whenever possible.
- - - - -

The only certain manner to test this requirement maybe to create a reference -implementation.

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

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 -standardization target). Implementors who wish to sacrifice modularity for some -other benefit can still do what they want; the requirement here only states that if -the software requirements classes are properly separated, they can be implemented in -a “plug’n’play” fashion.

- - - - -
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 -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 -or type) are all acceptable, redefinition (of an old class or type) is not.

- -

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 -purposes. However, it is not possible to write a standard “by example” that -leads to conformance tests. Examples are therefore non-normative, by definition.

-
- - -Profiles are defined as sets of conformance classes -

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 -). The base for creating a profile can be defined as the union of all -requirements classes.

- - - - -
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.
-
- - -There is a Defined Core - - - -
REQ020/req/core/core-requirements-separate
-Every standard SHALL define and identify a core set of requirements as a -separate conformance class.
- - - - -
REQ021/req/core/requirements-and-dependencies
-All general recommendations SHALL be in the core.
- - - - - - - - -
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.
- - - - -
REC004/rec/core/simple-core
-The core SHOULD be as simple as possible.
- - - - -
PER008/per/core/core-type
-The core MAY be partially or totally abstract.
- - - - -
PER009/per/core/req-class-another-standard
-The core requirements class MAY be a conformance class in another standard.
- - - - -
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 .
- -

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.

- - - - -

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

-
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.
- - -
- - -Extensions are requirements classes -

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

- -

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

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

- - - - -
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 -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 -standardization targets to behave in a certain manner when presented with a logical -inconsistency, but that inconsistency must be fundamental to the internal logic of -the model, and not a possible extension. Thus, a standard may require a -standardization target to accept GML as a feature specification language, but cannot -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.

-
- - -Optional requirements are organized as requirements classes - - - -

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 -they are required by the schema or not.

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

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.

-
- - -Requirements classes intersect overlap only by reference - - - -
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 -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 .

All general recommendations are in the core requirements class. The core -conformance test class contains tests that all other conformance classes must pass.

-

- - -
-
-
- - -Mapping this standard to types of models - -Semantics -

The previous section defines requirements for conformance to the ModSpec, but -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 -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 .

- -

As suggested in Clause , the structure of the normative clauses in a -standard should parallel the structure of the conformance test classes in -that standard. The structure of the normative clauses in a well written -standard will follow the structure of its model. This means that all three are -parallel.

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

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

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

- - - - -
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 - - -A will directly -reference the conformance/requirements class associated to another package - - B - - -B, -if and only if - - A - - -A is dependent on - - B - - -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.

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

External packages having predated the current version of the standard will -not normally have dependencies to packages within the standard.

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

Other dependencies (indirect) will arise from the transitive closure of the above -direct dependencies. That means if - - A - - -A depends on - - B - - -B, and - - B - - -B -depends on - - C - - -C then - - A - - -A depends on - - C - - -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.

- - - - -
REQ031/req/core/uml/leaf-model
-A UML leaf package SHALL be associated directly to only one requirements class.
- - - - -
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.

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

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

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

- -

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.

-
- -

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

-
- -

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.

- -

The UML model SHALL segregate all classes into leaf packages.

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

- -

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

-
- -

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.

- -

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.

-
- -

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.

- -

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.

-
- -

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.

- -

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.

-
- -

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.

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.

-

- - - -

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.

-
- -

Requirements may add constraints. This allows extensions to restrict:

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

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

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.

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

Schematron () 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.

- -

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.

-
- -

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

-
- -

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

-
- -

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

-
- -

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

-
- -

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

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

- -

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.

- -

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.

-
-
-
-
- - - - - - - - -
-Abstract Conformance Test Suite - -Conformance Test Class: The Core - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Conformance test classes have a single target -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Requirements are organized by clauses -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: ,

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Conformance test classes are consistent with requirements classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: ,

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Requirement classes and the Conformance Test classes in correspondence -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -No Optional Elements in Requirements classes -

A Conformance class shall not contain any optional conformance tests.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Certificate of conformance specifies all parameters used -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Conformance class tests only one requirements class -

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

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Conformance class specifies all 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.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Imported Conformance class tests are consistent with the specification -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Naming consistency -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Requirements in one and only one requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Co-dependent Requirements are in the same requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Modularity in implementation is possible -

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.

- -
  1. Test Purpose: Verify that this requirement is satisfied.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Requirements follow rules of inheritance -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Profiles are expressed as sets of conformance classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -There is a named Core requirements class -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -General conditions are in the core -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Every extension has a consistent target type -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -A standard is a core plus some number of extensions -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Conformance to this ModSpec is required for any 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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Future extensions cannot be restricted -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Optional requirements are organized as requirements classes -

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.

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -Requirements classes intersect overlap only by reference -

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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -Conformance test class: UML model extends The Standard - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: .

    -
  6. -
  7. Test Type: Conformance.

    -
  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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: .

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference: .

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -Conformance test class: XML schema extends The Specification - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -Conformance test class: Schematron - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
- - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
- - -Conformance Class: XML meta-schema - -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. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

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

    -
  2. -
  3. Test Method: Inspect the document to verify the above.

    -
  4. -
  5. Reference:

    -
  6. -
  7. Test Type: Conformance.

    -
  8. -
-
-
-
-OGC Only: Changes required in the OGC Standards -

The following is for OGC Standards and Abstract Specifications only: No changes are required to existing OGC Standards

-
- - -New OGC standards and revisions to existing OGC standards -

Any new standard, specification, or major revision of an existing standard SHALL -comply with the ModSpec in the structure of its internal models and its -conformance tests.

- -

Failure to conform by a candidate standard to the ModSpec should be specifically -noted and reasons given for such non-compliance in the conformance clauses of any -new or new version of such candidate standards.

- -

The adoption of such documents not compliant with the ModSpec shall be -considered as an authorized exception to the requirements of the ModSpec by the -approporiate authority, such as the OGC or ISO. The adoption of such -documents not compliant with the ModSpec shall be considered as an exception to -the requirements of the ModSpec by the authority (OGC) and shall be considered as an exception -to the rules of the authority such as the OGC and will require a two-thirds (2/3) majority (“Robert’s -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 Planning Committee or as specified -in any Policy and Procedure document used by this committee.

-
-
-Definitions - -Semantically ordered definitions -

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 typestandardization target type is a type of entity about which a standard -is written. An instance of a standardization target typestandardization target type is a -standardization targetstandardization target. A standard may address multiple targets in separate -conformance classes.

    -
  2. -
  3. a requirementrequirement is a statement of a condition to be satisfied by a single -standardization target typestandardization target type, and it must be stated in “normative” language.

    -
  4. -
  5. a conformance testconformance test checks if a set of -requirementrequirements are met (pass) or not met (fail) by a -standardization targetstandardization target. The relationship between conformance test conformance tests and requirementrequirements is many-to-many.

    -
  6. -
  7. all conformance test conformance tests are graded as pass or fail -against each instance of the standardization targetstandardization target.

    -
  8. -
  9. a requirementrequirement is associated to one conformance testconformance test.

    -
  10. -
  11. a recommendationrecommendation is a suggestion and is not associated to any -conformance testconformance test.

    -
  12. -
  13. a requirements classrequirements class is a set of one or more requirementrequirements -all with the same standardization target typestandardization target type.

    -
  14. -
  15. a conformance test classconformance (test) class is a collection of -conformance testconformance tests that are associated to and only to the -requirements in a corresponding requirements classrequirements class.

    -
  16. -
  17. a conformance test moduleconformance (test) module is also collection of -term conformance test classes not resolved via ID conformance-test-classes that group -conformance test conformance tests on a single -standardization target typestandardization target type.

    -
  18. -
  19. a conformant implementation is a standardization target typestandardization target type that has -successfully passed all tests in a specified conformance test classconformance (test) class and received a certificate of conformancecertificate of conformance

    -
  20. -
  21. the core requirements classcore requirements class of a standard is the minimal set of -requirementrequirements which must be supported by all conformant implementations. If a standard addresses multiple standardization target typestandardization target types, it may have a core for each target type.

    -
  22. -
  23. an extension of a requirements classrequirements class is an additional requirements classrequirements class -(the extension) that adds additional requirementrequirements to the first -requirements classrequirements class (the base requirements class being extended). The -extension is said to be dependent on the base. Any conformance test classconformance test class -must identify all its dependencies during the execution of conformance tests -against a candidate standardization targetstandardization target.

    -
  24. -
-
- - -UML Model -
-Specification structure -
- -

represents a UML model consistent with the specification model described -in . The following subclauses describe the classes shown in this UML -class diagram.

-
- - -Specification - - - -Specification -

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

- - -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
-
- - -Conformance Suite - - - -Conformance Class - - - -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 -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.

- - -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
-
- - -Requirements class - - - -RequirementsClass -

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.

- - -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
-
- - -Requirements module - - - -RequirementsModule -

A requirements modules (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 -conformance test modules.

- - -RequirementsModule attributes - - - - - - - - - - - - - - - - - -
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the requirements module.M1String
requirementsRequirements classes that this requirements module contains.MNRequirement
-
- - -Normative Statement - - - -NormativeStatement -

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

- - -NormativeStatement attributes - - - - - - - - - - - - -
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
nameName of the normative statement.M1String
-
- - -Requirement - - - -Requirement -

Normative statement that constitutes a requirement.

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

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 -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 -logical designs that may implement the requirements in the same module.

    -
  • -
- -

Regardless of their use, Recommendations are not tested since they are not -required of all conformant implementations.

-
- - -Conformance test - - - -ConformanceTest -

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

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

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.

- - -StandardizationTarget attributes - - - - - - - - - - - - - - - - - -
NameDefinitionMandatory / Optional / ConditionalMax OccurData Type
conformanceCertificatesconformance classes passed by this targetONString
typeType of the standardization target type.M1StandardizationTargetType
-
- - -StandardizationTargetType - - - -StandardizationTargetType - -
-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 10000-110000-1 -ISO - -IEC - - 2024-11-17 -ISO/IEC Directives, Part 2 - -Principles and rules for the structure and drafting of ISO and IEC documents - https://www.iso.org/sites/directives/current/part2/index.xhtml ISO/IEC DIR 2 9 en 2021 -International Organization for Standardization - ISO www.iso.org 2024-11-17 -ISO/IEC Directives, Part 2 - -Principles and rules for the structure and drafting of ISO and IEC documents - https://www.iso.org/sites/directives/current/part2/index.xhtml ISO/IEC DIR 2 2021-05-01 9 en 2021 -International Organization for Standardization - ISO www.iso.org - - 2024-11-17 -Geographic information - -Conformance and testing - -Geographic information — Conformance and testing - https://www.iso.org/standard/76457.html https://www.iso.org/obp/ui/en/#!iso:std:76457:en https://www.iso.org/contents/data/standard/07/64/76457.detail.rss ISO 19105 ISO 19105(E) urn:iso:std:iso:19105:stage-60.60 19105 -International Organization for Standardization - ISO www.iso.org 2 en fr 60 60 2022 -ISO - ISO 19105:2000 ISO 19105:2000 - 2024-11-17 -Geographic information - -Conformance and testing - -Geographic information — Conformance and testing - https://www.iso.org/standard/76457.html https://www.iso.org/obp/ui/en/#!iso:std:76457:en https://www.iso.org/contents/data/standard/07/64/76457.detail.rss ISO 19105:2022 ISO 19105:2022(E) urn:iso:std:iso:19105:stage-60.60 19105 2022-07 -International Organization for Standardization - ISO www.iso.org 2 en fr This document specifies the framework, concepts and methodology for conformance testing and criteria to be achieved to claim conformance to the family of applicable standardization documents regarding geographic information and relevant application domains. This document provides a framework for specifying abstract test suites composed of abstract test cases grouped in conformance classes and for defining the procedures to be followed during conformance testing. Conformance can be claimed for data or software products or services or by specifications including any profile or functional standard. The structure of, and relationships between, conformance classes as defined in this document underly a systematic approach to configuration management involving managing dependencies within and between modules. 60 60 2022 -ISO - ISO 19105:2000 ISO 19105:2000 - Geneva - Geneva - 2024-11-17 -Information technology - -Open Distributed Processing - -Unified Modeling Language (UML) Version 1.4.2 - -Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 - https://www.iso.org/standard/32620.html https://www.iso.org/obp/ui/en/#!iso:std:32620:en https://www.iso.org/contents/data/standard/03/26/32620.detail.rss ISO/IEC 19501 ISO/IEC 19501(E) urn:iso:std:iso-iec:19501:stage-90.60 19501 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr 90 60 2005 -ISO/IEC - 2024-11-17 -Information technology - -Open Distributed Processing - -Unified Modeling Language (UML) Version 1.4.2 - -Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 - https://www.iso.org/standard/32620.html https://www.iso.org/obp/ui/en/#!iso:std:32620:en https://www.iso.org/contents/data/standard/03/26/32620.detail.rss ISO/IEC 19501:2005 ISO/IEC 19501:2005(E) urn:iso:std:iso-iec:19501:stage-90.60 19501 2005-04 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr ISO/IEC 19501:2004 describes the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components. 90 60 2005 -ISO/IEC - Geneva - Geneva -OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2, OMG Document Number: formal/2007-11-04, Standard document URL: OMG UML/2.1.2/Infrastructure2.1.2/Infrastructure -OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, OMG Document Number: formal/2007-11-02; Standard document URL: OMG UML/2.1.2/Superstructure2.1.2/Superstructure - 2024-11-17 -Information technology - -Document Schema Definition Languages (DSDL) - -Part 3: Rule-based validation — Schematron - -Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron - https://www.iso.org/standard/40833.html https://www.iso.org/contents/data/standard/04/08/40833.detail.rss ISO/IEC 19757-3:2006 ISO/IEC 19757-3:2006(E) urn:iso:std:iso-iec:19757:-3:stage-95.99 19757 2006-06 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 1 en fr ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. 95 99 2006 -ISO/IEC - ISO/IEC 19757-3:2016 ISO/IEC 19757-3:2016 2016-01-14 - Geneva - 2024-11-17 -XML Schema Part 1: Structures Second Edition - https://www.w3.org/TR/xmlschema-1/ W3C xmlschema-1 xmlschema-1 -World Wide Web Consortium - W3C https://www.w3.org/ en Recommendation W3C REC-xmlschema-1-20010502 https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ W3C REC-xmlschema-1-20010502 - W3C REC-xmlschema-1-20041028 https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ W3C REC-xmlschema-1-20041028 - -W3C REC - xmlschema-1 - 2024-11-17 -XML Schema Part 2: Datatypes Second Edition - https://www.w3.org/TR/xmlschema-2/ W3C xmlschema-2 xmlschema-2 -World Wide Web Consortium - W3C https://www.w3.org/ en Recommendation W3C REC-xmlschema-2-20010502 https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ W3C REC-xmlschema-2-20010502 - W3C REC-xmlschema-2-20041028 https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ W3C REC-xmlschema-2-20041028 - -W3C REC - xmlschema-2 -
-Bibliography -

To preserve a unique numeric identifier for all documents listed as references in -this standard, the numbering of references in this annex is continued from the list -of normative reference in .

-ISO/IEC JTC 1, ISO/IEC 9075:2003 — Information Technology — Database Languages — SQL. -ISO/IEC 9075:200390752003 -ISO - -IEC - -ISO/IEC TR 10000: Information Technology — Framework and taxonomy of International Standardized Profiles -ISO/IEC TR 1000010000 -ISO - -IEC - 2024-11-17 -Information technology - -Database languages - -SQL multimedia and application packages — Part 3: Spatial - -Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial - https://www.iso.org/standard/38651.html https://www.iso.org/contents/data/standard/03/86/38651.detail.rss ISO/IEC 13249-3:2006 ISO/IEC 13249-3:2006(E) urn:iso:std:iso-iec:13249:-3:stage-95.99 13249 2006-11 -International Organization for Standardization - ISO www.iso.org -International Electrotechnical Commission - IEC www.iec.ch 3 en fr ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. 95 99 2006 -ISO/IEC - ISO/IEC 13249-3:2003 ISO/IEC 13249-3:2003 - ISO/IEC 13249-3:2011 ISO/IEC 13249-3:2011 2011-04-07 - Geneva - Object Management Group (OMG), February 2007, Unified Modeling Language: Infrastructure , version 2.1.1 , formal/07-02-06, available from OMG.org at - OMG UML/2.1.1/Infrastructure - 2.1.1/Infrastructure - - Object Management Group (OMG), February 2007, Unified Modeling Language: Superstructure, version 2.1.1 , formal/07-02-05, available from OMG.org at - OMG UML/2.1.1/Superstructure - 2.1.1/Superstructure - 2024-11-17 -W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - http://www.w3.org/TR/xmlschema11-1/ W3C xmlschema11-1 xmlschema11-1 -World Wide Web Consortium - W3C https://www.w3.org/ en Working Draft W3C WD-xmlschema11-1-20040716 http://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/ W3C WD-xmlschema11-1-20040716 - W3C WD-xmlschema11-1-20050224 http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ W3C WD-xmlschema11-1-20050224 - W3C WD-xmlschema11-1-20060330 http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ W3C WD-xmlschema11-1-20060330 - W3C WD-xmlschema11-1-20060831 http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ W3C WD-xmlschema11-1-20060831 - W3C WD-xmlschema11-1-20070830 http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ W3C WD-xmlschema11-1-20070830 - W3C WD-xmlschema11-1-20080620 http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/ W3C WD-xmlschema11-1-20080620 - W3C WD-xmlschema11-1-20090130 http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/ W3C WD-xmlschema11-1-20090130 - W3C CR-xmlschema11-1-20090430 http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ W3C CR-xmlschema11-1-20090430 - W3C WD-xmlschema11-1-20091203 http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/ W3C WD-xmlschema11-1-20091203 - W3C CR-xmlschema11-1-20110721 http://www.w3.org/TR/2011/CR-xmlschema11-1-20110721/ W3C CR-xmlschema11-1-20110721 - W3C PR-xmlschema11-1-20120119 http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ W3C PR-xmlschema11-1-20120119 - -W3C WD - xmlschema11-1 2024-11-17 -W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - http://www.w3.org/TR/xmlschema11-2/ W3C xmlschema11-2 xmlschema11-2 -World Wide Web Consortium - W3C https://www.w3.org/ en Working Draft W3C WD-xmlschema11-2-20040716 http://www.w3.org/TR/2004/WD-xmlschema11-2-20040716/ W3C WD-xmlschema11-2-20040716 - W3C WD-xmlschema11-2-20050224 http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/ W3C WD-xmlschema11-2-20050224 - W3C WD-xmlschema11-2-20060217 http://www.w3.org/TR/2006/WD-xmlschema11-2-20060217/ W3C WD-xmlschema11-2-20060217 - W3C WD-xmlschema11-2-20080620 http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/ W3C WD-xmlschema11-2-20080620 - W3C WD-xmlschema11-2-20090130 http://www.w3.org/TR/2009/WD-xmlschema11-2-20090130/ W3C WD-xmlschema11-2-20090130 - W3C CR-xmlschema11-2-20090430 http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ W3C CR-xmlschema11-2-20090430 - W3C WD-xmlschema11-2-20091203 http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/ W3C WD-xmlschema11-2-20091203 - W3C CR-xmlschema11-2-20110721 http://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/ W3C CR-xmlschema11-2-20110721 - W3C PR-xmlschema11-2-20120119 http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ W3C PR-xmlschema11-2-20120119 - -W3C WD - 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.

2024-11-17 -OWS5: OGC Web feature service, core and extensions - -OWS5: OGC Web feature service, core and extensions - https://portal.ogc.org/files/?artifact_id=28176 08-079 2008-09-12 - John Herring - -Open Geospatial Consortium - en This standard specifies the behavior of a service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations and transaction operations. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Retrieval operations allow features to be retrieved from the opaque underlying data store based upon constraints on spatial and non-spatial feature properties defined by the client. Transaction operations allow features to be created, changed and deleted from the opaque underlying data store. 2024-11-17 -Geographic information - -Reference model - -Geographic information — Reference model - https://www.iso.org/standard/26002.html https://www.iso.org/contents/data/standard/02/60/26002.detail.rss ISO 19101 ISO 19101(E) urn:iso:std:iso:19101:stage-95.99 19101 -International Organization for Standardization - ISO www.iso.org 1 en fr 95 99 2002 -ISO - ISO 19101-1:2014 ISO 19101-1:2014 2014-11-12 - 2024-11-17 -Geographic information - -Reference model - -Geographic information — Reference model - https://www.iso.org/standard/26002.html https://www.iso.org/contents/data/standard/02/60/26002.detail.rss ISO 19101:2002 ISO 19101:2002(E) urn:iso:std:iso:19101:stage-95.99 19101 2002-07 -International Organization for Standardization - ISO www.iso.org 1 en fr This International Standard defines the framework for standardization in the field of geographic information and sets forth the basic principles by which this standardization takes place. This framework identifies the scope of the standardization activity being undertaken and the context in which it takes place. The framework provides the method by which what is to be standardized can be determined and describes how the contents of the standards are related. Although structured in the context of information technology and information technology standards, this International Standard is independent of any application development method or technology implementation approach. 95 99 2002 -ISO - ISO 19101-1:2014 ISO 19101-1:2014 2014-11-12 - Geneva - Geneva 2024-11-17 -Geographic information - -Spatial schema - -Geographic information — Spatial schema - https://www.iso.org/standard/66175.html https://www.iso.org/obp/ui/en/#!iso:std:66175:en https://www.iso.org/contents/data/standard/06/61/66175.detail.rss ISO 19107 ISO 19107(E) urn:iso:std:iso:19107:stage-90.20 19107 -International Organization for Standardization - ISO www.iso.org 2 en fr 90 20 2019 -ISO - ISO 19107:2003 ISO 19107:2003 - 2024-11-17 -Geographic information - -Spatial schema - -Geographic information — Spatial schema - https://www.iso.org/standard/66175.html https://www.iso.org/obp/ui/en/#!iso:std:66175:en https://www.iso.org/contents/data/standard/06/61/66175.detail.rss ISO 19107:2019 ISO 19107:2019(E) urn:iso:std:iso:19107:stage-90.20 19107 2019-12 -International Organization for Standardization - ISO www.iso.org 2 en fr This document specifies conceptual schemas for describing the spatial characteristics of geographic entities, and a set of spatial operations consistent with these schemas. It treats “vector” geometry and topology. It defines standard spatial operations for use in access, query, management, processing and data exchange of geographic information for spatial (geometric and topological) objects. Because of the nature of geographic information, these geometric coordinate spaces will normally have up to three spatial dimensions, one temporal dimension and any number of other spatially dependent parameters as needed by the applications. In general, the topological dimension of the spatial projections of the geometric objects will be at most three. 90 20 2019 -ISO - ISO 19107:2003 ISO 19107:2003 - Geneva - Geneva 2024-11-17 -Geographic information - -Referencing by coordinates - -Geographic information — Referencing by coordinates - https://www.iso.org/standard/74039.html https://www.iso.org/obp/ui/en/#!iso:std:74039:en https://www.iso.org/contents/data/standard/07/40/74039.detail.rss ISO 19111 ISO 19111(E) urn:iso:std:iso:19111:stage-90.92 19111 -International Organization for Standardization - ISO www.iso.org 3 en fr 90 92 2019 -ISO - ISO 19111-2:2009 ISO 19111-2:2009 - ISO 19111:2007 ISO 19111:2007 - ISO/AWI 19111 ISO/AWI 19111 - ISO 19111:2019/Amd 1:2021 ISO 19111:2019/Amd 1:2021 2024-09-16 - ISO 19111:2019/Amd 2:2023 ISO 19111:2019/Amd 2:2023 2024-09-16 - 2024-11-17 -Geographic information - -Referencing by coordinates - -Geographic information — Referencing by coordinates - https://www.iso.org/standard/74039.html https://www.iso.org/obp/ui/en/#!iso:std:74039:en https://www.iso.org/contents/data/standard/07/40/74039.detail.rss ISO 19111:2019 ISO 19111:2019(E) urn:iso:std:iso:19111:stage-90.92 19111 2019-01 -International Organization for Standardization - ISO www.iso.org 3 en fr This document defines the conceptual schema for the description of referencing by coordinates. It describes the minimum data required to define coordinate reference systems. This document supports the definition of: — spatial coordinate reference systems where coordinate values do not change with time. The system may: — — be geodetic and apply on a national or regional basis, or — — apply locally such as for a building or construction site, or — — apply locally to an image or image sensor; — — be referenced to a moving platform such as a car, a ship, an aircraft or a spacecraft. Such a coordinate reference system can be related to a second coordinate reference system which is referenced to the Earth through a transformation that includes a time element; — spatial coordinate reference systems in which coordinate values of points on or near the surface of the earth change with time due to tectonic plate motion or other crustal deformation. Such dynamic systems include time evolution, however they remain spatial in nature; — parametric coordinate reference systems which use a non-spatial parameter that varies monotonically with height or depth; — temporal coordinate reference systems which use dateTime, temporal count or temporal measure quantities that vary monotonically with time; — mixed spatial, parametric or temporal coordinate reference systems. The definition of a coordinate reference system does not change with time, although in some cases some of the defining parameters can include a rate of change of the parameter. The coordinate values within a dynamic and in a temporal coordinate reference system can change with time. This document also describes the conceptual schema for defining the information required to describe operations that change coordinate values. In addition to the minimum data required for the definition of the coordinate reference system or coordinate operation, the conceptual schema allows additional descriptive information — coordinate reference system metadata — to be provided. This document is applicable to producers and users of geographic information. Although it is applicable to digital geographic data, the principles described in this document can be extended to many other forms of spatial data such as maps, charts and text documents. 90 92 2019 -ISO - ISO 19111-2:2009 ISO 19111-2:2009 - ISO 19111:2007 ISO 19111:2007 - ISO/AWI 19111 ISO/AWI 19111 - ISO 19111:2019/Amd 1:2021 ISO 19111:2019/Amd 1:2021 2024-09-16 - ISO 19111:2019/Amd 2:2023 ISO 19111:2019/Amd 2:2023 2024-09-16 - Geneva - Geneva 2024-11-17 -Geographic information - -Services - -Geographic information — Services - https://www.iso.org/standard/59221.html https://www.iso.org/obp/ui/en/#!iso:std:59221:en https://www.iso.org/contents/data/standard/05/92/59221.detail.rss ISO 19119 ISO 19119(E) urn:iso:std:iso:19119:stage-90.93 19119 -International Organization for Standardization - ISO www.iso.org 2 en fr 90 93 2016 -ISO - ISO 19119:2005 ISO 19119:2005 - ISO 19119:2005/Amd 1:2008 ISO 19119:2005/Amd 1:2008 - 2024-11-17 -Geographic information - -Services - -Geographic information — Services - https://www.iso.org/standard/59221.html https://www.iso.org/obp/ui/en/#!iso:std:59221:en https://www.iso.org/contents/data/standard/05/92/59221.detail.rss ISO 19119:2016 ISO 19119:2016(E) urn:iso:std:iso:19119:stage-90.93 19119 2016-01 -International Organization for Standardization - ISO www.iso.org 2 en fr ISO 19119:2016 defines requirements for how platform neutral and platform specific specification of services shall be created, in order to allow for one service to be specified independently of one or more underlying distributed computing platforms. ISO 19119:2016 defines requirements for a further mapping from platform neutral to platform specific service specifications, in order to enable conformant and interoperable service implementations. ISO 19119:2016 addresses the Meta:Service foundation of the ISO geographic information reference model described in ISO 19101‑1:2014, Clause 6 and Clause 8, respectively. ISO 19119:2016 defines how geographic services shall be categorised according to a service taxonomy based on architectural areas and allows also for services to be categorised according to a usage life cycle perspective, as well as according to domain specific and user defined service taxonomies, providing support for easier publication and discovery of services. 90 93 2016 -ISO - ISO 19119:2005 ISO 19119:2005 - ISO 19119:2005/Amd 1:2008 ISO 19119:2005/Amd 1:2008 - Geneva - Geneva -Geographic information — Simple features -ISO 1912519125 -ISO - 2024-11-17 -Geographic information - -Location-based services - -Tracking and navigation - -Geographic information — Location-based services — Tracking and navigation - https://www.iso.org/standard/32551.html https://www.iso.org/obp/ui/en/#!iso:std:32551:en https://www.iso.org/contents/data/standard/03/25/32551.detail.rss ISO 19133 ISO 19133(E) urn:iso:std:iso:19133:stage-90.93 19133 -International Organization for Standardization - ISO www.iso.org 1 en fr 90 93 2005 -ISO - 2024-11-17 -Geographic information - -Location-based services - -Tracking and navigation - -Geographic information — Location-based services — Tracking and navigation - https://www.iso.org/standard/32551.html https://www.iso.org/obp/ui/en/#!iso:std:32551:en https://www.iso.org/contents/data/standard/03/25/32551.detail.rss ISO 19133:2005 ISO 19133:2005(E) urn:iso:std:iso:19133:stage-90.93 19133 2005-10 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19133:2005 describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. It is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment. 90 93 2005 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Geography Markup Language (GML) - -Geographic information — Geography Markup Language (GML) - https://www.iso.org/standard/32554.html https://www.iso.org/contents/data/standard/03/25/32554.detail.rss ISO 19136 ISO 19136(E) urn:iso:std:iso:19136:stage-95.99 19136 -International Organization for Standardization - ISO www.iso.org 1 en fr 95 99 2007 -ISO - ISO 19136-1:2020 ISO 19136-1:2020 2020-01-09 - 2024-11-17 -Geographic information - -Geography Markup Language (GML) - -Geographic information — Geography Markup Language (GML) - https://www.iso.org/standard/32554.html https://www.iso.org/contents/data/standard/03/25/32554.detail.rss ISO 19136:2007 ISO 19136:2007(E) urn:iso:std:iso:19136:stage-95.99 19136 2007-09 -International Organization for Standardization - ISO www.iso.org 1 en fr The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features. ISO 19136:2007 defines the XML Schema syntax, mechanisms and conventions that: — provide an open, vendor-neutral framework for the description of geospatial application schemas for the transport and storage of geographic information in XML; — allow profiles that support proper subsets of GML framework descriptive capabilities; — support the description of geospatial application schemas for specialized domains and information communities; — enable the creation and maintenance of linked geographic application schemas and datasets; — support the storage and transport of application schemas and data sets; — increase the ability of organizations to share geographic application schemas and the information they describe. Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport. NOTE If an ISO 19109 conformant application schema described in UML is used as the basis for the storage and transportation of geographic information, ISO 19136 provides normative rules for the mapping of such an application schema to a GML application schema in XML Schema and, as such, to an XML encoding for data with a logical structure in accordance with the ISO 19109 conformant application schema. 95 99 2007 -ISO - ISO 19136-1:2020 ISO 19136-1:2020 2020-01-09 - Geneva - Geneva 2024-11-17 -Geographic information - -Schema for moving features - -Geographic information — Schema for moving features - https://www.iso.org/standard/41445.html https://www.iso.org/obp/ui/en/#!iso:std:41445:en https://www.iso.org/contents/data/standard/04/14/41445.detail.rss ISO 19141 ISO 19141(E) urn:iso:std:iso:19141:stage-90.93 19141 -International Organization for Standardization - ISO www.iso.org 1 en fr 90 93 2008 -ISO - 2024-11-17 -Geographic information - -Schema for moving features - -Geographic information — Schema for moving features - https://www.iso.org/standard/41445.html https://www.iso.org/obp/ui/en/#!iso:std:41445:en https://www.iso.org/contents/data/standard/04/14/41445.detail.rss ISO 19141:2008 ISO 19141:2008(E) urn:iso:std:iso:19141:stage-90.93 19141 2008-06 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19141:2008 defines a method to describe the geometry of a feature that moves as a rigid body. Such movement has the following characteristics. — The feature moves within any domain composed of spatial objects as specified in ISO 19107. — The feature may move along a planned route, but it may deviate from the planned route. — Motion may be influenced by physical forces, such as orbital, gravitational, or inertial forces. — Motion of a feature may influence or be influenced by other features, for example: The moving feature might follow a predefined route (e.g. road), perhaps part of a network, and might change routes at known points (e.g. bus stops, waypoints). Two or more moving features may be “pulled” together or pushed apart (e.g. an airplane will be refuelled during flight, a predator detects and tracks a prey, refugee groups join forces). Two or more moving features may be constrained to maintain a given spatial relationship for some period (e.g. tractor and trailer, convoy). ISO 19141:2008 does not address other types of change to the feature. Examples of changes that are not adressed include the following: — The deformation of features. — The succession of either features or their associations. — The change of non-spatial attributes of features. — The feature’s geometric representation cannot be embedded in a geometric complex that contains the geometric representations of other features, since this would require the other features’ representations to be updated as the feature moves. Because ISO 19141:2008 is concerned with the geometric description of feature movement, it does not specify a mechanism for describing feature motion in terms of geographic identifiers. This is done, in part, in ISO 19133. 90 93 2008 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Web Feature Service - -Geographic information — Web Feature Service - https://www.iso.org/standard/42136.html https://www.iso.org/obp/ui/en/#!iso:std:42136:en https://www.iso.org/contents/data/standard/04/21/42136.detail.rss ISO 19142 ISO 19142(E) urn:iso:std:iso:19142:stage-90.93 19142 -International Organization for Standardization - ISO www.iso.org 1 en fr 90 93 2010 -ISO - 2024-11-17 -Geographic information - -Web Feature Service - -Geographic information — Web Feature Service - https://www.iso.org/standard/42136.html https://www.iso.org/obp/ui/en/#!iso:std:42136:en https://www.iso.org/contents/data/standard/04/21/42136.detail.rss ISO 19142:2010 ISO 19142:2010(E) urn:iso:std:iso:19142:stage-90.93 19142 2010-12 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19142:2010 specifies the behaviour of a web feature service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations, locking operations, transaction operations and operations to manage stored parameterized query expressions. 90 93 2010 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Filter encoding - -Geographic information — Filter encoding - https://www.iso.org/standard/42137.html https://www.iso.org/obp/ui/en/#!iso:std:42137:en https://www.iso.org/contents/data/standard/04/21/42137.detail.rss ISO 19143 ISO 19143(E) urn:iso:std:iso:19143:stage-90.93 19143 -International Organization for Standardization - ISO www.iso.org 1 en fr 90 93 2010 -ISO - 2024-11-17 -Geographic information - -Filter encoding - -Geographic information — Filter encoding - https://www.iso.org/standard/42137.html https://www.iso.org/obp/ui/en/#!iso:std:42137:en https://www.iso.org/contents/data/standard/04/21/42137.detail.rss ISO 19143:2010 ISO 19143:2010(E) urn:iso:std:iso:19143:stage-90.93 19143 2010-10 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19143:2010 describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. These components are modular and intended to be used together or individually by other International Standards which reference ISO 19143:2010. ISO 19143:2010 defines an abstract component, named AbstractQueryExpression, from which other specifications can subclass concrete query elements to implement query operations. It also defines an additional abstract query component, named AbstractAdhocQueryExpresison, which is derived from AbstractQueryExpression and from which other specifications can subclass concrete query elements which follow the following query pattern:  — An abstract query element from which service specifications can subclass a concrete query element that implements a query operation that allows a client to specify a list of resource types, an optional projection clause, an optional selection clause, and an optional sorting clause to query a subset of resources that satisfy the selection clause. This pattern is referred to as an ad hoc query pattern since the server in not aware of the query until it is submitted for processing. This is in contrast to a stored query expression, which is stored and can be invoked by name or identifier. ISO 19143:2010 also describes an XML and KVP encoding of a system-neutral representation of a select clause. The XML representation is easily validated, parsed and transformed into a server-specific language required to retrieve or modify object instances stored in some persistent object store. ISO 19143:2010 defines the XML encoding for the following predicates. — A standard set of logical predicates: and, or and not. — A standard set of comparison predicates: equal to, not equal to, less than, less than or equal to, greater than, greater than or equal to, like, is null and between. — A standard set of spatial predicates: equal, disjoint, touches, within, overlaps, crosses, intersects, contains, within a specified distance, beyond a specified distance and BBOX. — A standard set of temporal predicates: after, before, begins, begun by, contains, during, ends, equals, meets, met by, overlaps and overlapped by. — A predicate to test whether the identifier of an object matches the specified value. ISO 19143:2010 defines the XML encoding of metadata that allows a service to declare which conformance classes, predicates, operators, operands and functions it supports. This metadata is referred to as Filter Capabilities. 90 93 2010 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Linear referencing - -Geographic information — Linear referencing - https://www.iso.org/standard/75150.html https://www.iso.org/obp/ui/en/#!iso:std:75150:en https://www.iso.org/contents/data/standard/07/51/75150.detail.rss ISO 19148 ISO 19148(E) urn:iso:std:iso:19148:stage-60.60 19148 -International Organization for Standardization - ISO www.iso.org 2 en fr 60 60 2021 -ISO - ISO 19148:2012 ISO 19148:2012 - 2024-11-17 -Geographic information - -Linear referencing - -Geographic information — Linear referencing - https://www.iso.org/standard/75150.html https://www.iso.org/obp/ui/en/#!iso:std:75150:en https://www.iso.org/contents/data/standard/07/51/75150.detail.rss ISO 19148:2021 ISO 19148:2021(E) urn:iso:std:iso:19148:stage-60.60 19148 2021-04 -International Organization for Standardization - ISO www.iso.org 2 en fr This document specifies a conceptual schema for locations relative to a one-dimensional object as measurement along (and optionally offset from) that object. It defines a description of the data and operations required to use and support linear referencing. This document is applicable to transportation, utilities, environmental protection, location-based services and other applications which define locations relative to linear objects. For ease of reading, most examples discussed in this document come from the transportation domain. 60 60 2021 -ISO - ISO 19148:2012 ISO 19148:2012 - Geneva - Geneva 2024-11-17 -Geographic information - -Rights expression language for geographic information - -GeoREL - -Geographic information — Rights expression language for geographic information — GeoREL - https://www.iso.org/standard/32567.html https://www.iso.org/contents/data/standard/03/25/32567.detail.rss ISO 19149 ISO 19149(E) urn:iso:std:iso:19149:stage-95.99 19149 -International Organization for Standardization - ISO www.iso.org 1 en fr 95 99 2011 -ISO - 2024-11-17 -Geographic information - -Rights expression language for geographic information - -GeoREL - -Geographic information — Rights expression language for geographic information — GeoREL - https://www.iso.org/standard/32567.html https://www.iso.org/contents/data/standard/03/25/32567.detail.rss ISO 19149:2011 ISO 19149:2011(E) urn:iso:std:iso:19149:stage-95.99 19149 2011-11 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19149:2011 defines an XML-based vocabulary or language to express rights for geographic information in order that digital licenses can be created for such information and related services. This language, GeoREL, is an extension of the rights expression language in ISO/IEC 21000-5 and is to be used to compose digital licenses. Each digital license will unambiguously express those particular rights that the owners (or their agent) of a digital geographic resource extend to the holders of that license. The digital rights management system in which these licenses are used can then offer ex ante (before the fact) protection for all such resources. NOTE The proper use of a GeoREL includes the preservation of rights access by formula expressed in usage licenses. Thus, data in the public or private domain, when protected, remain in their respective domains if the usage rights granted so state. These “rights” are not always covered by copyright law, and are often the result of contracts between individuals that specify the proper and allowed uses of resources, as opposed to the threat of copyright litigations which is an ex post facto (after the fact) remediation measure, not an ex ante protection measure. ISO 19149:2011 is not a reflection of, or extension of, copyright law. Mechanisms for the enforcement and preservation of those contract rights are specified in ISO/IEC 21000, and it is not the intention of ISO 19149:2011 to replace nor redefine those mechanisms, but to use them as previously standardized. 95 99 2011 -ISO - Geneva - Geneva 2024-11-17 -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - https://www.iso.org/standard/32571.html https://www.iso.org/contents/data/standard/03/25/32571.detail.rss ISO 19153 ISO 19153(E) urn:iso:std:iso:19153:stage-95.99 19153 -International Organization for Standardization - ISO www.iso.org 1 en fr 95 99 2014 -ISO - 2024-11-17 -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - -Geospatial Digital Rights Management Reference Model (GeoDRM RM) - https://www.iso.org/standard/32571.html https://www.iso.org/contents/data/standard/03/25/32571.detail.rss ISO 19153:2014 ISO 19153:2014(E) urn:iso:std:iso:19153:stage-95.99 19153 2014-02 -International Organization for Standardization - ISO www.iso.org 1 en fr ISO 19153:2014 is a reference model for digital rights management (DRM) functionality for geospatial resources (GeoDRM). As such, it is connected to the general DRM market in that geospatial resources shall be treated as nearly as possible like other resources, such as music, text, or services. It is not the intention to reinvent a market nor the technology that already exists and is thriving, but to make sure that a larger market has access to geospatial resources through a mechanism that it understands and that is similar to and consistent with the ones already in use. ISO 19153:2014 does not replace any previous standards, but it is dependent upon them. Each resource and service standard that exists or will exist becomes a resource description in ISO 19153:2014, and hopefully will be subject to the same protection that is afforded to other resources. This International Standard defines: —  A conceptual model for digital rights management of geospatial resources, providing a framework and reference for more detailed specification in this area. —  A metadata model for the expression of rights that associate users to the acts that they can perform against a particular geospatial resource, and associated information used in the enforcement and granting of those rights, such as owner metadata, available rights, and issuer of those rights. —  Requirements that are placed on rights management systems for the enforcement of those rights. A rights management system shall be necessary and sufficient: it shall implement only those restrictions necessary to enforce the rights defined therein, and it shall be sufficient to enforce those rights. —  How this is to work conceptually in the larger DRM context to ensure the ubiquity of geospatial resources in the general services market. A resource in this context is a data file, or service for geographic information or process. This abstract descriptive standard builds on and complements the existing standards, and defines at an abstract level a rights model to enable the digital rights management of standards-based geospatial resources. Future GeoDRM standards will be written to implement the concepts defined in ISO 19153:2014. 95 99 2014 -ISO - Geneva - Geneva 2024-11-17 -Geographic information - -Observations, measurements and samples - -Geographic information — Observations, measurements and samples - https://www.iso.org/standard/82463.html https://www.iso.org/obp/ui/en/#!iso:std:82463:en https://www.iso.org/contents/data/standard/08/24/82463.detail.rss ISO 19156 ISO 19156(E) urn:iso:std:iso:19156:stage-60.60 19156 -International Organization for Standardization - ISO www.iso.org 2 en fr 60 60 2023 -ISO - ISO 19156:2011 ISO 19156:2011 - 2024-11-17 -Geographic information - -Observations, measurements and samples - -Geographic information — Observations, measurements and samples - https://www.iso.org/standard/82463.html https://www.iso.org/obp/ui/en/#!iso:std:82463:en https://www.iso.org/contents/data/standard/08/24/82463.detail.rss ISO 19156:2023 ISO 19156:2023(E) urn:iso:std:iso:19156:stage-60.60 19156 2023-04 -International Organization for Standardization - ISO www.iso.org 2 en fr This document defines a conceptual schema for observations, for features involved in the observation process, and for features involved in sampling when making observations. These provide models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. Observations commonly involve sampling of an ultimate feature-of-interest. This document defines a common set of sample types according to their spatial, material (for ex situ observations) or statistical nature. The schema includes relationships between sample features (sub-sampling, derived samples). This document concerns only externally visible interfaces and places no restriction on the underlying implementations other than what is needed to satisfy the interface specifications in the actual situation. 60 60 2023 -ISO - ISO 19156:2011 ISO 19156:2011 - Geneva - Geneva - - - - - - - - - - - - - - - - -
-
-
diff --git a/sources/iev/cache/version b/sources/iev/cache/version deleted file mode 100644 index 9325c3c..0000000 --- a/sources/iev/cache/version +++ /dev/null @@ -1 +0,0 @@ -0.3.0 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19101.xml b/sources/relaton/cache/iso/iso_19101.xml deleted file mode 100644 index 4db5134..0000000 --- a/sources/relaton/cache/iso/iso_19101.xml +++ /dev/null @@ -1,122 +0,0 @@ - - 2024-11-17 - Geographic information - Reference model - Geographic information - Reference model - Information géographique - Modèle de référence - Information géographique - Modèle de référence - https://www.iso.org/standard/26002.html - https://www.iso.org/contents/data/standard/02/60/26002.detail.rss - ISO 19101 - ISO 19101(E) - urn:iso:std:iso:19101:stage-95.99 - 19101 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 95 - 99 - - - 2002 - - - ISO - - - - - - ISO 19101-1:2014 - ISO 19101-1:2014 - - 2014-11-12 - - - - - - 2024-11-17 - Geographic information - Reference model - Geographic information - Reference model - Information géographique - Modèle de référence - Information géographique - Modèle de référence - https://www.iso.org/standard/26002.html - https://www.iso.org/contents/data/standard/02/60/26002.detail.rss - ISO 19101:2002 - ISO 19101:2002(E) - urn:iso:std:iso:19101:stage-95.99 - 19101 - - 2002-07 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - This International Standard defines the framework for standardization in the field of geographic information and sets forth the basic principles by which this standardization takes place. -This framework identifies the scope of the standardization activity being undertaken and the context in which it takes place. The framework provides the method by which what is to be standardized can be determined and describes how the contents of the standards are related. -Although structured in the context of information technology and information technology standards, this International Standard is independent of any application development method or technology implementation approach. - This International Standard defines the framework for standardization in the field of geographic information and sets forth the basic principles by which this standardization takes place. -This framework identifies the scope of the standardization activity being undertaken and the context in which it takes place. The framework provides the method by which what is to be standardized can be determined and describes how the contents of the standards are related. -Although structured in the context of information technology and information technology standards, this International Standard is independent of any application development method or technology implementation approach. - - 95 - 99 - - - 2002 - - - ISO - - - - - - ISO 19101-1:2014 - ISO 19101-1:2014 - - 2014-11-12 - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19101 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19105.xml b/sources/relaton/cache/iso/iso_19105.xml deleted file mode 100644 index 889f62f..0000000 --- a/sources/relaton/cache/iso/iso_19105.xml +++ /dev/null @@ -1,116 +0,0 @@ - - 2024-11-17 - Geographic information - Conformance and testing - Geographic information - Conformance and testing - Information géographique - Conformité et essais - Information géographique - Conformité et essais - https://www.iso.org/standard/76457.html - https://www.iso.org/obp/ui/en/#!iso:std:76457:en - https://www.iso.org/contents/data/standard/07/64/76457.detail.rss - ISO 19105 - ISO 19105(E) - urn:iso:std:iso:19105:stage-60.60 - 19105 - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - - 60 - 60 - - - 2022 - - - ISO - - - - - - ISO 19105:2000 - ISO 19105:2000 - - - - - 2024-11-17 - Geographic information - Conformance and testing - Geographic information - Conformance and testing - Information géographique - Conformité et essais - Information géographique - Conformité et essais - https://www.iso.org/standard/76457.html - https://www.iso.org/obp/ui/en/#!iso:std:76457:en - https://www.iso.org/contents/data/standard/07/64/76457.detail.rss - ISO 19105:2022 - ISO 19105:2022(E) - urn:iso:std:iso:19105:stage-60.60 - 19105 - - 2022-07 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - This document specifies the framework, concepts and methodology for conformance testing and criteria to be achieved to claim conformance to the family of applicable standardization documents regarding geographic information and relevant application domains. This document provides a framework for specifying abstract test suites composed of abstract test cases grouped in conformance classes and for defining the procedures to be followed during conformance testing. -Conformance can be claimed for data or software products or services or by specifications including any profile or functional standard. The structure of, and relationships between, conformance classes as defined in this document underly a systematic approach to configuration management involving managing dependencies within and between modules. - Le présent document spécifie le cadre, les concepts et la méthodologie applicables aux tests et critères de conformité à respecter pour revendiquer la conformité avec la famille de document de normalisation sur l'information géographique et les domaines d'application concernés. Le présent document propose un cadre pour la spécification des suites de tests abstraits composées de cas de test abstraits regroupés en classes de conformité, et pour la définition des procédures à suivre lors des tests de conformité. -Il est possible de revendiquer la conformité pour les données ou les produits et services logiciels, ou par les spécifications, y compris de n'importe quel profil ou norme opératoire. La structure des classes de conformité définies dans le présent document, et les relations entre celles-ci, sous-tendent une approche systématique de la gestion de configuration qui implique la gestion des dépendances au sein des modules et entre ceux-ci. - - 60 - 60 - - - 2022 - - - ISO - - - - - - ISO 19105:2000 - ISO 19105:2000 - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19105 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19107.xml b/sources/relaton/cache/iso/iso_19107.xml deleted file mode 100644 index 196a0a2..0000000 --- a/sources/relaton/cache/iso/iso_19107.xml +++ /dev/null @@ -1,114 +0,0 @@ - - 2024-11-17 - Geographic information - Spatial schema - Geographic information - Spatial schema - Information géographique - Schéma spatial - Information géographique - Schéma spatial - https://www.iso.org/standard/66175.html - https://www.iso.org/obp/ui/en/#!iso:std:66175:en - https://www.iso.org/contents/data/standard/06/61/66175.detail.rss - ISO 19107 - ISO 19107(E) - urn:iso:std:iso:19107:stage-90.20 - 19107 - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - - 90 - 20 - - - 2019 - - - ISO - - - - - - ISO 19107:2003 - ISO 19107:2003 - - - - - 2024-11-17 - Geographic information - Spatial schema - Geographic information - Spatial schema - Information géographique - Schéma spatial - Information géographique - Schéma spatial - https://www.iso.org/standard/66175.html - https://www.iso.org/obp/ui/en/#!iso:std:66175:en - https://www.iso.org/contents/data/standard/06/61/66175.detail.rss - ISO 19107:2019 - ISO 19107:2019(E) - urn:iso:std:iso:19107:stage-90.20 - 19107 - - 2019-12 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - This document specifies conceptual schemas for describing the spatial characteristics of geographic entities, and a set of spatial operations consistent with these schemas. It treats "vector" geometry and topology. It defines standard spatial operations for use in access, query, management, processing and data exchange of geographic information for spatial (geometric and topological) objects. Because of the nature of geographic information, these geometric coordinate spaces will normally have up to three spatial dimensions, one temporal dimension and any number of other spatially dependent parameters as needed by the applications. In general, the topological dimension of the spatial projections of the geometric objects will be at most three. - Le présent document spécifie les schémas conceptuels de description des caractéristiques spatiales des entités géographiques, ainsi qu'un jeu d'opérations spatiales cohérent avec ces schémas. Il traite de géométrie et de topologie vectorielle. Il définit des opérations spatiales normalisées destinées à être utilisées pour accéder aux informations géométriques sur des objets spatiaux (géométriques et topologiques), pour les interroger, les gérer, les traiter et les échanger. Du fait de la nature des informations géographiques, ces espaces de coordonnées géométriques ont normalement jusqu'à trois dimensions spatiales, une dimension temporelle et n'importe quel nombre d'autres paramètres de l'espace, selon les besoins des applications. En général, la dimension topologique des projections spatiales des objets géométriques sera de trois au maximum. - - 90 - 20 - - - 2019 - - - ISO - - - - - - ISO 19107:2003 - ISO 19107:2003 - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19107 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19111.xml b/sources/relaton/cache/iso/iso_19111.xml deleted file mode 100644 index 57a0427..0000000 --- a/sources/relaton/cache/iso/iso_19111.xml +++ /dev/null @@ -1,200 +0,0 @@ - - 2024-11-17 - Geographic information - Referencing by coordinates - Geographic information - Referencing by coordinates - Information géographique - Référencement par coordonnées - Information géographique - Référencement par coordonnées - https://www.iso.org/standard/74039.html - https://www.iso.org/obp/ui/en/#!iso:std:74039:en - https://www.iso.org/contents/data/standard/07/40/74039.detail.rss - ISO 19111 - ISO 19111(E) - urn:iso:std:iso:19111:stage-90.92 - 19111 - - - - International Organization for Standardization - ISO - www.iso.org - - - 3 - en - fr - - - 90 - 92 - - - 2019 - - - ISO - - - - - - ISO 19111-2:2009 - ISO 19111-2:2009 - - - - - ISO 19111:2007 - ISO 19111:2007 - - - - - ISO/AWI 19111 - ISO/AWI 19111 - - - - - ISO 19111:2019/Amd 1:2021 - ISO 19111:2019/Amd 1:2021 - - 2024-09-16 - - - - - - ISO 19111:2019/Amd 2:2023 - ISO 19111:2019/Amd 2:2023 - - 2024-09-16 - - - - - - 2024-11-17 - Geographic information - Referencing by coordinates - Geographic information - Referencing by coordinates - Information géographique - Référencement par coordonnées - Information géographique - Référencement par coordonnées - https://www.iso.org/standard/74039.html - https://www.iso.org/obp/ui/en/#!iso:std:74039:en - https://www.iso.org/contents/data/standard/07/40/74039.detail.rss - ISO 19111:2019 - ISO 19111:2019(E) - urn:iso:std:iso:19111:stage-90.92 - 19111 - - 2019-01 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 3 - en - fr - - This document defines the conceptual schema for the description of referencing by coordinates. It describes the minimum data required to define coordinate reference systems. This document supports the definition of: -— spatial coordinate reference systems where coordinate values do not change with time. The system may: -- — be geodetic and apply on a national or regional basis, or -- — apply locally such as for a building or construction site, or -- — apply locally to an image or image sensor; -- — be referenced to a moving platform such as a car, a ship, an aircraft or a spacecraft. Such a coordinate reference system can be related to a second coordinate reference system which is referenced to the Earth through a transformation that includes a time element; -— spatial coordinate reference systems in which coordinate values of points on or near the surface of the earth change with time due to tectonic plate motion or other crustal deformation. Such dynamic systems include time evolution, however they remain spatial in nature; -— parametric coordinate reference systems which use a non-spatial parameter that varies monotonically with height or depth; -— temporal coordinate reference systems which use dateTime, temporal count or temporal measure quantities that vary monotonically with time; -— mixed spatial, parametric or temporal coordinate reference systems. -The definition of a coordinate reference system does not change with time, although in some cases some of the defining parameters can include a rate of change of the parameter. The coordinate values within a dynamic and in a temporal coordinate reference system can change with time. -This document also describes the conceptual schema for defining the information required to describe operations that change coordinate values. -In addition to the minimum data required for the definition of the coordinate reference system or coordinate operation, the conceptual schema allows additional descriptive information - coordinate reference system metadata - to be provided. -This document is applicable to producers and users of geographic information. Although it is applicable to digital geographic data, the principles described in this document can be extended to many other forms of spatial data such as maps, charts and text documents. - Le présent document définit le schéma conceptuel pour la description du référencement par coordonnées. Il décrit les données minimales requises pour définir des systèmes de référence de coordonnées. Le présent document prend en charge la définition des éléments suivants: -— les systèmes de référence de coordonnées spatiaux dans lesquels les valeurs des coordonnées ne changent pas avec le temps. Le système peut: -- — être géodésique et s'appliquer à l'échelle nationale ou régionale; ou -- — s'appliquer localement, comme dans le cas d'un bâtiment ou d'un chantier de construction; ou -- — s'appliquer localement à une image ou un capteur d'image; -- — être associé à une plate-forme mobile telle qu'une voiture, un navire, un aéronef ou un engin spatial. Un tel système de référence de coordonnées peut être relié à un deuxième système de référence de coordonnées qui est associé à la Terre par une transformation qui comprend un élément temporel; -— les systèmes de référence de coordonnées spatiaux dans lesquels les valeurs de coordonnées de points situés sur ou près de la surface de la terre, changent avec le temps en raison du mouvement tectonique des plaques ou d'autres déformations de la croûte terrestre. Ces systèmes dynamiques comprennent l'évolution temporelle, mais ils restent de nature spatiale; -— les systèmes de référence de coordonnées paramétriques qui utilisent un paramètre non spatial variant de façon monotone avec la hauteur ou la profondeur; -— les systèmes de référence de coordonnées temporels qui utilisent dateTime, le comptage temporel ou des mesures de grandeur temporelles dont les valeurs varient de façon monotone avec le temps; -— les systèmes de référence de coordonnées mixtes spatiaux, paramétriques ou temporels. -La définition d'un système de référence de coordonnées ne change pas avec le temps, même si dans certains cas, certains paramètres de définition peuvent inclure une vitesse de changement du paramètre. Les valeurs de coordonnées dans un système de référence de coordonnées dynamique et temporel peuvent changer avec le temps. -Le présent document décrit également le schéma conceptuel permettant de définir les informations requises pour décrire les opérations qui modifient les valeurs de coordonnées. -Outre les données minimales requises pour la définition du système de référence de coordonnées ou de l'opération sur les coordonnées, le schéma conceptuel permet de fournir des informations descriptives supplémentaires (métadonnées du système de référence de coordonnées) -Le présent document est applicable aux producteurs et aux utilisateurs d'informations géographiques. Bien qu'il soit applicable aux données géographiques numériques, il est possible d'élargir ses principes à de nombreux autres types de données géographiques tels que les cartes, les tableaux et les textes. - - 90 - 92 - - - 2019 - - - ISO - - - - - - ISO 19111-2:2009 - ISO 19111-2:2009 - - - - - ISO 19111:2007 - ISO 19111:2007 - - - - - ISO/AWI 19111 - ISO/AWI 19111 - - - - - ISO 19111:2019/Amd 1:2021 - ISO 19111:2019/Amd 1:2021 - - 2024-09-16 - - - - - - ISO 19111:2019/Amd 2:2023 - ISO 19111:2019/Amd 2:2023 - - 2024-09-16 - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19111 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19119.xml b/sources/relaton/cache/iso/iso_19119.xml deleted file mode 100644 index 590c81a..0000000 --- a/sources/relaton/cache/iso/iso_19119.xml +++ /dev/null @@ -1,132 +0,0 @@ - - 2024-11-17 - Geographic information - Services - Geographic information - Services - Information géographique - Services - Information géographique - Services - https://www.iso.org/standard/59221.html - https://www.iso.org/obp/ui/en/#!iso:std:59221:en - https://www.iso.org/contents/data/standard/05/92/59221.detail.rss - ISO 19119 - ISO 19119(E) - urn:iso:std:iso:19119:stage-90.93 - 19119 - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - - 90 - 93 - - - 2016 - - - ISO - - - - - - ISO 19119:2005 - ISO 19119:2005 - - - - - ISO 19119:2005/Amd 1:2008 - ISO 19119:2005/Amd 1:2008 - - - - - 2024-11-17 - Geographic information - Services - Geographic information - Services - Information géographique - Services - Information géographique - Services - https://www.iso.org/standard/59221.html - https://www.iso.org/obp/ui/en/#!iso:std:59221:en - https://www.iso.org/contents/data/standard/05/92/59221.detail.rss - ISO 19119:2016 - ISO 19119:2016(E) - urn:iso:std:iso:19119:stage-90.93 - 19119 - - 2016-01 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - ISO 19119:2016 defines requirements for how platform neutral and platform specific specification of services shall be created, in order to allow for one service to be specified independently of one or more underlying distributed computing platforms. -ISO 19119:2016 defines requirements for a further mapping from platform neutral to platform specific service specifications, in order to enable conformant and interoperable service implementations. -ISO 19119:2016 addresses the Meta:Service foundation of the ISO geographic information reference model described in ISO 19101‑1:2014, Clause 6 and Clause 8, respectively. -ISO 19119:2016 defines how geographic services shall be categorised according to a service taxonomy based on architectural areas and allows also for services to be categorised according to a usage life cycle perspective, as well as according to domain specific and user defined service taxonomies, providing support for easier publication and discovery of services. - ISO 19119:2016 définit des exigences sur la façon dont une spécification de services propre à une plate-forme et applicable à toutes les plates-formes doit être créée, de manière à ce qu'un service puisse être spécifié indépendamment d'une ou de plusieurs plates-formes informatiques distribuées sous-jacentes. -ISO 19119:2016 définit des exigences pour une mise en correspondance supplémentaire des spécifications de services applicables à toutes les plates-formes avec les spécifications de services propres à une plate-forme, de manière à assurer des implémentations de services conformes et interopérables. -ISO 19119:2016 traite du fondement Méta:Service du modèle de référence d'information géographique ISO décrit dans l'ISO 19101‑1:2014, Articles 6 et 8. -ISO 19119:2016 définit la façon dont des services géographiques doivent être classés selon une taxonomie de services basée sur des domaines architecturaux, et permet également de classer les services selon une perspective de cycle de vie à l'usage ainsi que selon des taxonomies de services propres à un domaine et définies par l'utilisateur, ce qui fournit un support facilitant la publication et la découverte de services. - - 90 - 93 - - - 2016 - - - ISO - - - - - - ISO 19119:2005 - ISO 19119:2005 - - - - - ISO 19119:2005/Amd 1:2008 - ISO 19119:2005/Amd 1:2008 - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19119 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19125.notfound b/sources/relaton/cache/iso/iso_19125.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/iso/iso_19125.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19133.xml b/sources/relaton/cache/iso/iso_19133.xml deleted file mode 100644 index 2100953..0000000 --- a/sources/relaton/cache/iso/iso_19133.xml +++ /dev/null @@ -1,106 +0,0 @@ - - 2024-11-17 - Geographic information - Location-based services - Tracking and navigation - Geographic information - Location-based services - Tracking and navigation - Information géographique - Services basés sur la localisation - Suivi et navigation - Information géographique - Services basés sur la localisation - Suivi et navigation - https://www.iso.org/standard/32551.html - https://www.iso.org/obp/ui/en/#!iso:std:32551:en - https://www.iso.org/contents/data/standard/03/25/32551.detail.rss - ISO 19133 - ISO 19133(E) - urn:iso:std:iso:19133:stage-90.93 - 19133 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 90 - 93 - - - 2005 - - - ISO - - - - - - 2024-11-17 - Geographic information - Location-based services - Tracking and navigation - Geographic information - Location-based services - Tracking and navigation - Information géographique - Services basés sur la localisation - Suivi et navigation - Information géographique - Services basés sur la localisation - Suivi et navigation - https://www.iso.org/standard/32551.html - https://www.iso.org/obp/ui/en/#!iso:std:32551:en - https://www.iso.org/contents/data/standard/03/25/32551.detail.rss - ISO 19133:2005 - ISO 19133:2005(E) - urn:iso:std:iso:19133:stage-90.93 - 19133 - - 2005-10 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19133:2005 describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. It is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment. - L'ISO 19133:2005 décrit les types de données ainsi que les opérations associées pour l'implémentation de services de navigation et de suivi. Elle est conçue, entre autres, pour spécifier des services web pouvant être accessibles à des dispositifs sans fil par le biais d'applications web proxy. - - 90 - 93 - - - 2005 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19133 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19136.xml b/sources/relaton/cache/iso/iso_19136.xml deleted file mode 100644 index 28c058d..0000000 --- a/sources/relaton/cache/iso/iso_19136.xml +++ /dev/null @@ -1,136 +0,0 @@ - - 2024-11-17 - Geographic information - Geography Markup Language (GML) - Geographic information - Geography Markup Language (GML) - Information géographique - Langage de balisage en géographie (GML) - Information géographique - Langage de balisage en géographie (GML) - https://www.iso.org/standard/32554.html - https://www.iso.org/contents/data/standard/03/25/32554.detail.rss - ISO 19136 - ISO 19136(E) - urn:iso:std:iso:19136:stage-95.99 - 19136 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 95 - 99 - - - 2007 - - - ISO - - - - - - ISO 19136-1:2020 - ISO 19136-1:2020 - - 2020-01-09 - - - - - - 2024-11-17 - Geographic information - Geography Markup Language (GML) - Geographic information - Geography Markup Language (GML) - Information géographique - Langage de balisage en géographie (GML) - Information géographique - Langage de balisage en géographie (GML) - https://www.iso.org/standard/32554.html - https://www.iso.org/contents/data/standard/03/25/32554.detail.rss - ISO 19136:2007 - ISO 19136:2007(E) - urn:iso:std:iso:19136:stage-95.99 - 19136 - - 2007-09 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features. -ISO 19136:2007 defines the XML Schema syntax, mechanisms and conventions that: -- provide an open, vendor-neutral framework for the description of geospatial application schemas for the transport and storage of geographic information in XML; -- allow profiles that support proper subsets of GML framework descriptive capabilities; -- support the description of geospatial application schemas for specialized domains and information communities; -- enable the creation and maintenance of linked geographic application schemas and datasets; -- support the storage and transport of application schemas and data sets; -- increase the ability of organizations to share geographic application schemas and the information they describe. -Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport. -NOTE If an ISO 19109 conformant application schema described in UML is used as the basis for the storage and transportation of geographic information, ISO 19136 provides normative rules for the mapping of such an application schema to a GML application schema in XML Schema and, as such, to an XML encoding for data with a logical structure in accordance with the ISO 19109 conformant application schema. - Le langage GML (Geography Markup Language, langage de balisage en géographie) est un codage XML conforme à l'ISO 19118 pour le transport et le stockage des informations géographiques modélisées conformément au cadre de modélisation conceptuelle utilisé dans la série de Normes internationales ISO 19100 et comprenant les propriétés spatiales et non spatiales des entités géographiques. -L'ISO 19136:2007 définit la syntaxe, les mécanismes et les conventions du schéma XML qui -- offrent un cadre ouvert indépendant du fournisseur pour la description des schémas d'application géospatiale pour le transport et le stockage des informations géographiques en langage XML; -- autorisent les profils prenant en charge les sous-ensembles corrects de possibilités descriptives du cadre GML; -- prennent en charge la description des schémas d'application géospatiale pour les domaines et communautés d'informations spécialisés; -- permettent de créer et d'entretenir des schémas d'application géographique associés et des ensembles de données; -- prennent en charge le stockage et le transport des schémas d'application et des ensembles de données; -- augmentent les possibilités d'organisation pour partager des schémas d'application géographique et les informations qu'ils décrivent. -Les implémenteurs peuvent choisir de stocker les schémas d'application géographique et les informations en GML, ou de les convertir à la demande à partir d'un autre format de stockage et d'utiliser GML uniquement pour le schéma et le transport des données. -NOTE Si un schéma d'application conforme à l'ISO 19109 décrit en langage UML est utilisé comme base du stockage et du transport des informations géographiques, l'ISO 19136:2007 donne les règles normatives de mise en correspondance de ce type de schéma d'application avec le schéma d'application GML en langage XML et, en tant que tel, avec le codage XML pour les données dotées d'une structure logique conformément au schéma d'application conforme à l'ISO 19109. - - 95 - 99 - - - 2007 - - - ISO - - - - - - ISO 19136-1:2020 - ISO 19136-1:2020 - - 2020-01-09 - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19136 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19141.xml b/sources/relaton/cache/iso/iso_19141.xml deleted file mode 100644 index 5fcb5f2..0000000 --- a/sources/relaton/cache/iso/iso_19141.xml +++ /dev/null @@ -1,134 +0,0 @@ - - 2024-11-17 - Geographic information - Schema for moving features - Geographic information - Schema for moving features - Information géographique - Schéma des entités mobiles - Information géographique - Schéma des entités mobiles - https://www.iso.org/standard/41445.html - https://www.iso.org/obp/ui/en/#!iso:std:41445:en - https://www.iso.org/contents/data/standard/04/14/41445.detail.rss - ISO 19141 - ISO 19141(E) - urn:iso:std:iso:19141:stage-90.93 - 19141 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 90 - 93 - - - 2008 - - - ISO - - - - - - 2024-11-17 - Geographic information - Schema for moving features - Geographic information - Schema for moving features - Information géographique - Schéma des entités mobiles - Information géographique - Schéma des entités mobiles - https://www.iso.org/standard/41445.html - https://www.iso.org/obp/ui/en/#!iso:std:41445:en - https://www.iso.org/contents/data/standard/04/14/41445.detail.rss - ISO 19141:2008 - ISO 19141:2008(E) - urn:iso:std:iso:19141:stage-90.93 - 19141 - - 2008-06 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19141:2008 defines a method to describe the geometry of a feature that moves as a rigid body. Such movement has the following characteristics. -- The feature moves within any domain composed of spatial objects as specified in ISO 19107. -- The feature may move along a planned route, but it may deviate from the planned route. -- Motion may be influenced by physical forces, such as orbital, gravitational, or inertial forces. -- Motion of a feature may influence or be influenced by other features, for example: - -The moving feature might follow a predefined route (e.g. road), perhaps part of a network, and might change routes at known points (e.g. bus stops, waypoints). -Two or more moving features may be “pulled” together or pushed apart (e.g. an airplane will be refuelled during flight, a predator detects and tracks a prey, refugee groups join forces). -Two or more moving features may be constrained to maintain a given spatial relationship for some period (e.g. tractor and trailer, convoy). - - -ISO 19141:2008 does not address other types of change to the feature. Examples of changes that are not adressed include the following: -- The deformation of features. -- The succession of either features or their associations. -- The change of non-spatial attributes of features. -- The feature's geometric representation cannot be embedded in a geometric complex that contains the geometric representations of other features, since this would require the other features' representations to be updated as the feature moves. -Because ISO 19141:2008 is concerned with the geometric description of feature movement, it does not specify a mechanism for describing feature motion in terms of geographic identifiers. This is done, in part, in ISO 19133. - L'ISO 19141:2008 définit une méthode permettant de décrire la géométrie d'une entité mobile se déplaçant comme un corps rigide. Ce type de déplacement présente les caractéristiques suivantes. -- L'entité se déplace à l'intérieur d'un domaine composé d'objets spatiaux conformément à l'ISO 19107. -- L'entité peut se déplacer le long d'un itinéraire planifié, mais elle peut s'en écarter. -- Le mouvement peut être influencé par les forces physiques, telles que les forces orbitale, de gravitation ou d'inertie. -- Le mouvement d'une entité peut influencer d'autres entités ou être influencé par elles, par exemple comme suit. - -L'entité mobile peut suivre un itinéraire prédéfini (tel qu'une route), pouvant faire partie d'un réseau, et peut modifier les itinéraires au niveau de points clés (par exemple arrêts de bus, points de cheminement). -Deux ou plusieurs entités mobiles peuvent être «tirées» ensemble ou poussées séparément (par exemple un avion ravitaillé en vol, un prédateur ayant repéré et suivant sa proie, des groupes de réfugiés unissant leurs forces). -Deux entités mobiles ou davantage peuvent être contraintes de conserver une relation spatiale donnée pendant une certaine période (par exemple tracteur et semi-remorque, convoi). - - -L'ISO 19141:2008 ne régit pas d'autres types de changement en matière d'entité. Les changements non abordés sont par exemple les suivants. -- La déformation des entités. -- La succession de chaque entité ou leurs associations. -- La modification des attributs non spatiaux des entités. -- La représentation géométrique de l'entité ne peut pas être présente dans un complexe géométrique comportant des représentations géométriques d'autres entités, car cela impliquerait une mise à jour des représentations des autres entités en même temps que le déplacement de l'entité. -Étant donné que l'ISO 19141:2008 couvre la description géométrique du déplacement de l'entité, elle ne spécifie pas un mécanisme consistant à décrire le mouvement des entités en termes d'identificateurs géographiques. Ce mécanisme est présenté en partie dans l'ISO 19133. - - 90 - 93 - - - 2008 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19141 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19142.xml b/sources/relaton/cache/iso/iso_19142.xml deleted file mode 100644 index 9bb61d3..0000000 --- a/sources/relaton/cache/iso/iso_19142.xml +++ /dev/null @@ -1,102 +0,0 @@ - - 2024-11-17 - Geographic information - Web Feature Service - Geographic information - Web Feature Service - Information géographique - Service d'accès aux entités géographiques par le web - Information géographique - Service d'accès aux entités géographiques par le web - https://www.iso.org/standard/42136.html - https://www.iso.org/obp/ui/en/#!iso:std:42136:en - https://www.iso.org/contents/data/standard/04/21/42136.detail.rss - ISO 19142 - ISO 19142(E) - urn:iso:std:iso:19142:stage-90.93 - 19142 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 90 - 93 - - - 2010 - - - ISO - - - - - - 2024-11-17 - Geographic information - Web Feature Service - Geographic information - Web Feature Service - Information géographique - Service d'accès aux entités géographiques par le web - Information géographique - Service d'accès aux entités géographiques par le web - https://www.iso.org/standard/42136.html - https://www.iso.org/obp/ui/en/#!iso:std:42136:en - https://www.iso.org/contents/data/standard/04/21/42136.detail.rss - ISO 19142:2010 - ISO 19142:2010(E) - urn:iso:std:iso:19142:stage-90.93 - 19142 - - 2010-12 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19142:2010 specifies the behaviour of a web feature service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations, locking operations, transaction operations and operations to manage stored parameterized query expressions. - L'ISO 19142:2010 spécifie le comportement d'un service qui fournit des transactions sur des entités géographiques et un accès à des entités géographiques indépendamment de l'entrepôt de données sous-jacent. Elle spécifie des opérations de découverte, des opérations d'interrogation, des opérations de verrouillage, des opérations de transactions et des opérations destinées à gérer des expressions d'interrogations paramétrées qui sont prédéfinies. - - 90 - 93 - - - 2010 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19142 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19143.xml b/sources/relaton/cache/iso/iso_19143.xml deleted file mode 100644 index 4790d62..0000000 --- a/sources/relaton/cache/iso/iso_19143.xml +++ /dev/null @@ -1,123 +0,0 @@ - - 2024-11-17 - Geographic information - Filter encoding - Geographic information - Filter encoding - Information géographique - Codage de filtres - Information géographique - Codage de filtres - https://www.iso.org/standard/42137.html - https://www.iso.org/obp/ui/en/#!iso:std:42137:en - https://www.iso.org/contents/data/standard/04/21/42137.detail.rss - ISO 19143 - ISO 19143(E) - urn:iso:std:iso:19143:stage-90.93 - 19143 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 90 - 93 - - - 2010 - - - ISO - - - - - - 2024-11-17 - Geographic information - Filter encoding - Geographic information - Filter encoding - Information géographique - Codage de filtres - Information géographique - Codage de filtres - https://www.iso.org/standard/42137.html - https://www.iso.org/obp/ui/en/#!iso:std:42137:en - https://www.iso.org/contents/data/standard/04/21/42137.detail.rss - ISO 19143:2010 - ISO 19143:2010(E) - urn:iso:std:iso:19143:stage-90.93 - 19143 - - 2010-10 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19143:2010 describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. -These components are modular and intended to be used together or individually by other International Standards which reference ISO 19143:2010. -ISO 19143:2010 defines an abstract component, named AbstractQueryExpression, from which other specifications can subclass concrete query elements to implement query operations. -It also defines an additional abstract query component, named AbstractAdhocQueryExpresison, which is derived from AbstractQueryExpression and from which other specifications can subclass concrete query elements which follow the following query pattern: -- An abstract query element from which service specifications can subclass a concrete query element that implements a query operation that allows a client to specify a list of resource types, an optional projection clause, an optional selection clause, and an optional sorting clause to query a subset of resources that satisfy the selection clause. -This pattern is referred to as an ad hoc query pattern since the server in not aware of the query until it is submitted for processing. This is in contrast to a stored query expression, which is stored and can be invoked by name or identifier. -ISO 19143:2010 also describes an XML and KVP encoding of a system-neutral representation of a select clause. The XML representation is easily validated, parsed and transformed into a server-specific language required to retrieve or modify object instances stored in some persistent object store. -ISO 19143:2010 defines the XML encoding for the following predicates. -- A standard set of logical predicates: and, or and not. -- A standard set of comparison predicates: equal to, not equal to, less than, less than or equal to, greater than, greater than or equal to, like, is null and between. -- A standard set of spatial predicates: equal, disjoint, touches, within, overlaps, crosses, intersects, contains, within a specified distance, beyond a specified distance and BBOX. -- A standard set of temporal predicates: after, before, begins, begun by, contains, during, ends, equals, meets, met by, overlaps and overlapped by. -- A predicate to test whether the identifier of an object matches the specified value. -ISO 19143:2010 defines the XML encoding of metadata that allows a service to declare which conformance classes, predicates, operators, operands and functions it supports. This metadata is referred to as Filter Capabilities. - L'ISO 19143:2010 décrit un encodage en XML et KVP d'une syntaxe neutre de système destiné à exprimer des clauses de projection, de sélection et de tri collectivement appelées expression d'interrogation. -Ces composants sont modulaires et destinés à être utilisés ensemble ou individuellement par d'autres normes que celles qui référencent l'ISO 19143:2010. -L'ISO 19143:2010 définit un composant abstrait, nommé AbstractQueryExpression, à partir duquel d'autres spécifications peuvent sous-classer des éléments d'interrogation concrets pour mettre en ?uvre des opérations d'interrogation. -L'ISO 19143:2010 définit également un composant d'interrogation abstrait supplémentaire, nommé AbstractAdhocQueryExpression, qui est dérivé du composant AbstractQueryExpression et à partir duquel d'autres spécifications peuvent sous-classer des éléments d'interrogation concrets qui suivent le modèle d'interrogation suivant: -- Un élément d'interrogation abstrait à partir duquel des spécifications de service peuvent sous-classer un élément d'interrogation concret mettant en oeuvre une opération d'interrogation permettant à un client de spécifier une liste de types de ressources, une clause de projection optionnelle, une clause de sélection optionnelle et une clause de tri optionnelle afin d'interroger un sous-ensemble de ressources qui satisfont à la clause de sélection. -Ce modèle est désigné comme étant un modèle d'interrogation ad hoc du fait que le serveur n'est pas informé de l'interrogation jusqu'à ce qu'elle lui soit soumise pour traitement. Cela s'oppose à une expression d'interrogation mémorisée, qui est mémorisée et peut être appelée par un nom ou un identifiant. -L'ISO 19143:2010 décrit également un encodage en XML et en KVP d'une représentation neutre de système d'une clause de sélection. La représentation XML est facilement validée, analysée et transformée en un langage spécifique au serveur requis pour récupérer ou modifier des instances d'objets mémorisées dans certains stockages d'objets permanents. -L'ISO 19143:2010 définit l'encodage en XML pour les prédicats suivants: un ensemble standard de prédicats logiques: and, or and not (et, ou et non); un ensemble standard de prédicats de comparaison: equal to, not equal to, less than, less than or equal to, greater than, greater than or equal to, like, is null and between (égal à, pas égal à, inférieur à, inférieur ou égal à, supérieur à, supérieur ou égal à, comme, est nul et entre); un ensemble standard de prédicats spatiaux: equal, disjoint, touches, within, overlaps, crosses, intersects, contains, within a specified distance, beyond a specified distance and BBOX (égal, disjoint, touche, dans, chevauche, croise, intersecte, contient, à une distance spécifiée, au-delà d'une distance spécifiée et boîte englobante); un ensemble standard de prédicats temporels: after, before, begins, begun by, contains, during, ends, equals, meets, met by, overlaps and overlapped by (après, avant, commence, commencé par, contient, pendant, se termine, égal à, satisfait, satisfait par, chevauche et chevauché par); et un prédicat pour vérifier si l'identifiant d'un objet correspond à la valeur spécifiée. -L'ISO 19143:2010 définit l'encodage en XML des métadonnées qui permettent à un service de déclarer les classes de conformité, les prédicats, les opérateurs, les opérandes et les fonctions qu'il prend en charge. Ces métadonnées sont désignées par le terme Capacités de filtre. - - 90 - 93 - - - 2010 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19143 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19148.xml b/sources/relaton/cache/iso/iso_19148.xml deleted file mode 100644 index 2bac072..0000000 --- a/sources/relaton/cache/iso/iso_19148.xml +++ /dev/null @@ -1,116 +0,0 @@ - - 2024-11-17 - Geographic information - Linear referencing - Geographic information - Linear referencing - Information géographique - Référencement linéaire - Information géographique - Référencement linéaire - https://www.iso.org/standard/75150.html - https://www.iso.org/obp/ui/en/#!iso:std:75150:en - https://www.iso.org/contents/data/standard/07/51/75150.detail.rss - ISO 19148 - ISO 19148(E) - urn:iso:std:iso:19148:stage-60.60 - 19148 - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - - 60 - 60 - - - 2021 - - - ISO - - - - - - ISO 19148:2012 - ISO 19148:2012 - - - - - 2024-11-17 - Geographic information - Linear referencing - Geographic information - Linear referencing - Information géographique - Référencement linéaire - Information géographique - Référencement linéaire - https://www.iso.org/standard/75150.html - https://www.iso.org/obp/ui/en/#!iso:std:75150:en - https://www.iso.org/contents/data/standard/07/51/75150.detail.rss - ISO 19148:2021 - ISO 19148:2021(E) - urn:iso:std:iso:19148:stage-60.60 - 19148 - - 2021-04 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - This document specifies a conceptual schema for locations relative to a one-dimensional object as measurement along (and optionally offset from) that object. It defines a description of the data and operations required to use and support linear referencing. -This document is applicable to transportation, utilities, environmental protection, location-based services and other applications which define locations relative to linear objects. For ease of reading, most examples discussed in this document come from the transportation domain. - Le présent document spécifie un schéma conceptuel pour les localisations par rapport à un objet à une seule dimension sous la forme d'une mesure le long de cet objet (et éventuellement décalées par rapport à celui-ci). Il définit une description des données et des opérations nécessaires pour utiliser et prendre en charge le référencement linéaire. -Le présent document est applicable aux transports, aux utilités, à la protection de l'environnement, aux services géolocalisés et aux autres applications qui définissent des localisations par rapport à des objets linéaires. Afin de faciliter la lecture, la plupart des exemples abordés dans le présent document proviennent du domaine des transports. - - 60 - 60 - - - 2021 - - - ISO - - - - - - ISO 19148:2012 - ISO 19148:2012 - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19148 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19149.xml b/sources/relaton/cache/iso/iso_19149.xml deleted file mode 100644 index 7c1a515..0000000 --- a/sources/relaton/cache/iso/iso_19149.xml +++ /dev/null @@ -1,110 +0,0 @@ - - 2024-11-17 - Geographic information - Rights expression language for geographic information - GeoREL - Geographic information - Rights expression language for geographic information - GeoREL - Information géographique - Langue sur l'expression des droits pour l'utilisation de l'information géographique - GeoREL - Information géographique - Langue sur l'expression des droits pour l'utilisation de l'information géographique - GeoREL - https://www.iso.org/standard/32567.html - https://www.iso.org/contents/data/standard/03/25/32567.detail.rss - ISO 19149 - ISO 19149(E) - urn:iso:std:iso:19149:stage-95.99 - 19149 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 95 - 99 - - - 2011 - - - ISO - - - - - - 2024-11-17 - Geographic information - Rights expression language for geographic information - GeoREL - Geographic information - Rights expression language for geographic information - GeoREL - Information géographique - Langue sur l'expression des droits pour l'utilisation de l'information géographique - GeoREL - Information géographique - Langue sur l'expression des droits pour l'utilisation de l'information géographique - GeoREL - https://www.iso.org/standard/32567.html - https://www.iso.org/contents/data/standard/03/25/32567.detail.rss - ISO 19149:2011 - ISO 19149:2011(E) - urn:iso:std:iso:19149:stage-95.99 - 19149 - - 2011-11 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19149:2011 defines an XML-based vocabulary or language to express rights for geographic information in order that digital licenses can be created for such information and related services. This language, GeoREL, is an extension of the rights expression language in ISO/IEC 21000-5 and is to be used to compose digital licenses. Each digital license will unambiguously express those particular rights that the owners (or their agent) of a digital geographic resource extend to the holders of that license. The digital rights management system in which these licenses are used can then offer ex ante (before the fact) protection for all such resources. -NOTE The proper use of a GeoREL includes the preservation of rights access by formula expressed in usage licenses. Thus, data in the public or private domain, when protected, remain in their respective domains if the usage rights granted so state. -These "rights" are not always covered by copyright law, and are often the result of contracts between individuals that specify the proper and allowed uses of resources, as opposed to the threat of copyright litigations which is an ex post facto (after the fact) remediation measure, not an ex ante protection measure. ISO 19149:2011 is not a reflection of, or extension of, copyright law. -Mechanisms for the enforcement and preservation of those contract rights are specified in ISO/IEC 21000, and it is not the intention of ISO 19149:2011 to replace nor redefine those mechanisms, but to use them as previously standardized. - ISO 19149:2011 defines an XML-based vocabulary or language to express rights for geographic information in order that digital licenses can be created for such information and related services. This language, GeoREL, is an extension of the rights expression language in ISO/IEC 21000-5 and is to be used to compose digital licenses. Each digital license will unambiguously express those particular rights that the owners (or their agent) of a digital geographic resource extend to the holders of that license. The digital rights management system in which these licenses are used can then offer ex ante (before the fact) protection for all such resources. -NOTE The proper use of a GeoREL includes the preservation of rights access by formula expressed in usage licenses. Thus, data in the public or private domain, when protected, remain in their respective domains if the usage rights granted so state. -These "rights" are not always covered by copyright law, and are often the result of contracts between individuals that specify the proper and allowed uses of resources, as opposed to the threat of copyright litigations which is an ex post facto (after the fact) remediation measure, not an ex ante protection measure. ISO 19149:2011 is not a reflection of, or extension of, copyright law. -Mechanisms for the enforcement and preservation of those contract rights are specified in ISO/IEC 21000, and it is not the intention of ISO 19149:2011 to replace nor redefine those mechanisms, but to use them as previously standardized. - - 95 - 99 - - - 2011 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19149 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19153.xml b/sources/relaton/cache/iso/iso_19153.xml deleted file mode 100644 index d121fc0..0000000 --- a/sources/relaton/cache/iso/iso_19153.xml +++ /dev/null @@ -1,111 +0,0 @@ - - 2024-11-17 - Geospatial Digital Rights Management Reference Model (GeoDRM RM) - Geospatial Digital Rights Management Reference Model (GeoDRM RM) - Modèle de référence pour la gestion numérique des droits d'utilisation de l'information géographique - Modèle de référence pour la gestion numérique des droits d'utilisation de l'information géographique - https://www.iso.org/standard/32571.html - https://www.iso.org/contents/data/standard/03/25/32571.detail.rss - ISO 19153 - ISO 19153(E) - urn:iso:std:iso:19153:stage-95.99 - 19153 - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - - 95 - 99 - - - 2014 - - - ISO - - - - - - 2024-11-17 - Geospatial Digital Rights Management Reference Model (GeoDRM RM) - Geospatial Digital Rights Management Reference Model (GeoDRM RM) - Modèle de référence pour la gestion numérique des droits d'utilisation de l'information géographique - Modèle de référence pour la gestion numérique des droits d'utilisation de l'information géographique - https://www.iso.org/standard/32571.html - https://www.iso.org/contents/data/standard/03/25/32571.detail.rss - ISO 19153:2014 - ISO 19153:2014(E) - urn:iso:std:iso:19153:stage-95.99 - 19153 - - 2014-02 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 1 - en - fr - - ISO 19153:2014 is a reference model for digital rights management (DRM) functionality for geospatial resources (GeoDRM). As such, it is connected to the general DRM market in that geospatial resources shall be treated as nearly as possible like other resources, such as music, text, or services. It is not the intention to reinvent a market nor the technology that already exists and is thriving, but to make sure that a larger market has access to geospatial resources through a mechanism that it understands and that is similar to and consistent with the ones already in use. -ISO 19153:2014 does not replace any previous standards, but it is dependent upon them. Each resource and service standard that exists or will exist becomes a resource description in ISO 19153:2014, and hopefully will be subject to the same protection that is afforded to other resources. -This International Standard defines: -- A conceptual model for digital rights management of geospatial resources, providing a framework and reference for more detailed specification in this area. -- A metadata model for the expression of rights that associate users to the acts that they can perform against a particular geospatial resource, and associated information used in the enforcement and granting of those rights, such as owner metadata, available rights, and issuer of those rights. -- Requirements that are placed on rights management systems for the enforcement of those rights. A rights management system shall be necessary and sufficient: it shall implement only those restrictions necessary to enforce the rights defined therein, and it shall be sufficient to enforce those rights. -- How this is to work conceptually in the larger DRM context to ensure the ubiquity of geospatial resources in the general services market. -A resource in this context is a data file, or service for geographic information or process. -This abstract descriptive standard builds on and complements the existing standards, and defines at an abstract level a rights model to enable the digital rights management of standards-based geospatial resources. Future GeoDRM standards will be written to implement the concepts defined in ISO 19153:2014. - L'ISO 19153:2014 est un modèle de référence pour la fonctionnalité de la gestion numérique des droits (DRM) des ressources géospatiales (géo-DRM). En tant que telle, elle est reliée au marché général de la DRM, étant donné que les ressources géospatiales doivent être traitées autant que possible comme d'autres ressources, telles que de la musique, des textes, ou des services. -L'ISO 19153:2014 définit: -- Un modèle conceptuel pour une gestion numérique des droits des ressources géospatiales, fournissant un cadre et une référence à une spécification plus détaillée dans ce domaine. -- Un modèle de métadonnées pour l'expression de droits qui associe les utilisateurs aux actions qu'ils peuvent accomplir envers une ressource géospatiale particulière, et une information associée utilisée dans la mise en application et la concession de ces droits, tels que des métadonnées de propriétaire, des droits disponibles et des émetteurs de ces droits. -- Des exigences placées sur des systèmes de gestion de droits pour la mise en application de ces droits. Un système de gestion des droits doit être nécessaire et suffisant: il doit mettre uniquement en oeuvre les restrictions nécessaires pour imposer les droits qui y sont définis, et doit être suffisant pour imposer ces droits. -- La manière dont cela doit fonctionner du point de vue conceptuel dans le contexte plus vaste de DRM afin d'assurer l'omniprésence des ressources géographiques sur le marché général des services. -Une ressource dans ce contexte est un fichier de données, un service d'information ou de méthodes géographiques. -La présente norme descriptive abstraite se fonde sur les normes existantes et les complète, et définit à un niveau abstrait un modèle de droits qui permet la gestion numérique des droits des ressources géospatiales basées sur des normes. Les futures normes géo-DRM seront rédigées de manière à mettre en oeuvre les concepts définis dans l'ISO 19153:2014. - - 95 - 99 - - - 2014 - - - ISO - - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19153 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_19156.xml b/sources/relaton/cache/iso/iso_19156.xml deleted file mode 100644 index 9d466d1..0000000 --- a/sources/relaton/cache/iso/iso_19156.xml +++ /dev/null @@ -1,118 +0,0 @@ - - 2024-11-17 - Geographic information - Observations, measurements and samples - Geographic information - Observations, measurements and samples - Information géographique - Observations, mesures et échantillons - Information géographique - Observations, mesures et échantillons - https://www.iso.org/standard/82463.html - https://www.iso.org/obp/ui/en/#!iso:std:82463:en - https://www.iso.org/contents/data/standard/08/24/82463.detail.rss - ISO 19156 - ISO 19156(E) - urn:iso:std:iso:19156:stage-60.60 - 19156 - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - - 60 - 60 - - - 2023 - - - ISO - - - - - - ISO 19156:2011 - ISO 19156:2011 - - - - - 2024-11-17 - Geographic information - Observations, measurements and samples - Geographic information - Observations, measurements and samples - Information géographique - Observations, mesures et échantillons - Information géographique - Observations, mesures et échantillons - https://www.iso.org/standard/82463.html - https://www.iso.org/obp/ui/en/#!iso:std:82463:en - https://www.iso.org/contents/data/standard/08/24/82463.detail.rss - ISO 19156:2023 - ISO 19156:2023(E) - urn:iso:std:iso:19156:stage-60.60 - 19156 - - 2023-04 - - - - - International Organization for Standardization - ISO - www.iso.org - - - 2 - en - fr - - This document defines a conceptual schema for observations, for features involved in the observation process, and for features involved in sampling when making observations. These provide models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. -Observations commonly involve sampling of an ultimate feature-of-interest. This document defines a common set of sample types according to their spatial, material (for ex situ observations) or statistical nature. The schema includes relationships between sample features (sub-sampling, derived samples). -This document concerns only externally visible interfaces and places no restriction on the underlying implementations other than what is needed to satisfy the interface specifications in the actual situation. - Le présent document définit un schéma conceptuel pour les observations, pour les entités impliquées dans le processus d'observation et pour les entités impliquées dans l'échantillonnage des données dans le cadre des observations. Celles-ci fournissent des modèles destinés à l'échange d'informations décrivant les faits observés et leurs résultats, aussi bien entre les différentes communautés scientifiques et techniques qu'en leur sein. -En général, les observations impliquent l'échantillonnage d'une entité concernée finale. Le présent document définit un ensemble commun de types d'échantillons en fonction de leur nature spatiale matérielle (pour les observations ex-situ) ou statistique. Ce schéma comprend les relations entre les entités d'échantillonnage (sous-échantillonnage, échantillons dérivés). -Le présent document ne concerne que les interfaces visibles de l'extérieur et ne place aucune restriction quant aux implémentations sous-jacentes, autres que celles nécessaires pour satisfaire aux spécifications relatives aux interfaces dans le contexte actuel. - - 60 - 60 - - - 2023 - - - ISO - - - - - - ISO 19156:2011 - ISO 19156:2011 - - - Geneva - - - Geneva - - international-standard - - Geographic information/Geomatics - - - 35.240.70 - IT applications in science - - - ISO 19156 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_10000-1.notfound b/sources/relaton/cache/iso/iso_iec_10000-1.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/iso/iso_iec_10000-1.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml b/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml deleted file mode 100644 index 0af4c11..0000000 --- a/sources/relaton/cache/iso/iso_iec_13249-3_2006.xml +++ /dev/null @@ -1,85 +0,0 @@ - - 2024-11-17 - Information technology - Database languages - SQL multimedia and application packages -- Part 3: Spatial - Information technology - Database languages - SQL multimedia and application packages -- Part 3: Spatial - Technologies de l'information - Langages de bases de données - Multimédia SQL et paquetages d'application -- Partie 3: Spatial - Technologies de l'information - Langages de bases de données - Multimédia SQL et paquetages d'application -- Partie 3: Spatial - https://www.iso.org/standard/38651.html - https://www.iso.org/contents/data/standard/03/86/38651.detail.rss - ISO/IEC 13249-3:2006 - ISO/IEC 13249-3:2006(E) - urn:iso:std:iso-iec:13249:-3:stage-95.99 - 13249 - - 2006-11 - - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 3 - en - fr - - ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. -Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. - ISO/IEC 13249-3:2006 defines spatial user-defined types, routines and schemas for generic spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology. -Implementations of ISO/IEC 13249-3:2006 may exist in environments that also support geographic information, decision support, data mining, and data warehousing systems. Application areas addressed by implementations of ISO/IEC 13249-3:2006 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, location based services, multimedia, and resource management applications. - - 95 - 99 - - - 2006 - - - ISO/IEC - - - - - - ISO/IEC 13249-3:2003 - ISO/IEC 13249-3:2003 - - - - - ISO/IEC 13249-3:2011 - ISO/IEC 13249-3:2011 - - 2011-04-07 - - - - Geneva - - international-standard - - Data management and interchange - - - 35.060 - Languages used in information technology - - - ISO 13249 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_19501.xml b/sources/relaton/cache/iso/iso_iec_19501.xml deleted file mode 100644 index 3806e09..0000000 --- a/sources/relaton/cache/iso/iso_iec_19501.xml +++ /dev/null @@ -1,122 +0,0 @@ - - 2024-11-17 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 - Technologies de l'information - Traitement distribué ouvert - Langage de modélisation unifié (UML), version 1.4.2 - Technologies de l'information - Traitement distribué ouvert - Langage de modélisation unifié (UML), version 1.4.2 - https://www.iso.org/standard/32620.html - https://www.iso.org/obp/ui/en/#!iso:std:32620:en - https://www.iso.org/contents/data/standard/03/26/32620.detail.rss - ISO/IEC 19501 - ISO/IEC 19501(E) - urn:iso:std:iso-iec:19501:stage-90.60 - 19501 - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 1 - en - fr - - - 90 - 60 - - - 2005 - - - ISO/IEC - - - - - - 2024-11-17 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 - Technologies de l'information - Traitement distribué ouvert - Langage de modélisation unifié (UML), version 1.4.2 - Technologies de l'information - Traitement distribué ouvert - Langage de modélisation unifié (UML), version 1.4.2 - https://www.iso.org/standard/32620.html - https://www.iso.org/obp/ui/en/#!iso:std:32620:en - https://www.iso.org/contents/data/standard/03/26/32620.detail.rss - ISO/IEC 19501:2005 - ISO/IEC 19501:2005(E) - urn:iso:std:iso-iec:19501:stage-90.60 - 19501 - - 2005-04 - - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 1 - en - fr - - ISO/IEC 19501:2004 describes the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components. - ISO/IEC 19501:2004 describes the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components. - - 90 - 60 - - - 2005 - - - ISO/IEC - - - - Geneva - - - Geneva - - international-standard - - Information technology - - - 35.080 - Software - - - ISO 19501 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml b/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml deleted file mode 100644 index 7b2c37d..0000000 --- a/sources/relaton/cache/iso/iso_iec_19757-3_2006.xml +++ /dev/null @@ -1,79 +0,0 @@ - - 2024-11-17 - Information technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation — Schematron - Information technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation — Schematron - Technologies de l'information - Langages de définition de schéma de documents (DSDL) - Partie 3: Validation de règles orientées — Schematron - Technologies de l'information - Langages de définition de schéma de documents (DSDL) - Partie 3: Validation de règles orientées — Schematron - https://www.iso.org/standard/40833.html - https://www.iso.org/contents/data/standard/04/08/40833.detail.rss - ISO/IEC 19757-3:2006 - ISO/IEC 19757-3:2006(E) - urn:iso:std:iso-iec:19757:-3:stage-95.99 - 19757 - - 2006-06 - - - - - International Organization for Standardization - ISO - www.iso.org - - - - - - International Electrotechnical Commission - IEC - www.iec.ch - - - 1 - en - fr - - ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) -ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. - ISO/IEC 19757 defines a set of Document Schema Definition Languages (DSDL) that can be used to specify one or more validation processes performed against Extensible Markup Language (XML) or Standard Generalized Markup Language (SGML) documents. (XML is an application profile SGML, ISO 8879:1986.) -ISO/IEC 19757-3:2006 specifies Schematron, a rules-based schema language for XML. It establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema. - - 95 - 99 - - - 2006 - - - ISO/IEC - - - - - - ISO/IEC 19757-3:2016 - ISO/IEC 19757-3:2016 - - 2016-01-14 - - - - Geneva - - international-standard - - Document description and processing languages - - - 35.240.30 - IT applications in information, documentation and publishing - - - ISO 19757 - - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_9075_2003.notfound b/sources/relaton/cache/iso/iso_iec_9075_2003.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/iso/iso_iec_9075_2003.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_dir_2.xml b/sources/relaton/cache/iso/iso_iec_dir_2.xml deleted file mode 100644 index 412c578..0000000 --- a/sources/relaton/cache/iso/iso_iec_dir_2.xml +++ /dev/null @@ -1,52 +0,0 @@ - - 2024-11-17 - ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents - Directives ISO/CEI, Partie 2 - Principes et règles de structure et de rédaction des documents ISO et IEC - https://www.iso.org/sites/directives/current/part2/index.xhtml - ISO/IEC DIR 2 - 9 - en - - - 2021 - - - International Organization for Standardization - ISO - www.iso.org - - - - - - 2024-11-17 - ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents - Directives ISO/CEI, Partie 2 - Principes et règles de structure et de rédaction des documents ISO et IEC - https://www.iso.org/sites/directives/current/part2/index.xhtml - ISO/IEC DIR 2 - - 2021-05-01 - - 9 - en - - - 2021 - - - International Organization for Standardization - ISO - www.iso.org - - - - - - - directive - - \ No newline at end of file diff --git a/sources/relaton/cache/iso/iso_iec_tr_10000.notfound b/sources/relaton/cache/iso/iso_iec_tr_10000.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/iso/iso_iec_tr_10000.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/iso/version b/sources/relaton/cache/iso/version deleted file mode 100644 index e4c59dc..0000000 --- a/sources/relaton/cache/iso/version +++ /dev/null @@ -1 +0,0 @@ -d4cbf244102652ea31d565b43af29b3f \ No newline at end of file diff --git a/sources/relaton/cache/ogc/08-079.xml b/sources/relaton/cache/ogc/08-079.xml deleted file mode 100644 index b71d36b..0000000 --- a/sources/relaton/cache/ogc/08-079.xml +++ /dev/null @@ -1,34 +0,0 @@ - - 2024-11-17 - OWS5: OGC Web feature service, core and extensions - OWS5: OGC Web feature service, core and extensions - - https://portal.ogc.org/files/?artifact_id=28176 - 08-079 - - 2008-09-12 - - - - - - John Herring - - - - - - - Open Geospatial Consortium - - - en - - This standard specifies the behavior of a service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies discovery operations, query operations and transaction operations. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Retrieval operations allow features to be retrieved from the opaque underlying data store based upon constraints on spatial and non-spatial feature properties defined by the client. Transaction operations allow features to be created, changed and deleted from the opaque underlying data store. - - discussion-paper - - technical - - - \ No newline at end of file diff --git a/sources/relaton/cache/ogc/ogc_08-079.redirect b/sources/relaton/cache/ogc/ogc_08-079.redirect deleted file mode 100644 index 2c8c1b3..0000000 --- a/sources/relaton/cache/ogc/ogc_08-079.redirect +++ /dev/null @@ -1 +0,0 @@ -redirection OGC(08-079) \ No newline at end of file diff --git a/sources/relaton/cache/ogc/version b/sources/relaton/cache/ogc/version deleted file mode 100644 index 8ada7e3..0000000 --- a/sources/relaton/cache/ogc/version +++ /dev/null @@ -1 +0,0 @@ -b4be7d3992a3f62eee3c0fb4a545190c \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.1.1_infrastructure.notfound b/sources/relaton/cache/omg/omg_uml_2.1.1_infrastructure.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.1.1_infrastructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.1.1_superstructure.notfound b/sources/relaton/cache/omg/omg_uml_2.1.1_superstructure.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.1.1_superstructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.1.2_infrastructure.notfound b/sources/relaton/cache/omg/omg_uml_2.1.2_infrastructure.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.1.2_infrastructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/omg/omg_uml_2.1.2_superstructure.notfound b/sources/relaton/cache/omg/omg_uml_2.1.2_superstructure.notfound deleted file mode 100644 index f297c80..0000000 --- a/sources/relaton/cache/omg/omg_uml_2.1.2_superstructure.notfound +++ /dev/null @@ -1 +0,0 @@ -not_found 2024-11-17 \ No newline at end of file diff --git a/sources/relaton/cache/omg/version b/sources/relaton/cache/omg/version deleted file mode 100644 index 49091a0..0000000 --- a/sources/relaton/cache/omg/version +++ /dev/null @@ -1 +0,0 @@ -819940ce0d14f052770ac65942363e11 \ No newline at end of file diff --git a/sources/relaton/cache/w3c/version b/sources/relaton/cache/w3c/version deleted file mode 100644 index 49091a0..0000000 --- a/sources/relaton/cache/w3c/version +++ /dev/null @@ -1 +0,0 @@ -819940ce0d14f052770ac65942363e11 \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema-1.xml b/sources/relaton/cache/w3c/w3c_xmlschema-1.xml deleted file mode 100644 index d9f664f..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema-1.xml +++ /dev/null @@ -1,41 +0,0 @@ - - 2024-11-17 - XML Schema Part 1: Structures Second Edition - https://www.w3.org/TR/xmlschema-1/ - W3C xmlschema-1 - xmlschema-1 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - Recommendation - - - - W3C REC-xmlschema-1-20010502 - https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ - W3C REC-xmlschema-1-20010502 - - - - - W3C REC-xmlschema-1-20041028 - https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ - W3C REC-xmlschema-1-20041028 - - - - W3C REC - xmlschema-1 - - - technicalReport - - \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema-2.xml b/sources/relaton/cache/w3c/w3c_xmlschema-2.xml deleted file mode 100644 index 9ebf0dc..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema-2.xml +++ /dev/null @@ -1,41 +0,0 @@ - - 2024-11-17 - XML Schema Part 2: Datatypes Second Edition - https://www.w3.org/TR/xmlschema-2/ - W3C xmlschema-2 - xmlschema-2 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - Recommendation - - - - W3C REC-xmlschema-2-20010502 - https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ - W3C REC-xmlschema-2-20010502 - - - - - W3C REC-xmlschema-2-20041028 - https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ - W3C REC-xmlschema-2-20041028 - - - - W3C REC - xmlschema-2 - - - technicalReport - - \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml b/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml deleted file mode 100644 index 3b8eb10..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema11-1.xml +++ /dev/null @@ -1,104 +0,0 @@ - - 2024-11-17 - W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - http://www.w3.org/TR/xmlschema11-1/ - W3C xmlschema11-1 - xmlschema11-1 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - Working Draft - - - - W3C WD-xmlschema11-1-20040716 - http://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/ - W3C WD-xmlschema11-1-20040716 - - - - - W3C WD-xmlschema11-1-20050224 - http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ - W3C WD-xmlschema11-1-20050224 - - - - - W3C WD-xmlschema11-1-20060330 - http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ - W3C WD-xmlschema11-1-20060330 - - - - - W3C WD-xmlschema11-1-20060831 - http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ - W3C WD-xmlschema11-1-20060831 - - - - - W3C WD-xmlschema11-1-20070830 - http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ - W3C WD-xmlschema11-1-20070830 - - - - - W3C WD-xmlschema11-1-20080620 - http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/ - W3C WD-xmlschema11-1-20080620 - - - - - W3C WD-xmlschema11-1-20090130 - http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/ - W3C WD-xmlschema11-1-20090130 - - - - - W3C CR-xmlschema11-1-20090430 - http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ - W3C CR-xmlschema11-1-20090430 - - - - - W3C WD-xmlschema11-1-20091203 - http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/ - W3C WD-xmlschema11-1-20091203 - - - - - W3C CR-xmlschema11-1-20110721 - http://www.w3.org/TR/2011/CR-xmlschema11-1-20110721/ - W3C CR-xmlschema11-1-20110721 - - - - - W3C PR-xmlschema11-1-20120119 - http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ - W3C PR-xmlschema11-1-20120119 - - - - W3C WD - xmlschema11-1 - - - technicalReport - - \ No newline at end of file diff --git a/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml b/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml deleted file mode 100644 index f5eb0ca..0000000 --- a/sources/relaton/cache/w3c/w3c_xmlschema11-2.xml +++ /dev/null @@ -1,90 +0,0 @@ - - 2024-11-17 - W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - http://www.w3.org/TR/xmlschema11-2/ - W3C xmlschema11-2 - xmlschema11-2 - - - - World Wide Web Consortium - W3C - https://www.w3.org/ - - - en - - - Working Draft - - - - W3C WD-xmlschema11-2-20040716 - http://www.w3.org/TR/2004/WD-xmlschema11-2-20040716/ - W3C WD-xmlschema11-2-20040716 - - - - - W3C WD-xmlschema11-2-20050224 - http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/ - W3C WD-xmlschema11-2-20050224 - - - - - W3C WD-xmlschema11-2-20060217 - http://www.w3.org/TR/2006/WD-xmlschema11-2-20060217/ - W3C WD-xmlschema11-2-20060217 - - - - - W3C WD-xmlschema11-2-20080620 - http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/ - W3C WD-xmlschema11-2-20080620 - - - - - W3C WD-xmlschema11-2-20090130 - http://www.w3.org/TR/2009/WD-xmlschema11-2-20090130/ - W3C WD-xmlschema11-2-20090130 - - - - - W3C CR-xmlschema11-2-20090430 - http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ - W3C CR-xmlschema11-2-20090430 - - - - - W3C WD-xmlschema11-2-20091203 - http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/ - W3C WD-xmlschema11-2-20091203 - - - - - W3C CR-xmlschema11-2-20110721 - http://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/ - W3C CR-xmlschema11-2-20110721 - - - - - W3C PR-xmlschema11-2-20120119 - http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ - W3C PR-xmlschema11-2-20120119 - - - - W3C WD - xmlschema11-2 - - - technicalReport - - \ No newline at end of file