Defining and Implementing Service Metadata Independent of OWS Configuration

[aaime]

From @jodygarnett email:

However each OGCAPI service has its own ServiceInfo with title/description - even if it does not provide any additional configuration over and above the open web service base (OGCAPI-Featuers uses WFSInfo for example). This was not what I expected so I am not sure I have a good idea how to proceed yet. David added some more "hints" to slot things under the correct heading; and there is not any way to configure the title / heading for OGCAPI-Features separately yet...

However, there is a catch: the implementation of WFS internal feature engine reaches out to WFSInfo specifically, and directly, to control its own behavior. E.g., GetFeature autonomously reaches to maxFeatures from WFSInfo.

[jodygarnett]

I am happy with the approach being taken with WFSInfo hosting FeatureService configuration beans in the metadata map.

I would like to see this topic pull the other direction. Make everything more dependent.

• Leave WFSInfo as it is
• Introduce WFS 1.0, WFS1.1 and WFS 2.0 conformances
• Then each protocol can be turned on and off: WFS 1.0, WFS 1.1, WFS 2.0, FeatureService v1
• Refactor the user interface as needed