Inconsistency in typing between EDR Parameter Object and CovJSON Parameter Object

[rosina-derks]

The Parameter object defined by the OGC EDR standard (C.1.11) differs from the Parameter object defined by the OGC CoverageJSON standard (9.3) regarding the i18n Object type. Is the difference between these objects intended?

The EDR standard prescribes type string for the several field names for the Parameter object, Unit object, Symbol object and observedProperty object. Although it states that these fields must be an i18n object in Requirement A.58 (/req/edr/rc-parameters), the spec does not define the i18n object.

The CoverageJSON standard prescribes type i18n for the same values which the EDR defines a string type. The CoverageJSON standard does define an i18n object (9.2) as a dict with a language tag as key and a string as value.

[chris-little]

@rosina-derks The simple answer to your question was that they were meant to be the same, but the I18N structure in EDR was removed as part of the simplification before release ("Perfection is not when you cannot add more, but when you cannot take anything else away", Antoine St Exupery).

This causes a problem because reverting to include I18N in API-EDR wuld be a breaking change, so forcing a Version 2.0. Perhaps this could be done when all of the OGC APIs are moved to V2 to increase consistency.

We are reluctant to add to EDR the option of both approaches to strings, as this adds complexity to the schemas and parsing.

Can you live with the situation at present?

And thank you for the detailed informed reading of the specs!

@ghobona @dblodgett-usgs @ShaneMill1 @iandruska-ibl FYI.

[rosina-derks]

@chris-little Thank you for your reply and explanation! I understand why the difference arose and breaking changes are unwanted at this point. We choose to implement an EDR Parameter Object and a separate CovJSON Parameter object for now.

Hopefully it can be incorporated when the OGC APIs are moved to V2!

[chris-little]

@rosina-derks A fix has been slated for V1.2.