You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
- API modules are now directly embedded/adapted to the description/requirements where they are used
- Moved "building blocks" such as the subset requirement module and what seems like a copy of Features - Part 2: CRS to bblocks/ directory
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).
The text was updated successfully, but these errors were encountered: