Re: [dxwg] Complete related defns

As previously noted, the [OGC's Modular Specification](https://portal.opengeospatial.org/files/?artifact_id=34762) model is relevant here. 
Clause 4 gives the terms and definitions, within which the following are immediately relevant: 

# 4.9 direct dependency (of a requirements class)
another requirements class (the dependency) whose requirements are defined to also be requirements of this requirements class
NOTE A 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. Any tests associated to this dependency can be applied to this requirements class.
When testing a direct dependency, the standardization target is directly subject to the test in the specified conformance test class of the direct dependency.

# 4.10 indirect dependency (of a requirements class)
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, the test against the consumable or product used 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 dependencies test the same standardization target, but indirect dependencies test related but different standardization targets.
The standardization target of the 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.

# 4.11 extension (of a requirements class)
requirements class which has a direct dependency on another requirements class
NOTE Here 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 classes.

# 4.13 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
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.
These alternative statements use non-normative language and are statements using the definitions of the ISO Directives Part 2.

# 4.16 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, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function.
[ISO/IEC TR 10000-1]
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 being conformant to a profile implies that the same target is conformant to the standards referenced in the profile.

# 4.19 requirements class
aggregate of all 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).

# 4.20 requirements module
aggregate of requirements and 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.

# 4.21 specification
document containing recommendations, requirements and conformance tests for those requirements
NOTE This definition is included for completeness. See Clause 5.3.
This does not restrict what else a standard may contain, as long as it does contain the three types of element cited.

# 4.22 standard
specification that has been approved by a legitimate Standards Body
NOTE This definition is included for completeness. 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.

# 4.23 standardization target
entity to which some requirements of a standard apply
NOTE The standardization target is the entity which may receive a certificate of conformance for a requirements class.

# 4.24 standardization target type
type of entity or set of entities to which the requirements of a standard apply
NOTE The standardization target types give the 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.

-- 
GitHub Notification of comment by dr-shorthair
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/374#issuecomment-432017190 using your GitHub account

Received on Monday, 22 October 2018 22:44:17 UTC