How to deal with inherited dependencies

[heidivanparys]

Currently, the spec says:

Requirements class	http://inspire.ec.europa.eu/id/spec/oapif-download/1.0/req/pre-defined
Target type	Web API
Dependency	OAPIF Requirements class "Core"
Dependency	OAPIF Requirements class "Open API 3.0"

INSPIRE-pre-defined-data-set-download-OAPIF is dependent on OpenAPI 3.0, which in turn is dependent on Core.

That means, that the dependency from INSPIRE-pre-defined-data-set-download-OAPIF to Core actually is redundant, as it has Core as a dependency already through OpenAPI 3.0, as also illustrated in the figure below (the redundant dependency in red).

So how should we deal with this inherited dependency?

1. Remove the inherited dependency from the table.
2. Leave the dependency in the table, but use "Inherited dependency" in the left column. Note that in order to be consistent, the tables for requirements classes “INSPIRE-multilinguality” and “INSPIRE-OAPIF-GeoJSON” would have to be updated too, and their inherited dependencies added.
3. Leave the table as it, and update the tables for requirements classes “INSPIRE-multilinguality” and “INSPIRE-OAPIF-GeoJSON” so they include all inherited dependencies too.
4. ?

Additional question: would illustrating the dependencies by means of a diagram as the one above be useful?

[heidivanparys]

@cportele What would OGC recommend here? In the pull request I chose option 1.

[cportele]

@heidivanparys - Yes, this is the typical approach. Everything else leads to redundancies - and, as a result, potential inconsistencies.

[heidivanparys]

Ok, thanks.

@alexanderkotsev Could you merge the pull request?