INSPIRE VS: schema validation fails if capabilities contains additional operations or extended capabilities

[lgoltz]

schema validation fails if capabilities contains additional operations or extended capabilities

Test run: https://inspire.ec.europa.eu/validator/v2/TestRuns/EIDb0da69f6-a29c-495d-99fb-52e868f1a919.html
Service: https://www.geoseaportal.de/inspire/services/MU_INSPIRE_VS?service=WMS&request=GetCapabilities

The test GetCapabilities_Operation -> at04-getcapabilities-xml-schema-validation -> check-xml-schema-valid (https://inspire.ec.europa.eu/validator//v2/TestRuns/EIDb0da69f6-a29c-495d-99fb-52e868f1a919.html?lang=de#EID9805ecd3-0175-1000-1742-8c6844ab7f3d) fails with:

Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 94; columnNumber: 32; cvc-complex-type.2.4.a: Invalid content was found starting with element 'sld:GetLegendGraphic'. One of '{"http://www.opengis.net/wms":_ExtendedOperation}' is expected. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]

Validation of the capabilities document is successful with other xml schema validations. It seems that the xsi:schemaLocation in the root element is not evaluated.

The same applies to the element soapwms:ExtendedCapabilities, the xsi:schemaLocation is located at this element, not the root document.

[carlospzurita]

Dear @lgoltz

Sorry for the delay, we are discussing internally the correct application of the schema. Validating it with Oxygen, the XML seems to be correct, so we are looking into the usage of the schemas by the validator.

[iuriemaxim]

Dear @carlospzurita Isnt't it related to the way this https://github.com/inspire-eu-validation/community/issues/398 is tried to be fixed? Before implementing https://github.com/inspire-eu-validation/community/issues/398 please ensure that the conclusions are correct.

[akuegeler]

We are seeing a different message for what I believe may be the same problem:

Error in step: at04-getcapabilities-xml-schema-validation
Schema not valid: [org.xml.sax.SAXParseException; systemId: http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd; lineNumber: 1; columnNumber: 1; Premature end of file. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]

In our case a namespace is used correctly in the capabilities response and imported in a referenced XSD (inspire-wms-extension.xsd):
<import namespace="http://www.esri.com/wms" schemaLocation="./esri-wms-extension.xsd"/>

(Unfortunately the two issues @iuriemaxim references cannot be accessed anymore, so I can't tell if this has been discussed before.)

A solution would be much appreciated!

[iuriemaxim]

@akuegeler

I think that the issue refereed in my post was now moved here: #398

All the links were broken since January 2021: #492

According to the description, in this case could be also relevant this:
#191
and this:
#201

[akuegeler]

Thank you @iuriemaxim, that is very helpful!
On the other posts:

• I am referring to WMS in this case.
• the XSD are accessible by clients

[iuriemaxim]

@akuegeler

Even if the 191 is refering to WFS, the schema location is for all services, so for WMS as well.
Even if 201 is refering to XSD accessible by clients, it is still relevant that no check is done to verify if the schema provided corespond to the schema expected.

So all incidents 492, 191 and 201 could be still relevant,

[JLSchaap]

Hello @dperezBM,
For me the status of this issue is not clear. Can we expect a fix for this issue?

[JohannaOtt]

Hello @dperezBM,
For me the status of this issue is not clear. Can we expect a fix for this issue?

@carlospzurita @fabiovinci @dperezBM I would like to double that. I get the error message @lgoltz reported (for the soapwms:ExtendedCapabilities element, not the GetLegendGraphic one) for example for this service.
To me it is not clear from the discussions in the related issues if there will be a change in the validator or if a change is needed in the providers' WMS.
Please provide an answer on if we can expect a change in the validator or what we need to change for our WMS to pass this test.

[JohannaOtt]

@carlospzurita @fabiovinci @dperezBM How is the current state here?

[fabiovinci]

Dear @JohannaOtt,

your service fails the at04-getcapabilities-xml-schema-validation test since it contains an additional soapwms:ExtendedCapabilities element defined in a "proprietary" schema (http://schemas.deegree.org/extensions/services/wms/1.3.0/soapwms.xsd).

The Validator uses for this test the fixed INSPIRE schema (https://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd) in which we added an additional OGC schema in the release 2022.2 (http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd).

We will evaluate if it is correct to add additional "proprietary" schemas to the inspire_vs.xsd, through new schema change proposals, or if it is possible to validate the GetCapabilities document against the schemas declared in the document itself after verifying that the inspire_vs.xsd schema is present in the schemaLocation attribute.

[Claudia-WE]

Dear @fabiovinci,
You stated in your answer to JohannaOtt #438 (comment) that you would evaluate

if it is correct to add additional "proprietary" schemas to the inspire_vs.xsd, through new schema change proposals, or if it is possible to validate the GetCapabilities document against the schemas declared in the document itself after verifying that the inspire_vs.xsd schema is present in the schemaLocation attribute.

Do you have any news concerning this ?

Best regards;
Claudia

[iuriemaxim]

Dear @fabiovinci
For ensuring interoperability including in interogating the capabilities of INSPIRE services, most probably all data providers should use the same schemas, including inspire_vs.xsd schemas. GetCapabilities document is critical for machine to machine communication. So if data providers will use different schemas for describing the capabilities of their services, then services built on top of these services with "custom described capabilities" will malfunction.

For example some processing services (WPS) will malfunction, as they are also parsing the capabilities of the services before processing one or more services altogether.

This will lead to a limitation in using the services from INSPIRE infrastructure, which is not inline with the principles of INSPIRE Directive.

INSPIRE is not just about data, but especially about services. Services are described by their capabilities. Ensuring interoperability at the level of the services means also ensuring the interoperability of capabilities of the services.

Custom extension of the description of the capabilities of the services by data providers has a simllar effect to the service interoperability as the custom extension of the codelists has to the interoperability of the data.

Best regards,
Iurie Maxim

[annat2022]

Dear @fabiovinci ,

We will evaluate if it is correct to add additional "proprietary" schemas to the inspire_vs.xsd, through new schema change proposals, or if it is possible to validate the GetCapabilities document against the schemas declared in the document itself after verifying that the inspire_vs.xsd schema is present in the schemaLocation attribute.

Any news related to this? Can we expect a change in the validator?

All the best
Anna

[JohannaOtt]

We will evaluate if it is correct to add additional "proprietary" schemas to the inspire_vs.xsd, through new schema change proposals, or if it is possible to validate the GetCapabilities document against the schemas declared in the document itself after verifying that the inspire_vs.xsd schema is present in the schemaLocation attribute.

@fabiovinci Are there any news on that?

[fabiovinci]

Dear all,

we further discussed the issue internally and decided not to implement the first option (i.e. to add additional "proprietary" schemas to the inspire_vs.xsd) as it is not formally correct.

So, we are investigating how to implement the second proposed solution (i.e. to validate the GetCapabilities document against the schemas declared in the document itself after verifying that the inspire_vs.xsd schema is present in one of the schemaLocation attributes).

[iuriemaxim]

@fabiovinci
For investigating solutions for implementation of the second proposed solution, please have a look also at the #398, as some service providers have schemaLocation at element level and not in the root. Probably a decision can/should be made on #398 as well.

[emanuelaepure10]

Hi @fabiovinci,

Have you made a decision regarding the implementation of the second option? Is the issue currently in the pipeline?

Thank you

[fabiovinci]

Hi @emanuelaepure10,

we are working on the integration of the Good Practice "Data and Service Linking Simplification" (all the details are in this discussion) that will require an update of the ATS/ETS for View Service, so the changes could have an impact on this issue.
For this reason, we will evaluate a possible solution to this issue in parallel with the above-mentioned work.

[skornsekj]

Hi,

Is there any update on this issue. Since there has been some progress on the implementation on the Good Practice "Data and Service Linking Simplification".

Thanks for the update.
Jan Skornsek

[fabiovinci]

Dear @skornsekj,

only Part A of the Good Practice has been implemented at the moment, a solution to this issue will be provided with the implementation of Part B which will be done in the coming months.

[fabiovinci]

Dear all,

this issue should now be solved due to the changes introduced for the integration of the data-service linking simplification for WMS (See related issue #1098).

The validator "validates the document against XML schemas declared in the schemaLocation attribute". (See updated ATS at04)

The solution is available in the staging instance.

[fabiovinci]

Dear @lgoltz,

your WMS service should now be valid since the new release of the validator uses the schemas declared in the capabilities document.

In any case, it seems that the schema declared in the soapwms:ExtendedCapabilities element is invalid (i.e https://schemas.deegree.org/core/3.5/extensions/services/wms/soapwms.xsd).
Please double-check your service and attempt to validate it again.

[skornsekj]

Dear @fabiovinci,

Thanks for the update. Please, you provide the URL of the staging instance. I've never used that environment. Thanks!

[fabiovinci]

The fix is now available in the production instance.

[fabiovinci]

Dear all,

we internally tested the fix and it works fine so we will close the issue.

Please reopen the issue or open a new one if the error persists.