View Service WMS: Capabilities XML schema validation fails with SLD operations

thijsbrentjens commented 5 years ago

WMS: http://www.broinspireservices.nl/wms/osgegmw-a-v1.0?&request=GetCapabilities&service=WMS

The View Service - WMS validation fails the schema validation. The Capabilities document has, besides INSPIRE Extended Capabilities, another extension, WMS-SLD operation for GetLegendGraphic.

This is not part of the schema of INSPIRE VS. However, it is valid for WMS. How to deal with this? Should this error be ignored then? Should the WMS-SLD schemas be imported as well? Or for validation should there be another schema importing both INSPIRE VS and WMS SLD?

thijsbrentjens commented 5 years ago

Note: another option is to try to use the INSPIRE VS schema and if that fails, try if the schemas as declared in the xsi:schemaLocation of the Capabilities document could be used. This is quite complicated and also tricky, in a sense that using the schemas as declared by the service itself, may not be correct / outdated.

MarieLambois commented 5 years ago

This issue is linked with the general issue of dealing with extensions. Extensions (for data, metadata or services) are never forbidden in INSPIRE so I think that the validator should allow them. One solution indeed is to used the declared schema instead of fixed ones.

bgsmase commented 5 years ago

Is it possible for the validator just to ignore unknown elements in extension positions?

thijsbrentjens commented 5 years ago

I'll provide the schema we used to include the WMS-SLD schema as well. This solved issues in NL.

thijsbrentjens commented 5 years ago

Validation against this (or a similar) schema won't fail XSD validation if the WMS-SLD operations are offered by the WMS:

http://validatie.geostandaarden.nl/schemas/wms-sld-inspire.xsd

MarcoMinghini commented 5 years ago

2017.4 meeting 2019-05-22

There is a general agreement that the Validator should allow extensions, i.e. other schemas in addition to those required by INSPIRE.
If we change the behaviour to validate against all the schemas declared, this might generate problems (e.g. there might be local schemas only available on the intranet).
Another option is to only allow some well-known WMS extensions, like SLD.
It is agreed to keep the discussion open, waiting for some more examples from other countries.

nmtoken commented 5 years ago

?&request=

Note that the syntax in the request is incorrect according to the WMS specification, it should be:

?request=GetCapabiilities&

Parameter name/value pairs end with the & not begin with it,

ref Tables 2 WMS OGC 01-068r3 and OGC® 06-042

http://host[:port]/path?{name[=value]&}

URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an optional part; {} denotes 0 or more occurrences. The prefix is entirely at the discretion of the service provider.

name=value&

One or more standard request parameter name/value pairs defined by an OGC Web Service. The actual list of required and optional parameters is mandated for each operation by the appropriate OWS specification.

So a WMS GetMap request for a layer with the default style should use styles& and not styles=&

thijsbrentjens commented 4 years ago

All, just a check if other countries have implementation examples of WMSes with extensions (like SLD) that can be listed here (as discussed in the meeting of May).

For example, Mapserver implementations are known to support the SLD extension. I can imagine that in other countries there are WMS implementations running Mapserver as well.

In NL there are multiple data providers that offer services with the SLD extension. So it is not a single service, but for several services we can't use the reference validator now. We would like to work towards a solution. We hope others can help in bringing this further.

Test examples we have from different providers: http://geodata.nationaalgeoregister.nl/natura2000/wms?SERVICE=WMS&request=GetCapabilities http://www.broinspireservices.nl/wms/osgegmw-a-v1.0?request=GetCapabilities&service=WMS

Kate-Lyndegaard commented 4 years ago

We would like to voice our support for the inclusion of the WMS SLD extension. At wetransform, we serve INSPIRE compliant network services for numerous organizations in member states including Germany, Denmark, Holland and Austria. We include the following schema location in our WMSs: http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd. This enables us to offer the GetLegendGraphic request.

Example WMS: https://haleconnect.com/ows/services/org.223.f8a77f5a-1260-41be-892a-7d57c2983f18_wms?SERVICE=WMS&REQUEST=GetCapabilities&VERSION=1.3.0

fhoubie commented 3 years ago

We have started to validate our implementation and we encounter the same problem of unsupported extensions schema (SLD or other) by validator. We have reported this here. As far as the samples do use those extensions, we think that the validator shall support them.

dahermansson commented 3 years ago

Is there any progress on this issue? We have this error in the validator on all our viewservices witch we have implemented with Carmenta Server. Example WMS: http://geo-inspire.trafikverket.se/MapService/wms.axd/TN_WaterTransportNetwork?Service=WMS&request=GetCapabilities

nmtoken commented 3 years ago

For example, Mapserver implementations are known to support the SLD extension. I can imagine that in other countries there are WMS implementations running Mapserver as well.

A quick test, if the service announces support for a GetLegendGraphic operation or references such a request in the LegendURL, then it supports SLD. GetLegendGraphic is not defined by the WMS specification.

pathmapper commented 3 years ago

Here are governmental (NRW / Germany) WMS which are using SLD: https://www.wms.nrw.de/geobasis/wms_nw_dop?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities https://www.wms.nrw.de/geobasis/wms_nw_dop_overlay?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities

There are a lot more WMS with SLD listed here.

It's also worth to note that QGIS Server 3.10, the OGC Reference Implementation for WMS 1.3.0, uses SLD by default and therefore for all WMS set up using QGIS Server the schema validation fails.

dperezBM commented 2 years ago

Dear all,

Since this issue had no interaction time ago, we decided to close it. Please feel free to open a new one if needed.

Thank you and best regards.

pathmapper commented 2 years ago

From https://github.com/INSPIRE-MIF/helpdesk-validator/issues/44#issuecomment-496218854

2017.4 meeting 2019-05-22

There is a general agreement that the Validator should allow extensions, i.e. other schemas in addition to those required by INSPIRE. If we change the behaviour to validate against all the schemas declared, this might generate problems (e.g. there might be local schemas only available on the intranet). Another option is to only allow some well-known WMS extensions, like SLD. It is agreed to keep the discussion open, waiting for some more examples from other countries.

After this comment, there are some more examples from other countries in this thread.

@MarcoMinghini is there any decision on this topic?

fabiovin commented 2 years ago

Dear all,

we are addressing this question in issue #616, please follow it for any updates.

A similar discussion is also present in the helpdesk repository (https://github.com/INSPIRE-MIF/helpdesk/issues/24).

Thanks.

INSPIRE-MIF / helpdesk-validator

View Service WMS: Capabilities XML schema validation fails with SLD operations #44