From e9bcb9b3fd4e49d3e1fda151cb2b5463d430b9c3 Mon Sep 17 00:00:00 2001 From: Ronald Tse Date: Tue, 25 Jun 2024 21:08:41 +0800 Subject: [PATCH] chore: clean up syntax --- sources/sections/04-terms-and-defs.adoc | 434 ++++++++++++------------ sources/sections/ac-definitions.adoc | 95 +++--- 2 files changed, 263 insertions(+), 266 deletions(-) diff --git a/sources/sections/04-terms-and-defs.adoc b/sources/sections/04-terms-and-defs.adoc index 3bd014a..123ea52 100644 --- a/sources/sections/04-terms-and-defs.adoc +++ b/sources/sections/04-terms-and-defs.adoc @@ -4,32 +4,33 @@ [.boilerplate] === {blank} -For the purposes of this document, 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. +For the purposes of this document, 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. 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 +XML schema document which includes, either directly or through the inclusion of +other schema documents, all schema components associated to its namespace === certificate of conformance -evidence of conformance to all or part of a standard, awarded for passing one or more -of the {{conformance test class,conformance test classes,options="noref"}} specified -in that standard +evidence of conformance to all or part of a standard, awarded for passing one or +more of the {{conformance test class,conformance test classes}} specified in +that standard [NOTE] ==== -"Certificates" do not have to be instantiated documents; having proof of passing the -conformance test class is sufficient. For example, the OGC currently keeps an online -list of conformant applications at http://www.opengeospatial.org/resource/products. +"Certificates" do not have to be instantiated documents; having proof of passing +the conformance test class is sufficient. For example, the OGC currently keeps +an online list of conformant applications at +http://www.opengeospatial.org/resource/products. Each certificate of conformance is awarded to a -{{standardization target,options="noref"}}. +{{standardization target}}. ==== === conformance test case @@ -37,17 +38,17 @@ Each certificate of conformance is awarded to a test for a particular requirement or a set of related requirements NOTE: When no ambiguity, the word "case" may be omitted. i.e. -{{conformance test,options="noref"}} is the same as -{{conformance test case,options="noref"}}. +{{conformance test}} is the same as +{{conformance test case}}. === conformance test module -set of related tests, all within a single {{conformance test class,options="noref"}} +set of related tests, all within a single {{conformance test class}} [NOTE] ==== When no ambiguity, the word "test" may be omitted. i.e. -{{conformance test module,options="noref"}} +{{conformance test module}} is the same as *conformance module*. Conformance modules may be nested in a hierarchical way. @@ -60,153 +61,147 @@ 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,options="noref"}} that must -be applied to receive a single {{certificate of conformance,options="noref"}} +set of {{conformance test module,conformance test modules}} that must +be applied to receive a single {{certificate of conformance}} [NOTE] ==== When no ambiguity is possible, the word "test" may be left out, so -{{conformance test class,options="noref"}} +{{conformance test class}} maybe called a <>. -In this standard, the set of {{requirement,requirements,options="noref"}} tested by -the conformance tests within a <> is a -{{requirements class,options="noref"}} and its dependencies. Each optional -{{requirement,options="noref"}} will be in a separate -{{requirements class,options="noref"}} -with other {{requirement,requirements,options="noref"}} that -are part of the same option. Each {{requirements class,options="noref"}} corresponds -to a separate <> - -In other words, the only options in a specification conformant to this standard will -be if a particular {{requirements class,options="noref"}} is tested. Each -requirements class will be in a 1 to 1 correspondence to a similarly named +In this standard, the set of {{requirement,requirements}} tested by the +conformance tests within a <> is a +{{requirements class}} and its dependencies. Each optional {{requirement}} 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 <> that tests all of the -{{requirements class,requirements class's,options="noref"}} -{{requirement,requirements,options="noref"}}. +{{requirements class,requirements class's}} {{requirement,requirements}}. -All {{requirement,requirements,options="noref"}} in a -<> will have the same -{{standardization target,options="noref"}}. +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. +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 set of <> that define tests for all -{{requirement,requirements,options="noref"}} of a standard +{{requirement,requirements}} of a standard [NOTE] ==== -The {{conformance suite,options="noref"}} is the union of all +The {{conformance suite}} is the union of all <>. It is by definition the <> of the entire specification. -In this standard, each {{requirement,options="noref"}} is mandatory within its -<> and each {{requirement,options="noref"}} is -tested in at least one {{conformance test,options="noref"}}. +In this standard, each {{requirement}} is mandatory within its +<> and each {{requirement}} is +tested in at least one {{conformance test}}. ==== === conformance test -test, abstract or real, of one or more {{requirement,requirements,options="noref"}} -contained within a standard, or set of standards +test, abstract or real, of one or more {{requirement,requirements}} contained +within a standard, or set of standards === core requirements class -unique {{requirements class,options="noref"}} that must be satisfied by any -conformant {{standardization target,standardization targets,options="noref"}} -associated to the specification +unique {{requirements class}} that must be satisfied by any conformant +{{standardization target,standardization targets}} associated to the +specification [NOTE] ==== -The core {{requirements class,options="noref"}} is unique because if it was possible -to have more than one, then each *core* would have to be implemented to pass any -{{conformance test class,options="noref"}}, 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,options="noref"}}, its associated -{{conformance test class,options="noref"}} or the software module that implements -that requirements class. +The core {{requirements class}} is unique because if it was possible to have +more than one, then each *core* would have to be implemented to pass any +{{conformance test class}}, and thus would have to be contained in any other +*core*. The *core* may be empty, or all or part of another standard or related +set of standards. + +The "*core*" can refer to this {{requirements class}}, its associated +{{conformance test class}} or the software module that implements that +requirements class. ==== === direct dependency (of a requirements class) -another {{requirements class,options="noref"}} (the dependency) whose -{{requirement,requirements,options="noref"}} are defined to also be -{{requirement,requirements,options="noref"}} of this -{{requirements class,options="noref"}} +another {{requirements class}} (the dependency) whose +{{requirement,requirements}} are defined to also be +{{requirement,requirements}} of this +{{requirements class}} [NOTE] ==== -A {{direct dependency (of a requirements class), direct dependency,options="noref"}} -of the current {{requirements class,options="noref"}} will have the same -{{standardization target,options="noref"}} as the current -{{requirements class,options="noref"}}. This is another ways of saying that the current -{{requirements class,options="noref"}} extends, or uses all the aspects of the -{{direct dependency (of a requirements class), direct dependency,options="noref"}}. +A {{direct dependency (of a requirements class), direct dependency}} +of the current {{requirements class}} will have the same +{{standardization target}} as the current +{{requirements class}}. This is another ways of saying that the current +{{requirements class}} extends, or uses all the aspects of the +{{direct dependency (of a requirements class), direct dependency}}. Any tests associated to this -{{direct dependency (of a requirements class),dependency,options="noref"}} can be applied to this -{{requirements class,options="noref"}}. +{{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,options="noref"}}, the -{{standardization target,options="noref"}} is +{{direct dependency (of a requirements class), direct dependency}}, the +{{standardization target}} is directly subject to the test in the specified -{{conformance test class,options="noref"}} of the -{{direct dependency (of a requirements class), direct dependency,options="noref"}}. +{{conformance test class}} of the +{{direct dependency (of a requirements class), direct dependency}}. ==== === indirect dependency (of a requirements class) -{{requirements class,options="noref"}} with a different -{{standardization target,options="noref"}} which is used, produced or associated to by the -implementation of this {{requirements class,options="noref"}} +{{requirements class}} with a different +{{standardization target}} which is used, produced or associated to by the +implementation of this {{requirements class}} [NOTE] ==== In this instance, as opposed to the -{{direct dependency (of a requirements class),direct dependency,options="noref"}}, +{{direct dependency (of a requirements class),direct dependency}}, the test against the consumable or product used -or produced by the {{requirements class,options="noref"}} does not directly test the -{{requirements class,options="noref"}}, 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, +or produced by the {{requirements class}} does not directly test the +{{requirements class}}, but tests only its side effects. Hence, a particular +type of feature service could be required to produce valid XML documents, but +the test of validity for the XML document is not directly testing the service, but only indirectly testing the validity of its output. -{{direct dependency (of a requirements class), Direct dependencies,options="noref"}} -test the same {{standardization target,options="noref"}}, but -{{indirect dependency (of a requirements class), indirect dependencies,options="noref"}} -test related but -different {{standardization target,standardization targets,options="noref"}}. - -The {{standardization target,options="noref"}} of the -{{indirect dependency (of a requirements class), indirect dependency,options="noref"}} -is different from the -target of "this requirements class" but it may be of the same or related -{{standardization target type,options="noref"}}. For example, if one service is -related to another second service, then a service {{requirement,options="noref"}} 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 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,options="noref"}} of a particular kind. +{{direct dependency (of a requirements class), Direct dependencies}} +test the same {{standardization target}}, but +{{indirect dependency (of a requirements class), indirect dependencies}} +test related but different {{standardization target,standardization targets}}. + +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 +to have an association to a licensing service, then the requirements of a +licensing service are indirect requirements for the DRM-enabled service. Such a +requirement may be stated as the associated licensing service has a +{{certificate of conformance}} of a particular kind. ==== === extension (of a requirements class) -{{requirements class,options="noref"}} which has a -{{direct dependency (of a requirements class), direct dependency,options="noref"}} on another -{{requirements class,options="noref"}} +{{requirements class}} which has a +{{direct dependency (of a requirements class), direct dependency}} on another +{{requirements class}} -NOTE: Here {{extension (of a requirements class),extension,options="noref"}} is -defined on {{requirements class,options="noref"}} so that their implementation may be +NOTE: Here {{extension (of a requirements class),extension}} is +defined on {{requirements class}} so that their implementation may be software extensions in a manner analogous to the extension relation between the -{{requirements class,requirements classes,options="noref"}}. +{{requirements class,requirements classes}}. === general recommendation @@ -214,26 +209,26 @@ recommendation applying to all entities in a specification model === home (of a requirement or recommendation) -official statement of a {{requirement,options="noref"}} or -{{recommendation,options="noref"}} that is the precedent for any other version -repeated or rephrased elsewhere +official statement of a {{requirement}} or {{recommendation}} that is the +precedent for any other version repeated or rephrased elsewhere [NOTE] ==== Explanatory text associated to 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. +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,options="noref"}} using the definitions of the ISO Directives +{{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 +UML model package that does not contain any subpackages, but contains +classifiers [.source] <> @@ -245,18 +240,18 @@ UML model package that does not contain any subpackages, but contains classifier alt:[abstract model] alt:[conceptual model] -theoretical construct that represents something, with a set of variables and a set of -logical and quantitative relationships between them. +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,options="noref"}}. The terms are almost interchangeable, with -{{model,options="noref"}} being preferred when the *source* is a constructed entity, -and *metaphor* being preferred when the *source* already exists, and the emphasis is +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 @@ -266,16 +261,17 @@ ____ *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,options="noref"}} are by their vary nature not the same as what -they are describing, and thus must contain a *conceptual metaphor* to describe their +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. ==== @@ -284,25 +280,26 @@ inherently makes them abstractions. 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 class,conformance test classes,options="noref"}}, +{{conformance test class,conformance test classes}}, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. [NOTE] ==== -This definition has been adopted from ISO 10000: Part 1. 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 or -conformance classes (either preexisting or locally defined) of the base standards. - -This means that a {{standardization target,options="noref"}} being conformant to a -profile implies that the same *target* is conformant to the standards referenced in -the {{profile,options="noref"}}. +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 +or conformance classes (either preexisting or locally defined) of the base +standards. + +This means that a {{standardization target}} being conformant to a profile +implies that the same *target* is conformant to the standards referenced in the +{{profile}}. ==== [.source] @@ -310,15 +307,15 @@ the {{profile,options="noref"}}. === recommendation -expression in the content of a document 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 +expression in the content of a document 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: Although using normative language, a {{recommendation,options="noref"}} is not -a {{requirement,options="noref"}}. The usual form replaces the "shall" (imperative or -command) of a {{requirement,options="noref"}} with a "should" (suggestive or +NOTE: Although using normative language, a {{recommendation}} is not +a {{requirement}}. The usual form replaces the "shall" (imperative or +command) of a {{requirement}} with a "should" (suggestive or conditional). [.source] @@ -331,28 +328,27 @@ compliance with the document is to be claimed and from which no deviation is per [NOTE] ==== -Each {{requirement,options="noref"}} is a normative criterion for a single *type of -standardization target*. In this standard, requirements will be associated to -{{conformance test, conformance tests,options="noref"}} that can be used to prove -compliance to the underlying criteria by the -{{standardization target,options="noref"}}. - -The implementation of a {{requirement,options="noref"}} is dependent on the type of -specification being written. A data specification requires data structures, but a -procedural specification requires software implementations. The view of a standard in -terms of a set of testable {{requirement,requirements,options="noref"}} allows us to +Each {{requirement}} is a normative criterion for a single +*type of standardization target*. In this standard, requirements will be +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 +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,options="noref"}} is usually expressed in terms -of a model of the {{standardization target,options="noref"}}, 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,options="noref"}}. +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,options="noref"}} use normative language and in particular -are commands and use the imperative "shall" or similar imperative constructs. -Statements in standards which are not requirements and need to be either conditional -or future tense normally use "will" and should not be confused with requirements that -use "shall" imperatively. +{{requirement,Requirements}} use normative language and in particular are +commands and use the imperative "shall" or similar imperative constructs. +Statements in standards which are not requirements and need to be either +conditional or future tense normally use "will" and should not be confused with +requirements that use "shall" imperatively. ==== [.source] @@ -360,91 +356,89 @@ use "shall" imperatively. === requirements class -aggregate of all {{requirements module,requirement modules,options="noref"}} that -must all be satisfied to satisfy a {{conformance test class,options="noref"}} +aggregate of all {{requirements module,requirement modules}} that +must all be satisfied to satisfy 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 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). +relationship from the original target to something that has a property +(satisfies a condition or requirement from another requirements class). === requirements module -aggregate of {{requirement,requirements,options="noref"}} and -{{recommendation,recommendations,options="noref"}} of a specification against a -single {{standardization target type,options="noref"}} +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. +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. === specification -document containing {{recommendation,recommendations,options="noref"}}, -{{requirement,requirements,options="noref"}} and -{{conformance test, conformance tests,options="noref"}} -for those {{requirement,requirements,options="noref"}} +document containing {{recommendation,recommendations}}, +{{requirement,requirements}} and {{conformance test, conformance tests}} for +those {{requirement,requirements}} [NOTE] ==== 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. +This does not restrict what else a standard may contain, as long as it does +contain the three types of element cited. ==== === standard -{{specification,options="noref"}} that has been approved by a legitimate Standards Body +{{specification}} that has been approved by a legitimate Standards Body [NOTE] ==== -This definition is included for completeness. {{standard,Standard,options="noref"}} -and {{specification,options="noref"}} can apply to the same document. While -{{specification,options="noref"}} is always valid, {{standard,options="noref"}} only -applies after the adoption of the document by a legitimate standards organization. +This definition is included for completeness. {{standard,Standard}} and +{{specification}} can apply to the same document. While {{specification}} is +always valid, {{standard}} only applies after the adoption of the document by a +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. +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 -entity to which some {{requirement,requirements,options="noref"}} of a -{{standard,options="noref"}} apply +entity to which some {{requirement,requirements}} of a {{standard}} apply -NOTE: The {{standardization target,options="noref"}} is the entity which may receive -a {{certificate of conformance,options="noref"}} for a -{{requirements class,options="noref"}}. +NOTE: The {{standardization target}} is the entity which may receive a +{{certificate of conformance}} for a {{requirements class}}. === standardization target type -type of entity or set of entities to which the -{{requirement,requirements,options="noref"}} of a {{standard,options="noref"}} apply +type of entity or set of entities to which the {{requirement,requirements}} of a +{{standard}} apply [NOTE] ==== -The {{standardization target type,standardization target types,options="noref"}} give -the {{standardization target,standardization targets,options="noref"}} 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. +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,options="noref"}}. This makes OWS Common a default +{{standardization target type}}. This makes OWS Common a default "global core" for all OGC Services. -In some cases, the {{standardization target type,options="noref"}} may be another +In some cases, the {{standardization target type}} may be another specification. A GML application schema is a -{{standardization target,options="noref"}} for the GML standard, but is in turn a +{{standardization target}} for the GML standard, but is in turn a specification of instances of that application schema. ==== @@ -453,9 +447,9 @@ specification of instances of that application schema. expression in a document conveying information NOTE: Includes all statements in a document not part of the normative -{{requirement,requirements,options="noref"}}, -{{recommendation,recommendations,options="noref"}} or -{{conformance test, conformance tests,options="noref"}}. Included for completeness. +{{requirement,requirements}}, +{{recommendation,recommendations}} or +{{conformance test, conformance tests}}. Included for completeness. [.source] <> diff --git a/sources/sections/ac-definitions.adoc b/sources/sections/ac-definitions.adoc index 160ae7e..b3a63a9 100644 --- a/sources/sections/ac-definitions.adoc +++ b/sources/sections/ac-definitions.adoc @@ -8,52 +8,55 @@ 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 type,options="noref"}} is a type of entity about which -a standard is written. An instance of a {{standardization target type,options="noref"}} -is a {{standardization target,options="noref"}}. A standard -may address multiple targets in separate <>. -. a {{requirement,options="noref"}} is a statement of a condition to be satisfied by -a single {{standardization target type,options="noref"}}, and it must be stated in -"normative" language. -. a {{conformance test,options="noref"}} checks if a set of -{{requirement,requirements,options="noref"}} are met (*pass*) or not met (*fail*) by -a {{standardization target,options="noref"}}. The relationship between -{{conformance test, conformance tests,options="noref"}} and -{{requirement,requirements,options="noref"}} is many-to-many. -. all {{conformance test, conformance tests,options="noref"}} are graded as *pass* -or *fail* against each instance of the {{standardization target,options="noref"}}. -. a {{requirement,options="noref"}} is associated to at least one -{{conformance test,options="noref"}}. -. a {{recommendation,options="noref"}} is a suggestion and is not associated to any -{{conformance test,options="noref"}}. -. a {{requirements class,options="noref"}} is a set of one or more -{{requirement,requirements,options="noref"}} all on the same -{{standardization target type,options="noref"}}. -. a {{conformance test class,conformance (test) class,options="noref"}} is a -collection of {{conformance test,conformance tests,options="noref"}} that are -associated to and only to the requirements in a corresponding -{{requirements class,options="noref"}}. -. a {{conformance test class,conformance (test) class,options="noref"}} is also -collection of {{conformance test module,conformance test modules,options="noref"}} -that group {{conformance test, conformance tests,options="noref"}} on a single -{{standardization target type,options="noref"}}. -. a *conformant implementation* is a {{standardization target type,options="noref"}} -that has successfully passed all tests in a specified -{{conformance test class,conformance (test) class,options="noref"}} -and received a {{certificate of conformance,options="noref"}} -. the {{core requirements class,options="noref"}} of a standard is the minimal set -of {{requirement,requirements,options="noref"}} which must be supported by all -*conformant implementations*. If a specification addresses multiple -{{standardization target type,standardization target types,options="noref"}}, it may -have a *core* for each *target type*. -. an *extension* of a {{requirements class,options="noref"}} is a second -{{requirements class,options="noref"}} (the extension) that adds additional -{{requirement,requirements,options="noref"}} to the first -{{requirements class,options="noref"}} (the *base requirements class* being -extended). The extension is said to be dependent on the *base*. Any -{{conformance test class,options="noref"}} must identify all of its dependencies -during the execution of conformance tests against a candidate -{{standardization target,options="noref"}}. +. a {{standardization target type}} is a type of entity about which a standard +is written. An instance of a {{standardization target type}} is a +{{standardization target}}. A standard may address multiple targets in separate +<>. + +. a {{requirement}} is a statement of a condition to be satisfied by a single +{{standardization target type}}, and it must be stated in "normative" language. + +. a {{conformance test}} checks if a set of +{{requirement,requirements}} are met (*pass*) or not met (*fail*) by a +{{standardization target}}. The relationship between {{conformance test, +conformance tests}} and {{requirement,requirements}} is many-to-many. + +. all {{conformance test, conformance tests}} are graded as *pass* or *fail* +against each instance of the {{standardization target}}. + +. a {{requirement}} is associated to at least one {{conformance test}}. + +. a {{recommendation}} is a suggestion and is not associated to any +{{conformance test}}. + +. a {{requirements class}} is a set of one or more {{requirement,requirements}} +all on the same {{standardization target type}}. + +. a {{conformance test class,conformance (test) class}} is a collection of +{{conformance test,conformance tests}} that are associated to and only to the +requirements in a corresponding {{requirements class}}. + +. a {{conformance test class,conformance (test) class}} is also collection of +{{conformance test module,conformance test modules}} that group +{{conformance test, conformance tests}} on a single +{{standardization target type}}. + +. a *conformant implementation* is a {{standardization target type}} that has +successfully passed all tests in a specified {{conformance test +class,conformance (test) class}} and received a {{certificate of conformance}} + +. the {{core requirements class}} of a standard is the minimal set of +{{requirement,requirements}} which must be supported by all *conformant +implementations*. If a specification addresses multiple {{standardization target +type,standardization target types}}, it may have a *core* for each *target +type*. + +. an *extension* of a {{requirements class}} is a second {{requirements class}} +(the extension) that adds additional {{requirement,requirements}} to the first +{{requirements class}} (the *base requirements class* being extended). The +extension is said to be dependent on the *base*. Any {{conformance test class}} +must identify all of its dependencies during the execution of conformance tests +against a candidate {{standardization target}}. [[annex-C-2]] === UML Model