From eb8ede111a6167ff9ed27fc9d76e622f52aa7b5f Mon Sep 17 00:00:00 2001 From: Peter Parslow Date: Mon, 22 Jul 2024 16:29:48 +0100 Subject: [PATCH 1/2] Update 06-req-class.adoc - typo/wrong word in (old) 6.1 Typo / spelling - "equivalence" should be "equivalents" (or "equivalent" --- sources/sections/06-req-class.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sources/sections/06-req-class.adoc b/sources/sections/06-req-class.adoc index 9abd6b8..c130b0d 100644 --- a/sources/sections/06-req-class.adoc +++ b/sources/sections/06-req-class.adoc @@ -70,7 +70,7 @@ these component elements in a normative manner, including but not limited to oth standards, implementations of the conformance test suite, or certificates of conformance for implementations conformant to the standard in question.#* The precise enforcement of this requirement and its associated recommendation is the purview of -the OGC Naming Authority or its equivalence. +the OGC Naming Authority or its equivalents. 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. From ab8d678099e60a8ca29871ca5ffab50700baf5ae Mon Sep 17 00:00:00 2001 From: Peter Parslow Date: Mon, 22 Jul 2024 17:12:29 +0100 Subject: [PATCH 2/2] Update 06-req-class.adoc A number of other typos --- sources/sections/06-req-class.adoc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/sources/sections/06-req-class.adoc b/sources/sections/06-req-class.adoc index c130b0d..58243b3 100644 --- a/sources/sections/06-req-class.adoc +++ b/sources/sections/06-req-class.adoc @@ -88,7 +88,7 @@ Conformance tests are aggregated into conformance classes that specify how certa 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, this Policy 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. +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, this Policy defines a "requirements class" as a set of requirements that must all be passed to achieve a particular conformance class (see @@ -98,14 +98,14 @@ parallel the conformance test modules. A standard written to this Policy may use this "module" structure in any manner consistent with the rest of this Policy. An OGC Standard or Abstract Specification 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 +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 Policyd. If other standards are +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 <>. @@ -115,7 +115,7 @@ passed to qualify to pass this conformance class. In terms of requirements, that that the dependent conformance class contains tests (by reference) for all requirements of the "included" conformance class. -From this POlicy's view of requirements classes, one requirements +From this Policy's view of requirements classes, 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" @@ -168,9 +168,9 @@ class in which the request-response pair is defined and set against requirements === Using the model The primary difficulty in speaking of standards (or candidate -standards){blank}footnote:[This is purposely written as "as yet not adopted" +standards){blank}footnote:[This is purposely written as "as not yet adopted" standards, since it is during the authoring process that this Policy must be -considered, not _ex post facto_.] as a group is their diverse +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 @@ -683,7 +683,7 @@ 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 specification to enforce a level of quality on its -standardization targets, when well and properly formed; do not interfere with the +standardization targets, when well and properly formed, do not interfere with the proper extension of those targets. So, the specification 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 @@ -705,7 +705,7 @@ standard 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 +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.