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
One way that we may already be doing that in some cases is by using conditional language directly within specific requirements parts (If [condition] the implementation SHALL [obligations depending on an optional dependency]).
In the example I provided about variable width tile matrix sets and tile matrix set limits, the context when the dependency is optional can be implied from the conformance section of the 2DTMS, which for VariableMatrix says:
The target is a service or an encoding needing to define a TileMatrixSet with variable width.
and for TileMatrixSetLimits says:
The target is a service, a client, or an encoding needing to define TileMatrixSetLimits
However, a an additional field to explain when the dependency is optional would certainly make a lot of sense.
...I think often when we have used conditions inside a requirement, they were on a specific part of the requirement.
... the requirements (or requirements parts) conditions allow to express an obligation that would otherwise always require the optional conformance class dependency.
Here I would like to express that the functionality of this conformance class leverages the capabilties defined in other conformance classes (what they define is also applicable to the current conformance class), without a hard dependency on them.
The text was updated successfully, but these errors were encountered:
These conditional statements will require an update to ModSpec. We could potentially use this document as a pilot to drive modeling of the proposed updates.
From:
From @jerstlouis (in a discussion with @ghobona @joanma747 @opoudjis ):
One way that we may already be doing that in some cases is by using conditional language directly within specific requirements parts (If [condition] the implementation SHALL [obligations depending on an optional dependency]).
In the example I provided about variable width tile matrix sets and tile matrix set limits, the context when the dependency is optional can be implied from the conformance section of the 2DTMS, which for VariableMatrix says:
and for TileMatrixSetLimits says:
However, a an additional field to explain when the dependency is optional would certainly make a lot of sense.
...I think often when we have used conditions inside a requirement, they were on a specific part of the requirement.
... the requirements (or requirements parts) conditions allow to express an obligation that would otherwise always require the optional conformance class dependency.
Other examples from Processes - Part 3:
https://github.com/jerstlouis/ogcapi-processes/blob/part3-update/extensions/workflows/requirements/requirements_class_collection-output.adoc
Here I would like to express that Collection Output depends on OGC API data access specifications, but any one or more of them will do.
https://github.com/jerstlouis/ogcapi-processes/blob/part3-update/extensions/workflows/requirements/requirements_class_nested-processes.adoc
Here I would like to express that the functionality of this conformance class leverages the capabilties defined in other conformance classes (what they define is also applicable to the current conformance class), without a hard dependency on them.
The text was updated successfully, but these errors were encountered: