Extended Capabilities in GeoServer 2.20.0 include an extra SupportedLanguade tag

[kalxas]

[kalxas]

Fixed by adding eng as supported language in the inspire configuration:

[kalxas]

Linked to #7

[kalxas]

Virtual WMS still affected:

http://beta.geoportal.ypen.gr/geoserver/amaqd-wms/ows?service=wms&version=1.3.0&request=GetCapabilities

[kalxas]

Also fixed for virtual WMS, same configuration on the amaqd-wms workspace

[grigoriouelena]

What happens when the default language is not english?

[grigoriouelena]

What happens when the default language is not english?

The problem is solved when the i18n configuration is used to provide capabilities information in some default and some other supported language. In our case the default language is greek and the supported language is english.

[grigoriouelena]

Correct INSPIRE extended caps schema (TechnicalGuidance_ViewServices_v3.0)

<inspire_vs:ExtendedCapabilities>
<inspire_common:MetadataUrl xsi:type="inspire_common:resourceLocatorType"> <inspire_common:URL>http://discoveryService....</inspire_common:URL>
< inspire_common:MediaType>application/vnd.ogc.csw….</inspire_common:MediaType>
</inspire_common:MetadataUrl>
<inspire_common:SupportedLanguages xsi:type="inspire_common:supportedLanguagesType">
<inspire_common:DefaultLanguage>
<inspire_common:Language>dut</inspire_common:Language>
</inspire_common:DefaultLanguage>
<inspire_common:SupportedLanguage>
<inspire_common:Language>eng</inspire_common:Language>
</inspire_common:SupportedLanguage>
</inspire_common:SupportedLanguages>
<inspire_common:ResponseLanguage>
<inspire_common:Language>dut</inspire_common:Language>
</inspire_common:ResponseLanguage>
</inspire_vs:ExtendedCapabilities>

1. same default and supported language

When the default and other supported language is the same, the capabilities document omits the element /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage.
Since the element is not mandatory, the validation is successful (at least as regards the schema validation).

Relevant validation report: 1. wmsCaps_SameDefaultSupportedLang.html.zip

2. no other supported language
   When no other supported language is selected, the element
   /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage is present in the capabilities document but it is not correctly encoded.

The child element /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage/inspire_common:Language is missing so the schema validation fails.

The validator returns the following message:

Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 110; columnNumber: 48; cvc-complex-type.2.4.b: The content of element 'inspire_common:SupportedLanguage' is not complete. One of '{"http://inspire.ec.europa.eu/schemas/common/1.0":Language}' is expected. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]

Relevant validation report: 2. wmsCaps_noOtherSupportedLang.html.zip

3. different default and other supported language
   The desired configuration in our case is to provide different default and supported languages, using the i18n configuration for the internationalization of the capabilities response.

When this configuration is present, the capabilities response is again not correctly encoded.

The relevant test fails for the schema validation. The error is
Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 110; columnNumber: 85; cvc-complex-type.2.3: Element 'inspire_common:SupportedLanguage' cannot have character [children], because the type's content type is element-only. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]

Relevant validation report: 3. wmsCaps_difDefaultSupportedLang.html.zip

Note #1: The i18n configuration does not affect geoserver’s behavior regarding the inspire extended caps.
Note #2: The above testing was made for the following virtual wms
http://beta.geoportal.ypen.gr/geoserver/aqd-wms/ows?service=wms&version=1.3.0&request=GetCapabilities

1. wmsCaps_SameDefaultSupportedLang.html.zip
2. wmsCaps_noOtherSupportedLang.html.zip
3. wmsCaps_difDefaultSupportedLang.html.zip

[kalxas]

This might be the source of this issue:
geoserver/geoserver#5123

[kalxas]

My suggestion is to raise this issue upstream

[kalxas]

Reported upstream:
https://sourceforge.net/p/geoserver/mailman/message/37379044/

[kalxas]

Update 08-11-2021: We agreed to not add extra languages in version 2.20 since this triggers the validator bug. Waiting for bug to be resolved upstream.

[kalxas]

Related: https://osgeo-org.atlassian.net/browse/GEOS-10852

[kalxas]

Related: https://osgeo-org.atlassian.net/browse/GEOS-10557

[kalxas]

Related: https://osgeo-org.atlassian.net/browse/GEOS-10411
and fixed here: geoserver/geoserver#5725

[kalxas]

The code used to encode the language:
https://github.com/geoserver/geoserver/blob/1668c7ca5e2922978dfc930002f91062831eed57/src/extension/inspire/src/main/java/org/geoserver/inspire/ServicesUtils.java#L71