-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ModSpec conditions: requirements class condition, inheritance condition, requirement part condition #439
Comments
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. |
Needs to be discussed within OGC. |
This issue will be discussed in the DocTeam and OAB first. |
OAB first if there should be a change to the Mod Spec. Could someone please describe what kind of change is actually needed? It seems to me that a condition can live entirely within a requirement and perhaps the issue is better addressed by structuring requirements accordingly. |
@ogcscotts summarizing the e-mail discussion from October 17-18, 2022 (see thread copied in email), I think there are a number of capabilities being discussed:
( Currently, the metanorma conditions:: keyword can only be used at the requirement level. )
|
thanks, @jerstlouis - the examples help greatly. I do think that this topic needs to go to the OAB. I could see two end states of discussion: |
Discussed 2024-02-15. Waiting for DocTeam and OAB |
A draft update of the Mod Spec is now in work. This topic will be considered in the OAB as part of the review of the update. |
@ogcscotts how do we get involved in the ModSpec revision? Thanks! |
@ronaldtse we can share an early draft with you for feedback. The OGC Architecture Board (OAB) will run the process, but happy to include you as a contributor. |
Linking back to the official ModSpec repository: |
2024-07-08 Discussed with OGC Staff and agreed to keep this ticket on hold until the new version of the ModSpec is approved by the OGC Membership. |
On 7 November 2024, there was an update from the ModSpec development team. The presentation is at https://portal.ogc.org/files/?artifact_id=109496 (portal access required) |
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: