geopython
OWS Capabilities Probe: Check for Title element may raise false negative
Describe the bug
All OWS Capabilities Probes share a Check for Title> string. See here. As Title may even be left out since minOccurs=0 as per OGC OWS schema, this may lead to Check failure (false negative).
To Reproduce Steps to reproduce the behavior, e.g.:
- add CSW Resource with URL: https://sextant.ifremer.fr/geonetwork/srv/eng/csw-EMODNET_Chemistry?
- run Test
- See test fails but https://sextant.ifremer.fr/geonetwork/srv/eng/csw-EMODNET_Chemistry?service=CSW&version=2.0.2&request=GetCapabilities is valid
Expected Behavior Expected test to succeed.
Screenshots or Logfiles Not required.
Context (please complete the following information):
- OS: any
- Browser N.A.
- Browser Version N.A.
- Python Version N.A.
- GeoHealthCheck Version 0.8.0
Additional context The Check is basically a "Contains String", so need to find a String that is always present in capabilities response for all OWSes
Might need to check other OWS schema, as not all OWS standards inherit from OWS 2, WFS 2.0 doesn't for example, it uses version 1.1.0, not sure about earlier WFS versions. WCS 2.0 does use OWS 2 though.
Don't think WMS uses any OWS common schema for WMS 1.3.0 we have: http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd that tells us that title is very much required.
Incidentally, https://sextant.ifremer.fr/geonetwork/srv/eng/csw-EMODNET_Chemistry?service=CSW&version=2.0.2&request=GetCapabilities is invalid (if we mean schema checking) it fails on:
Value 'LessThanOrEqualTo' is not facet-valid with respect to enumeration '[LessThan, GreaterThan, LessThanEqualTo, GreaterThanEqualTo, EqualTo, NotEqualTo, Like, Between, NullCheck]'. It must be a value from the enumeration.
and
The value 'GreaterThanOrEqualTo' of element 'ogc:ComparisonOperator' is not valid.
CSW 2.0.2 uses OWS 1.0.0
@nmtoken good point! When we first developed the generic GetCapabilities Probe, we (I) naively thought that the Title element was mandatory for any OWS. Had to scan through OGC OWS standards to see that this is not (always) the case! In reality this Check is currently a "Caps doc contains <Title String" check. It could have been any other string that is mandatory in any OWS Caps doc.. Formally we should check against the XSD but OGC-conformance testing is not the purpose of GHC. Each implementation (GeoServer, MapServer, GeoNetwork etc) should have been conformance-checked.
For this issue: we should solve this by checking the occurrence of a string common to any OWS Capabilities, that is at the samen time not in an Caps Exception response. An XSD conformance Check per OWS-(type,version) could be developed as Plugin.
@justb4 The reason I found this issue, was because it was suggested to us that GHC might be used to do standards conformance testing (our use case is at the moment WMS/WFS/WCS) conformance plus specific content in the capabilities response, at the moment we do this checking manually. We have found that capabilities responses are often invalid, but not sure if that is only when services supply edited or static files, over faulty implementations.
Thank you for confirming what I suspected that OGC-conformance testing is not the purpose of GHC, but it's good to know that a plugin could be developed to do it.
Conformance testing can be provided via OGC, so called CITE Tests [1] and the related software Team Engine [2]. Would be nice if that could somehow be coupled to a GHC Plugin.
And yes many deployment have an invalid Capabilities file. Often indeed as the file may be static (usually for performance reasons) or locally generated. So the implementation, e.g. GeoServer, is OGC-compliant, but local changes may render invalid Caps files.
Other problem is often that the Capabilities file advertises "capabilities" that it does not support. Think e.g. of content/image types or projections. [1] https://www.ogc.org/projects/groups/citesc [2] https://cite.opengeospatial.org/teamengine/