Catalan as supported language in capabilities

[danicgc]

When including Catalan ("cat") as one of the supported languages in the capabilities document of a WMS, the at04-getcapabilities-xml-schema-validation throws the following error message, despite being a regional language included on the INSPIRE common.xsd schema (and so having an ISO 639-2/B alpha 3 code):

Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 99; columnNumber: 70; cvc-enumeration-valid: Value 'cat' is not facet-valid with respect to enumeration '[bul, cze, dan, dut, eng, est, fin, fre, ger, gre, hun, gle, ita, lav, lit, mlt, pol, por, rum, slo, slv, spa, swe]'. It must be a value from the enumeration. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]

[carlospzurita]

Dear @danicgc

Thank you for raising this issue. We are going to check the WMS ETS for this Test Step. In the meantime, can you send us the service endpoint that you are validating?

[danicgc]

The WMS URL is http://geoserveis.ide.cat/idec_inspire_ps/wms/service
Please discard other error messages thrown, as we are working on them.
Thank you

[carlospzurita]

Dear @danicgc

we have been checking this issue with the Techincal Guidances. Checking the Table 3 for the VS TG in page 21, it establishes a mapping for elements in the GetCapabilities document to the corresponding Metadata Element for the service. If we take a look into the Metadata Language described in section 2.2.2 of the MD TG 2.0, you can find the requirement C.5

The official languages contained on the common schema listed under the <xs:simpleType name="euLanguageISO6392B"> element are the official languages, and so the ETS uses them to apply the schema validation. Catalan is not part of the list of official languages, and so the validation on this service should fail.

[carlospzurita]

Dear @danicgc

Did you have the opportunity to review the last comment that we posted? It would be very useful for us in order to close this issue for the release.

[carlospzurita]

Dear @danicgc

Do you have any feedback on this issue? It would be useful to us to know if we can close this issue or do a new analysis

Best,

Carlos.

[fabiovin]

Dear @danicgc,

as indicated by Carlos, according to TG Requirement C.5, the “Metadata language” shall be one of the official languages of the European Union. In MD TG this element (Metadata language) has multiplicity 1.
The “Metadata Language” element is mapped to the “inspire_common:SupportedLanguages” (ExtendedCapabilities) element of the WMS_Capabilities ( Table 3 for the VS TG in page 21).

But this element (inspire_common:SupportedLanguages) can contain 1 or more sub-elements, as indicated in the Implementation Requirement 71 in the VS TG, allowing the provision of a GetCapabilities-Response in different languages. In this case, the supported languages seem to be all the ones defined by ISO 639-2/B, as indicated in Table 9.

The GetCapabilities-Response elements used to document the different languages, according to Requirement 71, make use of the same child element inspire_common:Language.

So, according to the mapping (Table 3 for the VS TG on page 21) between the “Metadata Language” element and the “inspire_common:SupportedLanguages” element, the data type associated with the <inspire_common:Language> element, in the common.xsd was "euLanguageISO6392B", limiting the allowed values to the official languages of the European Union.

Considerations:

1. Multilingualism is foreseen also in the metadata, using, for instance, the “gmd:PT_FreeText” encoding for the free text values. In this case, it seems that no restriction on the languages is present.
2. INSPIRE requires multi-language support and requests a list of all supported languages as well as the default language in the capabilities document. Based on the language parameter in the GetCapabilities request, certain specific metadata values, are provided in the requested language. If the language is not supported (or no language parameter is present), the default language is used.

Possible solution:

The “Metadata Language” element could be associated to the “inspire_common:DefaultLanguage” element (which is the mandatory sub-element of the “inspire_common:SupportedLanguages” element and it has multiplicity 1), leaving the possibility to use other languages (using the <inspire_common:SupportedLanguage> elements) different from the official ones.

This solution requires:

1. a modification of the “Technical Guidance for the implementation of INSPIRE View Services” (Table 3) in order to specify the mapping between the “Metadata Language” element and the “inspire_common:DefaultLanguage” element.
2. a modification on the commom.xsd schema in order to associate a different data type to the “Language” element
3. the implementation of a specific check on the “inspire_common:DefaultLanguage” element, in order to verify that only an official language of the European Union is used.

[danicgc]

Dear @fabiovin,
First of all, thank you very much for the review of the issue.
Your solution is perfect for us and we wish the same for the rest of the community, as it helps multilingualism.
We hope it to be implemented soon.
Best regards,

[jescriu]

Dear Fabio & Marco,
Thank you very much again for considering my email RE Validation of multilingual INSPIRE View Services.pdf regarding the validation of multilingual INSPIRE View Services, based on what was in principle acccepted for the Geoportal Validator back in 2017.
This is really a major step for reusing INSPIRE services in a multilingual context.
All the best.

[danicgc]

Dear @fabiovin,
It's some months since you suggested a nice solution for a better multilingualism but we are not aware of any action about it. Do you know how/where to monitor it? We did not reported it to any other community nor team.
Thank you in advance.

[fabiovin]

Dear @danicgc,

thank you for your reminder.

We discussed this internally and decided to start the process of implementing the solution that we proposed some time ago.
The proposed solution requires changes in the different INSPIRE artefacts, i.e. technical guidance, schemas and reference validator.

We started to analyze the feasibility of changing the common.xsd schema and/or the other schemas involved, when we have completed the analysis we will open the related issues in the dedicated repository (i.e. Technical guidance and Application schemas).

We will link the related issues here so that you can monitor them from this issue.

Regards,
Fabio