Conformance enums difficulties

[jerstlouis]

@cportele We are finding it very difficult to handle the mapping of URI conformance classes to values at the top-level of the conformance object.

Could that perhaps be nested within a separate property, e.g. classProperties or something similar?

The difficulty is that while conformsTo is a fixed property, those URIs are arbitrary. This forces treating the whole thing as a dictionary / map / associative array. It would be much easier if those URIs were within a dedicated property which could be a dictionary, while the top-level object could be a class with properties.

The current setup does not support well a declarative approach (defining classes) to parsing and writing the conformance JSON.

Suggesting something like:

{
  "conformsTo": [
    "http://www.opengis.net/spec/ogcapi-routes-1/1.0/conf/core",
    "http://www.opengis.net/spec/ogcapi-routes-1/1.0/conf/mode"
  ],
  "classProperties": {
     "http://www.opengis.net/spec/ogcapi-routes-1/1.0/conf/core": {
       "preferences": [ "fastest", "shortest" ]
     },
     "http://www.opengis.net/spec/ogcapi-routes-1/1.0/conf/mode": {
       "modes": [ "on-road", "off-road" ]
     }
  }
}

[cportele]

@jerstlouis - that makes sense to me

[jerstlouis]

@cportele Thanks. Do you recall if this approach to mapping conformance classes to enumeration values was used in another OGC API or discussed in Common? I seem to recall another discussion about this. Styles, perhaps?

[cportele]

As far as I remember, this is the first and only case that has used the approach so far in the OGC API family, so this is a good time to test and make improvements so that we have a solid approach!

[cportele]

We should use properties for the key. Since the resource is about conformance classes, the context is clear and "properties" is more concise.

[cportele]

Meeting 2021-12-09: Agreement to make the change.

Also open an issue in Common to propose this as a general pattern that other standards could also use.