QGIS » QGIS Application

Hi.

I confirm that the action described resolve the validity problem.

I modify the code of qgis-server adding the prefix and the namespace and schemaLocation missed.
Also I comment the code for GetStyle and GetPrint in the GetCapability response.

And voila' the response now is VALID.

For me is ok .

Now we have our "qgis-server" compliant with ogc and inspire.

:))

Regards.

Is there any practical problem with this?

I dont know who really use the
tags

GetStyles and GetPrint in the GetCapabilities.

Surely no one of the standard OGC client like Arcgis, QGIS, Autoca, Geotool-based and so on no one could use this two tags.

I don't know if the two web client for qgis like the
"QGIS Web client" and the "Lizmap web client" will use it.

AFAIK the GetCapabilities is a standard OGC world used response. And some proprietary tags in it will break the compatibility.

As example our client based on the GeoTools and based on a rigorous apply of OGC stadard will fail.
Also any other standard client like ArcGIS that use the getcapabilities to understand what layers and what functionalyity will fail if the response is not standard.

If agree with this consideration.
I could open a PULL for a Patch.
The patch fixe the namespace of getLegendGraphics and remove the tags GetStyle and GetPrint from the GetCapabilities Response.

I tested the patch on my qgis-server (the same of the ticket). Now it is patched and is OGC compliant in the wms 1.3.0 getcapabilities response.

Regards.

aperi2007 - wrote:

Surely no one of the standard OGC client like Arcgis, QGIS, AutoCAD, Geotool-based and so on no one could use this two tags.

Of course, but they also don't have a problem with it.

I don't know if the two web client for qgis like the "QGIS Web client" and the "Lizmap web client" will use it.

Not sure about Lizmap, but QWC does. GetPrint was introduced for QWC.

AFAIK the GetCapabilities is a standard OGC world used response. And some proprietary tags in it will break the compatibility.

Not really. I don't know any client that checks the validity of the GetCapabilities response.

As example our client based on the GeoTools and based on a rigorous apply of OGC standard will fail.
Also any other standard client like ArcGIS that use the getcapabilities to understand what layers and what functionalyity will fail if the response is not standard.

Did you verify that that's actually true? ArcGIS 10.1 apparently doesn't have a problem with QGIS server. And invalid responses might do no harm at all as long as all the expected stuff is actually there - which is the case. Clients shouldn't be to picky as there are lots of servers out that have "alternative" interpretations of the spec.

If agree with this consideration. I could open a PULL for a Patch. The patch fixe the namespace of getLegendGraphics and remove the tags GetStyle and GetPrint from the GetCapabilities Response.

I suppose that would break existing clients (that are not that picky on validity). Does QGIS Desktop still work (ie. does it show the legend)? I suppose b3a708fba doesn't and still should make the response valid. Although letting the schemaLocation point at an extended schema might be in a grey area of the spec. Maybe there is a cleaner way to extend the schema without introducing a different namespace. I didn't find any, but I'm not an XML expert. xmlpatternsvalidator at least doesn't complain anymore.

I tested the patch on my qgis-server (the same of the ticket). Now it is patched and is OGC compliant in the wms 1.3.0 getcapabilities response.

Which clients did you use to test?

I rsponde between rows:

aperi2007 - wrote:

Surely no one of the standard OGC client like Arcgis, QGIS, AutoCAD, Geotool-based and so on no one could use this two tags.

Of course, but they also don't have a problem with it.

I know how work arcgis.
I use arcgis 9.3.1
It call for capabilities and show all the layers it find.
You know it ?

I don't know if the two web client for qgis like the "QGIS Web client" and the "Lizmap web client" will use it.

Not sure about Lizmap, but QWC does. GetPrint was introduced for QWC.

Not really. I don't know any client that checks the validity of the GetCapabilities response.

The GetCapabilities is a standard OGC. So it MUST BE used with a standard OGC xsd.
You cannot change it otherwise it is not compiant.
ANY PUBLIC ADMINISTRATION IN EUROPE IS CALLED TO USE INPSIRE.
The use of a server that is not inspire compliant (ogc compliant) is a violation of european laws.
And cannot be fund with public money.

As example our client based on the GeoTools and based on a rigorous apply of OGC standard will fail. Also any other standard client like ArcGIS that >use the getcapabilities to understand what layers and what functionalyity will fail if the response is not standard.

Did you verify that that's actually true? ArcGIS 10.1 apparently doesn't have a problem with QGIS server. And invalid responses might do no harm at all >as long as all the expected stuff is actually there - which is the case. Clients shouldn't be to picky as there are lots of servers out that have >"alternative" interpretations of the spec.

In Italy a public administration cannot say to an user "hey buy a arcgis 10 license " because your arcgi 9.3 don't work with my incompatible OGC server.
I Guess also in other european menber states is the same.

If agree with this consideration. I could open a PULL for a Patch. The patch fixe the namespace of getLegendGraphics and remove the tags GetStyle and >GetPrint from the GetCapabilities Response.

I suppose that would break existing clients (that are not that picky on validity). Does QGIS Desktop still work (ie. does it show the legend)? I suppose
b3a708fba doesn't and still should make the response valid. Although letting the schemaLocation point at an extended schema might be in a grey area of
the spec. Maybe there is a cleaner way to extend the schema without introducing a different namespace. I didn't find any, but I'm not an XML expert.
xmlpatternsvalidator at least doesn't complain anymore.

ok, I don' t well explain.
Tne qgis desktop is totally neutral on this problem.

The GetStyles and GetPrint tags ARE NOT present in Mapserver and Geoserver.

IS qgus workng with Mapserver or GeoServer ?

Surely yes.
SO the GetStyles and GetPrint are unusegul for QGIS desktop.

They are added to give a commercial advantege to some web portal solution.
That adopting a non standard OGC solution hope to gain a piece of market.

But a public administration cannot be the funder of a product not interoperable and not compliant with inspire specificitaio

SO I Guess actually the clients of this product are or private subject or PA that don't understand well this question.

But is ESRI and Autocad and so on
will understand this will have no problem to explain well to their new potential client that QGIS server is NOT compliant with Inspire and so is unuseful.

Regards,

Andrea.

sorry.
I dont understand.
AFAIK the better solution is add the namespace.

This is the code to set the change in the qgiswmsserver.cpp.

wmsCapabilitiesElement.setAttribute( "xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance" );
-->    wmsCapabilitiesElement.setAttribute( "xmlns:sld", "http://www.opengis.net/sld" );
-->    wmsCapabilitiesElement.setAttribute( "xsi:schemaLocation", "http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd" );

and also this:

//wms:GetLegendGraphic
-->  elem = doc.createElement( "sld:GetLegendGraphic"/*wms:GetLegendGraphic*/ );

This code correct the GetLegendGraphics problem.

Obviously still remain to resolve the presence of GetStyle e GetPrint.

QGIS server has a GetProjectSettings request which has a lot more information for QGIS webclient (which the GetPrint tag is for). In earlier times there was no such request and the GetCapabilities request was "abused". Now, probably you can get rid of these vendor things in the GetCababilities response.

Stefan

aperi2007 - wrote:

Not really. I don't know any client that checks the validity of the GetCapabilities response.

The GetCapabilities is a standard OGC. So it MUST BE used with a standard OGC xsd.

I know. But I don't know any client that actually validated the response.

In Italy a public administration cannot say to an user "hey buy a arcgis 10 license " because your arcgi 9.3 don't work with my incompatible OGC server.
I Guess also in other european menber states is the same.

I was just asking if you actually tried any clients and found any that actually fail. Any client that only accepts fully valid GetCapabilities responses will probably have problems with lots of available WMS servers and also be very slow as validating the schema takes much time. So I suppose in practice no client will actually do that and hence any client capable to work with any valid schema will be able to ignore elements that it doesn't support and in turn should also work with QGIS' response. That doesn't mean that QGIS' shouldn't be compliant - it just questions the actual relevance of it.

To me it was unclear if you just suspect that ArcGIS doesn't work or if you actually verified that it has. That I found ArcGIS 10.1 working (and now verified that 9.2 also appears to work) suggested that it was just a hunch.

aperi2007 - wrote:

sorry. I dont understand.

http://qgis.org/wms_1_3_0.xsd reads:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:wms="http://www.opengis.net/wms" targetNamespace="http://www.opengis.net/wms">
  <include schemaLocation="http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd"/>
  <element name="GetLegendGraphic" type="wms:OperationType" substitutionGroup="wms:_ExtendedOperation" />
  <element name="GetPrint" type="wms:OperationType" substitutionGroup="wms:_ExtendedOperation" />
  <element name="GetStyles" type="wms:OperationType" substitutionGroup="wms:_ExtendedOperation" />
</schema>

So the schema wasn't copied.

AFAIK the better solution is add the namespace.

Right, but it might break existing clients and it's unclear to me if there are any clients that would benefit from it.

This is the code to set the change in the qgiswmsserver.cpp.

wmsCapabilitiesElement.setAttribute( "xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance" );
--> wmsCapabilitiesElement.setAttribute( "xmlns:sld", "http://www.opengis.net/sld" );
--> wmsCapabilitiesElement.setAttribute( "xsi:schemaLocation", "http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd" );

If we did that I'd propose a qgis namespace similiar to the above xsd listing all the available extensions (ie. like umn mapserver does).

QGIS server has a GetProjectSettings request which has a lot more information for QGIS webclient (which the GetPrint tag is for). In
earlier times there was no such request and the GetCapabilities request was "abused". Now, probably you can get rid of these vendor things
in the GetCababilities response.

Stefan

Hi Stefan,
yes your solution is the right think to do.

Put all not ogc compliant things in a not standard request/response couple.
So it can host every new introduced by qgis. And leave the standard response only for standard things.

Thx,

Andrea.

Right, but it might break existing clients and it's unclear to me if there are any clients that would benefit from it.

This is the code to set the change in the qgiswmsserver.cpp.

wmsCapabilitiesElement.setAttribute( "xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance" ); --> >wmsCapabilitiesElement.setAttribute( "xmlns:sld", "http://www.opengis.net/sld" ); --> wmsCapabilitiesElement.setAttribute( >"xsi:schemaLocation", "http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld >http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd" );

If we did that I'd propose a qgis namespace similiar to the above xsd listing all the available extensions (ie. like umn mapserver does).

The client actually don't do any type of validation otherwise they will fails.
This mena thay don't use any standard library to parse and extract informations from the xml response otherwise they fail in invalidity.
This mean the client parse the response manually.

This mean also that QGIS is caged by some manual client that use a non standard and not wms compliant xml response ?

This is the better think that may hope a commercial product like esri.
:))

aperi2007 - wrote:

If we did that I'd propose a qgis namespace similiar to the above xsd listing all the available extensions (ie. like umn mapserver does).

The client actually don't do any type of validation otherwise they will fails.
This mena thay don't use any standard library to parse and extract informations from the xml response otherwise they fail in invalidity.
This mean the client parse the response manually.

Not validating doesn't mean that you don't use a standard library and do manual parsing. You can use a standard library and still skip the validation - actually you probably always will for performance reason unless there is reasonable doubt that the response is correct (eg. for debugging while developing or if you use an unreliable transport path etc).

This mean also that QGIS is caged by some manual client that use a non standard and not wms compliant xml response?

Extending the GetCapabilities response is covered by the spec - that's what the _ExtendedOperation element is for. I think we're in a grey area now. AFAICT the spec doesn't clearly state where the schemeLocation should point, there is intended room for extension and validation tools are probably unable to spot any invalidity now, but we're probably still outside the intended interpretation of the spec as GetCapabilities "shall contain an XML Schema instance schemaLocation attribute that binds the “http://www.opengis.net/wms” namespace to the schema in E.1." - which it does - but indirectly ;)

But the solution with the qgis namespace would be fine and valid - although it still might break clients.

Extending the GetCapabilities response is covered by the spec - that's what the _ExtendedOperation element is for. I think we're in a
grey area now. AFAICT the spec doesn't clearly state where the schemeLocation should point, there is intended room for extension and
validation tools are probably unable to spot any invalidity now, but we're probably still outside the intended interpretation of the
spec as GetCapabilities "shall contain an XML Schema instance schemaLocation attribute that binds the “http://www.opengis.net/wms”
namespace to the schema in E.1." - which it does - but indirectly ;)

The important is to grant the compatibility with the OGC spec. So the solution with the extendedoperation is valid if it is compliant with the OGC xsd.

But the solution with the qgis namespace would be fine and valid - although it still might break clients.

I tested the "qgis" prefix solution instead of "sld" with XMLSPy.
It is valid.

And francly, to update the own client from "sld" or "none" to "qgis" is really easy.
And to have a qgis-server compliant is more advantage for all.

So the correct should be:

<WMS_Capabilities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.3.0" xmlns="http://www.opengis.net/wms" xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd" xmlns:qgis="http://www.opengis.net/sld">

...
   <qgis:GetLegendGraphic>
    <Format>image/jpeg</Format>
    <Format>image/png</Format>
    <DCPType>
     <HTTP>
      <Get>
       <OnlineResource xlink:type="simple" xmlns:xlink="...omissis..."/>
      </Get>
     </HTTP>
    </DCPType>
   </qgis:GetLegendGraphic>

this is the "qgis" namspace definition:

--> xmlns:qgis="http://www.opengis.net/sld"

and the schemaLocation:
should point also to the
http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd

Regards,

A.

aperi2007 - wrote:

I tested the "qgis" prefix solution instead of "sld" with XMLSPy.
It is valid.

Isn't the current solution "valid" for xmlspy too?

aperi2007 - wrote:

I tested the "qgis" prefix solution instead of "sld" with XMLSPy.
It is valid.

And does it also make ArcGIS 9.2 work for you?

aperi2007 - wrote:

I tested the "qgis" prefix solution instead of "sld" with XMLSPy. It is valid.

Isn't the current solution "valid" for xmlspy too?

I tested it using the official and valid xsd from OGC.

The question is not only xmlspy.
I don't tested your solution, but I understand you point to another xsd that you have put on your site.

This xsd is not the official xsd.
I try to explain better:
Is it exactly equals to that from OGC ?

If yes why point it on your private site ?.
If you stop your site, the server response will become unvalidable.

if it is not equals to the official xsd , this mean you have chage something in the standard.

And surely the xmlspy will validable it.
But xmlspy don't know that the address you use is not the official url requested from the specs.
:)

So you have a valid xml but absolutely no grant to be interoperable because you valid on a different xsd rather than the official.

A.

aperi2007 - wrote:

The question is not only xmlspy.

I think I fully understand your concerns. My question just is if there are any clients affected by this. I also don't know if there are actually clients (still) relying on the current behaviour. Maybe other can comment on that.

For instance does ArcGIS 9.3 actually validate the schema, while 9.2 and 10.1 apparently don't? I suspect that 9.3 will still have problems even when the validity issue is fixed.

I don't tested your solution, but I understand you point to another xsd that you have put on your site.

But the spec doesn't require that you use the xsd directly from OGC. It explicitly allows to use a copy:

7.2.4 GetCapabilities response

7.2.4.1 Introduction

When invoked on a WMS, the response to a GetCapabilities request shall be an XML document containing service metadata formatted according to the XML Schema in E.1. The schema specifies the mandatory and optional content of the service metadata and how the content is formatted. The XML document shall contain a root element named WMS_Capabilities in the “http://www.opengis.net/wms” namespace. This element shall contain an XML Schema instance schemaLocation attribute that binds the “http://www.opengis.net/wms” namespace to the schema in E.1. The schema bound to the root attribute may be a copy of the schema in E.1 instead of the master copy at the URL stated in the annex provided none of the normative content of the schema is changed. The schema copy shall be located at a fully-qualified and accessible URL to permit XML validating software to retrieve it. The response shall be valid according to XML Schema validation rules.

It's explictly stated if extensions actually mean that "the normative content of the schema is changed" - as the spec explictly allows extensions and the scheme is the OGC xsd + those extensions. The extensions usually are in an separate xsd (which with my limited xml knowledge always come with a separate namespace), but "6.9.5 Extended capabilities and operations" also doesn't explictly requires that either.

But the spec doesn't require that you use the xsd directly from OGC. It explicitly allows to use a copy:

Yes but is a technical need by the parser.
The parser "de facto" when parser using thexsd must download it.

Of course this mean that you could download it and put it on your site.

Must the spec explicitly DENY that you MODIFY IT and (perhaps) deny also the redistribute.
I don't know if the OGC licence deny the redistribution.

But surely the ISO organization (just as another example of the distributor of the WMS SPecs)
explixitly deny the redistribution of their XSD.

You can download but for your internal use only.

The two organization seem apparently tohave different logics but instead both have the same goal (objective) in mind

To have a GRANT that the user that download the xsd DON'T CHANGE something in it.

One say "you cannot change anythin" the other say "you cannot redistribute".
So avoid the confiusion.

Onestly if one has the xsd in its site, when has any problem is more easy to change a little row in it rather then
the change its code.
:))

So to point forward the original in the original site is like say
"I am compliant to the original specs as you can see".

Instaed point to a different site , a private site is like see
"My product work with my xsd. I hopeis equals to the original, but I dont know".

So I guess more better to point directly it.

Otherwise the QGIS himself has any risk that someone
could add new fetures and add them also to the xsd on it site.
No-one could detect this, the validation tets will pass , but was not autentically valid.

And when was discovered that the validity is FALSE the qgis credibility was definitively compromise.

Please notice:
I discovered the invalidity because I have a problem with our software and after a day spent to search the problem on out software I do a test on validity of xml response of qgis.

The response was surprisly for me.

If you was using a xsd on your site that match fully the need of qgis.
The validity in the xmlspy was be passed, but also my software was still go in error because it wrong to parse the response because It dont know that there is a GetPrint tag in that position.
And lost many more time to discovered it.

I guess this is a bad practice.I practice that I avoid because is dangerous and expose to future changing and waste of time to understand why that software don't work with qgis-server.

A

aperi2007 - wrote:

But the spec doesn't require that you use the xsd directly from OGC. It explicitly allows to use a copy:

Yes but is a technical need by the parser.
The parser "de facto" when parser using the xsd must download it.

Of course this mean that you could download it and put it on your site.

Must the spec explicitly DENY that you MODIFY IT and (perhaps) deny also the redistribute.
I don't know if the OGC licence deny the redistribution.

Of course, that's what a spec is for. If you claim we are non-compliant back that up with a statement from the spec that we violate. We don't need to assess why a spec sets clear bounds in some areas and leaves room for interpretation in others - we just need to stay within the bounds it sets to be compliant. According to the spec extensions are ok and pointing at different schema locations is ok unless "the normative content of the schema is changed". I don't know if the there is an other part of the spec that elaborates what that quote actually supposed to mean and if aren't compliant to that, but I don't see something in that quoted paragraph that we clearly violate.

I'm not saying that we are compliant, but I also don't say that we non-compliant. I don't know if we actually violate the spec. Sorry, but your general remarks about generic standards don't help with that.

I'd also like do have direct answers to my questions about which clients you found being affected (you claimed ArcGIS 9.3 has problems, while I didn't find problems with 9.2 and 10.1) and whether they are still affected and if those problems arise just from the capabilities being invalid or if those clients actually can't cope with extensions, although they should when the schema includes any according to the spec. In the latter case we could - for the sake of interoperability with non-compliant clients - maybe have an optional setting to avoid exposing the extensions. But as said earlier to be affected by this, a client must validate the response (which most probably don't for performance reasons) and/or iterate the requests listing in capabilities and look for stuff that it doesn't support, although that might make an otherwise perfectly usable service unusable.

What I want to know: which clients are affected by the current behaviour and which clients would be affected by a changes of the current behaviour (extended requests without a prefix). You seem to avoid answering direct questions to that, I don't know and those who do might not be available until after the pentecost weekend. So we probably just have to wait.

I agree with Jürgen that it is not completely clear what "The schema bound to the root attribute may be a copy of the schema in E.1
instead of the master copy at the URL stated in the annex provided none of the normative content of the schema is changed" really permits or bans. I think the intent was that it was allowed to change comments and documentation (as stated in the intro paragraph of E.1), but perhaps not extending the schema itself.

The way Inspire proceeds to extend WMS 1.3.0 can be a source of inspiration (pun intended ;-)) in that case.

For example, here's the beginning of the response of UMN MapServer to a GetCapabilities request to a project configured with Inspire extensions:

<WMS_Capabilities version="1.3.0" 
     xmlns="http://www.opengis.net/wms" 
     xmlns:sld="http://www.opengis.net/sld" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xmlns:ms="http://mapserver.gis.umn.edu/mapserver" 
     xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" 
     xmlns:inspire_vs="http://inspire.ec.europa.eu/schemas/inspire_vs/1.0" 
     xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd
                         http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd
                         http://inspire.ec.europa.eu/schemas/inspire_vs/1.0 http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd
                         http://mapserver.gis.umn.edu/mapserver http://www.geodaten-mv.de/dienste/inspirevs_test?language=ger&amp;service=WMS&amp;version=1.3.0&amp;request=GetSchemaExtension">

and later in the doc :

  <inspire_vs:ExtendedCapabilities>
    <inspire_common:MetadataUrl xsi:type="inspire_common:resourceLocatorType">
      <inspire_common:URL>http://www.geodaten-mv.de/soapServices/CSWStartup?service=CSW&amp;version=2.0.2&amp;request=GetRecordById&amp;outputSchema=http://www.isotc211.org/2005
/gmd&amp;ElementSetName=full&amp;Id=4d5f1402-5b2b-43ec-949f-92d125179318</inspire_common:URL>
      <inspire_common:MediaType>application/vnd.ogc.csw.capabilities.response_xml</inspire_common:MediaType>
    </inspire_common:MetadataUrl>
    <inspire_common:SupportedLanguages>
      <inspire_common:DefaultLanguage><inspire_common:Language>ger</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>ger</inspire_common:Language></inspire_common:ResponseLanguage>
  </inspire_vs:ExtendedCapabilities>

The http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd schema is :

<schema xmlns:inspire_vs="http://inspire.ec.europa.eu/schemas/inspire_vs/1.0" xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:wms="http://www.opengis.net/wms" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" targetNamespace="http://inspire.ec.europa.eu/schemas/inspire_vs/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.1">
    <import namespace="http://www.opengis.net/wms" schemaLocation="http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd"/>
    <import namespace="http://inspire.ec.europa.eu/schemas/common/1.0" schemaLocation="../../common/1.0/common.xsd"/>
    <element name="ExtendedCapabilities" type="inspire_common:ExtendedCapabilitiesType" substitutionGroup="wms:_ExtendedCapabilities"/>
</schema>