Modular standard
A standard’s usefulness and hence worth can be measured by:
- The ease with which it can be implemented.
- The number of times it has been implemented, and by whom.
- The number of times those implementations are used.
- The ease with which those implementations interact.
- The number of times it has been extended through inclusion in other useful standards.
Some of these are affected by the choice of topic, but all are affected by the internal logical structure of the standard. A standard is a partial solution to a design problem which limits “conformant” solutions to enhance interoperability and harmony between disparate implementations.
These “limitations” are expressed as requirements and recommendations in the standard. Often it is sensible for a standard to recognize groups of requirements that should be implemented together and allow for implementations to only conform to some of these groups1. For example, in a data specification standard, some requirements may be independent of the data encoding, with other requirements being specific to XML or JSON encodings. Or some requirements may be independent of whether the data is object based or gridded, with other requirements being specific to one of those types. The distinguishing factor is known as the specification target of the requirement class.
By organizing the requirements into requirements classes, implementations of the standard can specify which group(s) of requirements they conform to. To support this, each class is identified in a similar way to the identification of the individual requirements; see - Structure of URIs in ISO/TC 211 resources for implementation Clause 3. In order to support conformance testing, each requirements class has an equivalent conformance class, with abstract and executable2 test classes. For further details, see ISO 19105:2022.
When considering the organization of requirements into requirements classes, one of the important factors is dependency – where implementing some requirements necessarily depends on other requirements being implemented. It is very common for a standard to have one requirements class on which the others depend – often called something like the core requirements class.
Many standards wisely build on other standards, from TC 211 and other sources, which introduces dependencies between the documents. By making standards modular, it is easier to state specifically what it is that the standard depends on.
Both internal and (where possible) external dependencies should be on a requirements class, and not (generally) on an entire standard or an individual requirement.
1) The ISO Directives Part 2, Clause 6.6 refers to these subsets as profiles, but that term has a different meaning in our community.
2) The executable test suite(s) may not be part of the standard; they are implementations of the abstract test suite(s), which are specified in the standard.
| Contributors |
PMG Convenor |
| 2022-07-28 | Updated reference to ISO 19105 |
| 2021-12-01 | New page |