Skip to content
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

Open
ronaldtse opened this issue Oct 18, 2022 · 13 comments
Assignees
Labels
enhancement New feature or request

Comments

@ronaldtse
Copy link
Contributor

ronaldtse commented Oct 18, 2022

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:

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.

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.

@ronaldtse ronaldtse added the enhancement New feature or request label Oct 18, 2022
@ronaldtse
Copy link
Contributor Author

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.

@opoudjis
Copy link
Contributor

opoudjis commented Dec 4, 2023

Needs to be discussed within OGC.

@ghobona
Copy link

ghobona commented Dec 4, 2023

This issue will be discussed in the DocTeam and OAB first.

@ogcscotts
Copy link

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.

@jerstlouis
Copy link

jerstlouis commented Dec 5, 2023

@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:

  1. The ability to express at the requirement class level the conditions when a dependency applies
    e.g., OGC API - Tiles Tileset req class does not express dependency on http://www.opengis.net/spec/tms/2.0/conf/json-variablematrixwidth, or on the XML requirement classes, since it is optional for the implementation to support XML or variable width tile matrix sets, but if implementations do support these, then the dependency on those req classes does apply.
    (defining separate Tileset requirement classes to depend on these, as is actually already done in 2DTMS for JSON, XML encoding of VariableWidth, would results in unwanted duplication/proliferation of classes for each feature that is being encoded, when the granularity is already handled by those dependencies)

  2. The ability to specify at the requirement part level a condition when that part of the requirement applies
    For example Requirement 8 of OGC API - Tiles has several requirement parts beginning with an If... sentence. Though these could potentially be separate requirements, often they are closely related statements that we would like to keep together as a single requirement.

( Currently, the metanorma conditions:: keyword can only be used at the requirement level. )

  1. The ability to specify alternatives that can satisfy a dependency (e.g., Tiles Collection Tilesets depending on Common - Part 2 or Features - Part 1; or Processes-3 Collection Output dependency on any data access OGC API e.g., Tiles, Coverages, Features, Maps, DGGS, EDR...)

  2. The ability to express that if this other requirement class is also implemented, these requirement parts apply (somewhat of a reverse dependency). We have a new example of this in OGC API - Maps where Scaling and Subsetting can be supported independently, but are heavily intertwined if both are implemented (table 7, 8 and 9; see also Requirement 23 A spatial-subsetting/width-height).

@ogcscotts
Copy link

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:
(1) the mod spec is updated to better support dependencies as requirements stated with dependencies look more "natural" to a developer; OR
(2) requirements with dependencies get broken into multiple requirements organized by preconditions (the "if" statements), which is very precise, but perhaps needlessly complex.
I could be wrong in my assessment, so let's have the OAB consider since that group owns the Mod Spec.

@github-project-automation github-project-automation bot moved this to 🆕 New in Metanorma Feb 15, 2024
@opoudjis opoudjis moved this from 🆕 New to On hold in Metanorma Feb 15, 2024
@opoudjis opoudjis assigned opoudjis and unassigned ronaldtse Feb 15, 2024
@ghobona
Copy link

ghobona commented Feb 15, 2024

Discussed 2024-02-15.

Waiting for DocTeam and OAB

@ogcscotts
Copy link

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.

@ronaldtse
Copy link
Contributor Author

@ogcscotts how do we get involved in the ModSpec revision? Thanks!

@ogcscotts
Copy link

@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.

@ronaldtse
Copy link
Contributor Author

Linking back to the official ModSpec repository:

@ghobona
Copy link

ghobona commented Jul 8, 2024

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.

@ghobona
Copy link

ghobona commented Nov 12, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: On hold
Development

No branches or pull requests

5 participants