Potentially revert and simplify some generic language and requirements which was an attempt at making re-usable requirement modules (e.g., #270) that can be directly and literally included (as in ASCIIDoc include) in different standards, for different resource types.
This is confusing for implementers, as it tends to mkake the text longer than necessary and less clear / straightforward, and in common cases where the same parameters (for example) are used in different resource contexts, it results in conflicts caused by the same ASCIIDoc content being included multiple times.
Instead, the language describing the re-usable building blocks should be adapted to the resource context where they are used.
We already made similar reverts in Maps and Coverages, opting to directly adapt the requirements to the resources they apply to (even though we maintain the concept of building blocks / requirement module).
An example of this the split of 9.1 Parameter Requirements vs. 9.2 Target Resource Requirements, instead of organizing together the parameter requirement with what it does to the resource (in this case, we're always just talking about /collections).
Potentially revert and simplify some generic language and requirements which was an attempt at making re-usable requirement modules (e.g., #270) that can be directly and literally included (as in ASCIIDoc include) in different standards, for different resource types. This is confusing for implementers, as it tends to mkake the text longer than necessary and less clear / straightforward, and in common cases where the same parameters (for example) are used in different resource contexts, it results in conflicts caused by the same ASCIIDoc content being included multiple times. Instead, the language describing the re-usable building blocks should be adapted to the resource context where they are used. We already made similar reverts in Maps and Coverages, opting to directly adapt the requirements to the resources they apply to (even though we maintain the concept of building blocks / requirement module). An example of this the split of 9.1 Parameter Requirements vs. 9.2 Target Resource Requirements, instead of organizing together the parameter requirement with what it does to the resource (in this case, we're always just talking about /collections).