minor version resolution on definition server

[pzaborowski]

Hi, according to the opengeospatial/ogcapi-features#739 definition server shall resolve links to
1.0 definitions to the highest minor version 1.0.x (and all x.y to highest of x.y and x.y.z I guess).
Test case (links from 18-058r1):

1. http://www.opengis.net/spec/ogcapi-features-2/1.0/req/crs -> redirect? -> http://www.opengis.net/spec/ogcapi-features-2/1.0.1/req/crs
2. then in the browser http://www.opengis.net/spec/ogcapi-features-2/1.0.1/req/crs -> http://docs.ogc.org/is/18-058r1/18-058r1.html#_requirements_class_coordinate_reference_systems_by_reference

Current result in the browser:
http://www.opengis.net/spec/ogcapi-features-2/1.0/req/crs -> http://docs.ogc.org/is/18-058/18-058.html#rc_crs
and
http://www.opengis.net/spec/ogcapi-features-2/1.0.1/req/crs -> http://docs.ogc.org/is/18-058r1/18-058r1.html#_requirements_class_coordinate_reference_systems_by_reference

Is the requested behaviour already documented?
Are we ok that there is no option to distinguish references to the replaced URI for externals like the software?

[pzaborowski]

2. formally, on the definition server, shall Part 2 v.1.0.1 modules (e.g. conformance class) refer to Part v1.0.1 or v1.0 ?
   in other words:
   http://www.opengis.net/doc/IS/ogcapi-features-2/1.0.1/conf/crs http://www.opengis.net/def/ont/specrel/dependency http://www.opengis.net/spec/ogcapi-features-1/1.0.1/conf/core
   OR
   http://www.opengis.net/doc/IS/ogcapi-features-2/1.0.1/conf/crs http://www.opengis.net/def/ont/specrel/dependency http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core

[ghobona]

A draft of the updated mappings is at https://github.com/opengeospatial/ogcapi-features/blob/master/specification-elements/18-058r1.csv

[pzaborowski]

Thanks @ghobona.
@rob-metalinkage was/is the idea to update the mapping ad-hoc per request?

Took the other spec like Features Core corrigendum:
https://docs.opengeospatial.org/is/17-069r4/17-069r4.html#_requirements_class_openapi_3_0
links to:
http://www.opengis.net/spec/ogcapi-features-1/1.0/req/oas30
but the link resolves to the previous version.
There is no specific mapping file for 17-069r4 in the pointed directory.

@ghobona @rob-metalinkage let's rephrase the question - shall be the mapping to the newest minor version automatic so we can be always up to date? or maybe there is a process already in place that shall populate it to operations and it may be leaky?

[ghobona]

@pzaborowski It's not currently automatic. I extract the URIs using a python script, create a CSV file, and send the CSV file to @kstegemoller for configuration of the server.

In some cases, the Editors of the standards help review the CSV files.

[jerstlouis]

Currently, the definition server makes a distinction between {major}.{minor}.{patch} and {major}.{minor} when resolving URI.

e.g.,
http://www.opengis.net/doc/IS/cis/1.1

returns CIS document version r6

vs.
http://www.opengis.net/doc/IS/cis/1.1.1
returns CIS version r8.

To follow the policy, the 1.1.1 URI should not exist and the 1.1 URI should always resolve to the latest corrigendum version.

This would also help search engine return proper results. e.g., a Google search for "OGC CIS" finds the deprecated version 1.1 (r6) rather than the proper 1.1.1 (r8).