diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc index 123ea52..282956c 100644 --- a/sources/sections/04-terms-and-defs.adoc +++ b/sources/sections/04-terms-and-defs.adoc @@ -4,7 +4,7 @@ [.boilerplate] === {blank} -For the purposes of this document, the following terms and definitions apply. +For the purposes of this Policy, the following terms and definitions apply. Terms not defined here take on 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. @@ -16,6 +16,10 @@ Many of these definitions depend upon the model given in <>. 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 @@ -29,8 +33,7 @@ the conformance test class is sufficient. For example, the OGC currently keeps an online list of conformant applications at http://www.opengeospatial.org/resource/products. -Each certificate of conformance is awarded to a -{{standardization target}}. +Each certificate of conformance is awarded to a {{standardization target}}. ==== === conformance test case @@ -43,16 +46,12 @@ NOTE: When no ambiguity, the word "case" may be omitted. i.e. === conformance test module -set of related tests, all within a single {{conformance test class}} +set of related for against a given requirements module all with the same standardization target [NOTE] ==== -When no ambiguity, the word "test" may be omitted. i.e. -{{conformance test module}} -is the same as *conformance module*. Conformance modules may -be nested in a hierarchical way. - -This term and those associated to it are included here for consistency with ISO 19105. +When there is no ambiguity, the word "test" may be omitted. i.e. {{conformance test module}} +is the same as *conformance module*. Conformance modules may be nested in a hierarchical way. ==== [.source] @@ -61,50 +60,41 @@ This term and those associated to it are included here for consistency with ISO === conformance test class alt:[conformance test level] -set of {{conformance test module,conformance test modules}} that must -be applied to receive a single {{certificate of conformance}} +set of {{conformance tests,conformance test}} that must be passed to receive a single {{certificate of conformance}} [NOTE] ==== -When no ambiguity is possible, the word "test" may be left out, so -{{conformance test class}} +When no ambiguity is possible, the word "test" may be left out, so {{conformance test class}} maybe called a <>. -In this standard, the set of {{requirement,requirements}} tested by the +In this Policy, the set of {{requirement,requirements}} tested by the conformance tests within a <> is a -{{requirements class}} and its dependencies. Each optional {{requirement}} will +{{requirements class}} and its dependencies. Optional {{requirement,requirements}} will be in a separate {{requirements class}} with other {{requirement,requirements}} that are part of the same option. Each {{requirements class}} corresponds to a separate <> -In other words, the only options in a specification conformant to this standard -will be if a particular {{requirements class}} is tested. Each requirements -class will be in a 1 to 1 correspondence to a similarly named +Each requirements class will be in a 1 to 1 correspondence to a similarly named <> that tests all of the {{requirements class,requirements class's}} {{requirement,requirements}}. All {{requirement,requirements}} in a <> will have the same {{standardization target}}. -The term "level" is a synonym for "class" and is part of the ISO nomenclature. -Here the two terms are treated as equivalent but ISO usually has differences in -the way they are named and how they related to one another level or class. ==== === conformance suite +alt:[conformance test suite] +alt:[abstract test suite] -set of <> that define tests for all -{{requirement,requirements}} of a standard +set of <> that define tests for all {{requirement,requirements}} of a standard or abstract specification [NOTE] ==== -The {{conformance suite}} is the union of all -<>. It is by definition the -<> of the entire specification. +The {{conformance suite}} is the union of all <>. It is by definition the +<> of the entire standard or abstract specification. -In this standard, each {{requirement}} is mandatory within its -<> and each {{requirement}} is -tested in at least one {{conformance test}}. +In this Policy, each {{requirement}} is mandatory within its <> and each {{requirement}} is tested in at least one {{conformance test}}. ==== === conformance test @@ -116,11 +106,11 @@ within a standard, or set of standards unique {{requirements class}} that must be satisfied by any conformant {{standardization target,standardization targets}} associated to the -specification +standard [NOTE] ==== -The core {{requirements class}} is unique because if it was possible to have +The core {{requirements class}} is unique because if were possible to have more than one, then each *core* would have to be implemented to pass any {{conformance test class}}, and thus would have to be contained in any other *core*. The *core* may be empty, or all or part of another standard or related @@ -133,8 +123,7 @@ requirements class. === direct dependency (of a requirements class) -another {{requirements class}} (the dependency) whose -{{requirement,requirements}} are defined to also be +another {{requirements class}} (the dependency) whose {{requirement,requirements}} are defined to also be {{requirement,requirements}} of this {{requirements class}} @@ -146,16 +135,14 @@ of the current {{requirements class}} will have the same {{requirements class}}. This is another ways of saying that the current {{requirements class}} extends, or uses all the aspects of the {{direct dependency (of a requirements class), direct dependency}}. -Any tests associated to this +Any tests associated with this {{direct dependency (of a requirements class),dependency}} can be applied to this {{requirements class}}. When testing a {{direct dependency (of a requirements class), direct dependency}}, the -{{standardization target}} is -directly subject to the test in the specified -{{conformance test class}} of the -{{direct dependency (of a requirements class), direct dependency}}. +{{standardization target}} is directly subject to the test in the specified +{{conformance test class}} of the {{direct dependency (of a requirements class), direct dependency}}. ==== === indirect dependency (of a requirements class) @@ -179,13 +166,7 @@ test the same {{standardization target}}, but {{indirect dependency (of a requirements class), indirect dependencies}} test related but different {{standardization target,standardization targets}}. -The {{standardization target}} of the -{{indirect dependency (of a requirements class), indirect dependency}} -is different from the target of "this requirements class" but it may be of the -same or related {{standardization target type}}. For example, if one service is -related to another second service, then a service {{requirement}} may be placed -against the second associated service to assure that the first service has -access to its functionality. For example, if a DRM-enabled service is required +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 @@ -205,37 +186,23 @@ software extensions in a manner analogous to the extension relation between the === general recommendation -recommendation applying to all entities in a specification model +recommendation applying to all entities in a standard === home (of a requirement or recommendation) official statement of a {{requirement}} or {{recommendation}} that is the -precedent for any other version repeated or rephrased elsewhere +precedent for any other version repeated or rephrased elsewhere in a standard [NOTE] ==== -Explanatory text associated to normative language often repeats or rephrases the +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. -These alternative statements use non-normative language and are -{{statement,statements}} using the definitions of the ISO Directives -Part 2. ==== -=== leaf package - -UML model package that does not contain any subpackages, but contains -classifiers - -[.source] -<> - -[.source] -<> - === model alt:[abstract model] alt:[conceptual model] @@ -243,38 +210,21 @@ alt:[conceptual model] theoretical construct that represents something, with a set of variables and a set of logical and quantitative relationships between them. -[NOTE] -==== -Derived from _Wikipedia_ - -The "theoretical construct" is essentially a *conceptual metaphor* with the -*target* of the *metaphor* as the thing being modeled, and the *source* of the -*metaphor* as the {{model}}. The terms are almost interchangeable, with -{{model}} being preferred when the *source* is a constructed entity, and -*metaphor* being preferred when the *source* already exists, and the emphasis is -the mapping between it and the *target*. - -The definition in <> is - -[quote] -____ -*conceptual model* - model that defines concepts of a universe of discourse. -____ - -While adequate in the context of a "universe of discourse" as the something -addressed by a standard, a model need not have any "universality" property at -all. Most often models are representative of only a relatively small portion of -a larger universe, and part of the process of modeling is to factor out the -properties and things to which no interest is directed within the present -standard. It also fails to define "model" which is in fact the central issue -within this discussion. - -The *abstract* or *conceptual* is actually redundant and will often be dropped -in the text. {{model,Models}} are by their vary nature not the same as what they -are describing, and thus must contain a *conceptual metaphor* to describe their -relationship to the *target* (the thing being described) of the model. This -inherently makes them abstractions. -==== +=== module + +one of a set of separate parts that can be joined together to form a larger object + +[.source] +Cambridge Dictionary + +=== 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 @@ -285,15 +235,9 @@ conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. [NOTE] + ==== -This definition has been adopted from <>. The wording has been -changed to accommodate the shared vocabulary of OGC and ISO TC 211 and for -editorial reasons. The original text is "A set of one or more base standards -and/or ISPs, and, where applicable, the identification of chosen classes, -conforming subsets, options and parameters of those base standards, or ISPs -necessary to accomplish a particular function." - -In the usage of this standard, a profile will be a set of requirements classes +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. @@ -307,7 +251,7 @@ implies that the same *target* is conformant to the standards referenced in the === recommendation -expression in the content of a document conveying that among several +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 @@ -318,33 +262,30 @@ a {{requirement}}. The usual form replaces the "shall" (imperative or command) of a {{requirement}} with a "should" (suggestive or conditional). +NOTE: Recommendations are *not* tested and therefor have no related conformance test. + [.source] <> === requirement -expression in the content of a document conveying criteria to be fulfilled if -compliance with the document is to be claimed and from which no deviation is permitted +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] ==== Each {{requirement}} is a normative criterion for a single -*type of standardization target*. In this standard, requirements will be +*type of standardization target*. In this Policy, requirements are associated to {{conformance test, conformance tests}} that can be used to prove compliance to the underlying criteria by the {{standardization target}}. The implementation of a {{requirement}} is dependent on the type of -specification being written. A data specification requires data structures, but +standard being written. A data standard requires data structures, but a procedural specification requires software implementations. The view of a standard in terms of a set of testable {{requirement,requirements}} allows us to use set descriptions of both the standard and its implementations. -The specification of a {{requirement}} is usually expressed in terms of a model -of the {{standardization target}}, such as a UML model, or an XML or SQL schema. -Anything without a defined test is _a priori_ not testable and thus would be -better expressed as a {{recommendation}}. - -{{requirement,Requirements}} use normative language and in particular are +{{requirement,Requirements}} use normative language and are commands and use the imperative "shall" or similar imperative constructs. Statements in standards which are not requirements and need to be either conditional or future tense normally use "will" and should not be confused with @@ -356,8 +297,8 @@ requirements that use "shall" imperatively. === requirements class -aggregate of all {{requirements module,requirement modules}} that -must all be satisfied to satisfy a {{conformance test class}} +aggregate of all {{requirements,requirement}} with a single standrdization target that +must all be satisfied to pass a {{conformance test class}} NOTE: There is some confusion possible here, since the testing of indirect dependencies seems to violate this definition. But the existence of an indirect @@ -367,15 +308,9 @@ relationship from the original target to something that has a property === requirements module -aggregate of {{requirement,requirements}} and -{{recommendation,recommendations}} of a specification against a -single {{standardization target type}} - -NOTE: This term is included to be consistent with the use of modules in ISO -19105. The third type of normative language, the "permission" which uses "may," -is not considered here mainly because it is usually 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. +collection of {{requirement class,requirements classes}}, +{{recommendation,recommendations}} and {{permission,permissions}} with a +single {{standardization target}} === specification @@ -393,7 +328,7 @@ contain the three types of element cited. === standard -{{specification}} that has been approved by a legitimate Standards Body +document that has been approved by a legitimate Standards Body [NOTE] ==== @@ -402,11 +337,6 @@ This definition is included for completeness. {{standard,Standard}} and always valid, {{standard}} only applies after the adoption of the document by a legitimate standards organization. -The legitimate Standards Bodies for OGC consist of OGC, ISO and any of the other -standards bodies accepted and used as a source of normative references by OGC or -ISO in their standards. In the normal meaning of the word "standard", there are -other conditions that may be required, but this standard has chosen to ignore -them in the process of abstraction. ==== === standardization target @@ -416,31 +346,14 @@ entity to which some {{requirement,requirements}} of a {{standard}} apply NOTE: The {{standardization target}} is the entity which may receive a {{certificate of conformance}} for a {{requirements class}}. +NOTE: Need to add examples! To wit: For example, the standardization target for the OGC API - Features - Part 2: Coordinate Reference Systems by Reference Standard is to extend the core capabilities specified in Part 1: Core so that implementations have the ability to use coordinate reference system identifiers other than the defaults defined in the core. The standardization target of the CDB version 2.0 CRS Requirements Classes is to clearly define (with metadata) a CRS for a CDB compliant datastore. + === standardization target type type of entity or set of entities to which the {{requirement,requirements}} of a {{standard}} apply -[NOTE] -==== -The {{standardization target type,standardization target types}} give -the {{standardization target,standardization targets}} a typing -system similar to the UML classifiers. In general, the types inherit from one -another in the same way that UML classes do. The same class/metaclass semantics -apply, and two targets can be considered to have the "same type" (in a -particular situation) if their instantiation types share the appropriate -supertype, as is the case in UML. - -In OGC for example, all service types that must pass the OWS (Open Web Services) -Common specification are some extension of the "Open Web Service" -{{standardization target type}}. This makes OWS Common a default -"global core" for all OGC Services. - -In some cases, the {{standardization target type}} may be another -specification. A GML application schema is a -{{standardization target}} for the GML standard, but is in turn a -specification of instances of that application schema. -==== +NOTE: Need examples. To wit: For example, the standardization target type for The OGC API – Features Standard are Web APIs. The standardization target type for the CDB Standard is a datastore compliant with the requirements as stated in the CDB Standard. === statement