<div dir="ltr"><div><div><div><div><div>This is not only a inspire need. This more important because is an WMS invalidity.<br><br></div>I try to explain better.<br><br></div>The mapserver was not inpire compliant because it miss of something metadata elements.<br>
OK, but almost it was OGC WMS compliant.<br><br></div>The inspire specs say "take an OGC WMS compliant and on it add something that I say to you".<br><br></div>The QGIS IS not WMS Compliant . This is worst than inspire non compliant.<br>
<br></div><div>Also inspire say "the interoperability" is the base to start all together.<br><br></div><div>The invalidity of qgis-server is due to the add of a proprietary tag that fail the xsd tests OGC WMS.<br>
</div><div>So it is not interoperability with other products.<br><br></div><div>This is worst than :<br><br></div><div>To be more inspire compliant.<br><br>The question here is:<br>qgis-erver is not OGC WMS compliant.<br>
<br></div><div>However I say what is the problem:<br><br></div><div>The ticket is here:<br><a href="http://hub.qgis.org/issues/10489">http://hub.qgis.org/issues/10489</a><br><br></div><div>The problem are a worst definition of the Tag GetLegendGraphics,<br>
</div><div>but as report in the ticket the solution is described in the ticket.<br><br></div><div>The other two probles are the presence of a <br></div><div>GetStyle in the wms 1.3.0 response. The GetStyle was dismissed from OGC in the 1.3.0 response.<br>
<br>And the presence of the proprietary tag "GetPrint".<br><br></div><div>My simplesolution was change the GetLegendGraphics.<br></div><div>This is a simply change in the code.<br></div><div>I have patched my server using "sld" prefix because is the standard.<br>
But also the solution of Jef to use the "qgis" prefix is ok because is valid for a good validator (xmlspy I use).<br>So If the qgis groups decide to adopt the "qgis" prefix namespace for GetLegendGraphics, I have no problem to change my patch.<br>
Otherwise I leave the standard name "sld".<br><br>The other two problems.<br><br>GetStyles and GetPrint.<br>They are not tags of the WMS 1.3.0 specs.<br>So they should not be present in the response.<br>The solution is remove them or put them in the specific dedicated section.<br>
But obviously they are put correctly in that section.<br><br>Thx,<br><br>Andrea.<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-07 22:19 GMT+02:00 Alex Mandel <span dir="ltr"><<a href="mailto:tech_dev@wildintellect.com" target="_blank">tech_dev@wildintellect.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please add your specific list of current non-compliant issue to:<br>
<a href="http://hub.qgis.org/issues/6520" target="_blank">http://hub.qgis.org/issues/6520</a><br>
<br>
I'll add in a note about the WMS 1.3 tags specifically created for<br>
non-standard features.<br>
<br>
I think this issue can be resolved.<br>
<br>
Thanks,<br>
Alex<br>
<div><div class="h5"><br>
On 06/07/2014 01:17 PM, Alex Mandel wrote:<br>
> On 06/07/2014 01:06 PM, Andrea Peri wrote:<br>
>> Yes also this is possible,<br>
>> but pay attention to use it correctly.<br>
>> I guess it is no really simple to use (ie to define the extension).<br>
><br>
> It looks really simple to use according to the docs. If it works and<br>
> cascading WMS works with other WMS servers, and it passes the schema<br>
> check I see no issue.<br>
><br>
><br>
>> In the SLD world this was allowed and a unfortunately and worst<br>
>> understanding of it will born a lot of incompatible dialects.<br>
>> Also in the metadata world (iso19115) the possibility to extend the specs<br>
>> will produce incompatibility monster.<br>
>> :)<br>
> This exists in the html world, over time there are winners. If you don't<br>
> care to use the extra features you are always welcome to use the base<br>
> which is 100% compliant. The winners or some compromise variant end up<br>
> in the next version of the spec.<br>
><br>
>> I guess surely better and easy is put the new functions in in a distinct<br>
>> and new kind of request.<br>
>><br>
><br>
> After reading the WMS doc I believe using the tags I mention is the<br>
> correct way to do it. Technically the result is WMS 1.3.0 compliant.<br>
> Clients are free to ignore the extra functions as not using them does<br>
> not remove any required features.<br>
><br>
> As to why fund it? If QGIS provides other value to your organization in<br>
> some other way, total cost of operation may be lower to simply ensure<br>
> it's compliant rather than to switch software or have to use multiple<br>
> software.<br>
><br>
> Thanks,<br>
> Alex<br>
><br>
><br>
>> Andrea.<br>
>><br>
>><br>
>><br>
>> 2014-06-07 21:56 GMT+02:00 Alex Mandel <<a href="mailto:tech_dev@wildintellect.com">tech_dev@wildintellect.com</a>>:<br>
>><br>
>>> I just checked the WMS 1.3.0 specification document<br>
>>> <a href="http://portal.opengeospatial.org/files/?artifact_id=14416" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=14416</a><br>
>>><br>
>>> Extended optional features are allowed. There is a specific way to<br>
>>> include them. See section 6.9.5 "Extended capabilities and operations"<br>
>>> <_ExtendedCapabilities> or <_ExtendedOperations><br>
>>><br>
>>> So perhaps we just need to wrap those extra options in a specific tag<br>
>>> for them to pass schema testing.<br>
>>><br>
>>> Thanks,<br>
>>> Alex<br>
>>><br>
>>> On 06/07/2014 12:35 PM, Alex Mandel wrote:<br>
>>>> I understand the issue now. In order to be WMS 1.3 complaint you can<br>
>>>> only use what's in the spec.<br>
>>>><br>
>>>> Looking at an analogy with html specs I find this limitation appalling<br>
>>>> short-sighted. It means there can be no innovation testing new features<br>
>>>> with the spec unless you manage to get it into the future spec. I find<br>
>>>> it hard to comprehend that clients don't just skip tags that fail to<br>
>>>> match a known tag. In html land its very common for some browsers to<br>
>>>> know some non-standard tags, which are new features in testing to be<br>
>>>> proposed or reworked into future standards. IE's policy of only adhering<br>
>>>> to the spec and including no experimental tag support has been seen be<br>
>>>> web designers as discouraging to any change. Why, because their is no<br>
>>>> way to publicly test new ideas.<br>
>>>><br>
>>>> So from the QGIS side, in order to comply we would need to reply with<br>
>>>> only allowed tags if a user requests WMS=1.3.0, we can reply with more<br>
>>>> stuff like GetPrint if they don't specify that version. Or perhaps we<br>
>>>> have to invent a 1.3.0+ variant specifically for when a user knows it's<br>
>>>> QGIS server.<br>
>>>><br>
>>>> Anyone more familiar with WMS that can shed more light on the best way<br>
>>>> to work around this issue and have both compliance and the ability to<br>
>>>> add extra features that have no standard equivalent yet.<br>
>>>><br>
>>>> My point still stands, that EU agencies with this concern should be<br>
>>>> funding compliance efforts, not removing funding for lack of compliance.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Alex<br>
>>>><br>
>>>> On 06/07/2014 12:23 PM, Andrea Peri wrote:<br>
>>>>> Hi,<br>
>>>>> I need to be more clear.<br>
>>>>> My english is tremendous.<br>
>>>>> :)<br>
>>>>><br>
>>>>> The Interoperability mean to have a small set of operation euals on<br>
>>> EVERY<br>
>>>>> Server WMS.<br>
>>>>><br>
>>>>> Equals mena same reqeust , same response.<br>
>>>>><br>
>>>>> So when a Cleit WMS send a Request of GetCapabilities, The response<br>
>>> should<br>
>>>>> be the same from QGIS-server or from GeoServer or From Mapserver.<br>
>>>>><br>
>>>>> The same response mean that every product use the same dialect the same<br>
>>>>> tags and so on.<br>
>>>>><br>
>>>>><br>
>>>>> The XSD OGC is the dictionary that every wms client and server should<br>
>>> use<br>
>>>>> to know the right language and tags.<br>
>>>>><br>
>>>>> When the QGIS_Server response to a request GetCapbility with an XML that<br>
>>>>> contains the GetPrint tags.<br>
>>>>> The client wms say "hey what is this ? It is not in the XSD OGC. This<br>
>>> mean<br>
>>>>> your response is wrong."<br>
>>>>><br>
>>>>> Of course there are some client wms that don0t do a validation of<br>
>>> response,<br>
>>>>> they HOPE that the response will be exactly as they exected.<br>
>>>>> If this is not true. They go in crash or other bad situation.<br>
>>>>><br>
>>>>> Again the resence of a Tag not compliant with XSD OGC will create<br>
>>>>> incompatibility.<br>
>>>>><br>
>>>>> Think to a client that will parse the xml response and say:<br>
>>>>><br>
>>>>> ok the GetLegendGraphics tag is passed now there is "this well know<br>
>>> tag".<br>
>>>>><br>
>>>>> Instead arrive a GetPrint tags.<br>
>>>>><br>
>>>>> The client wms become crazy.<br>
>>>>><br>
>>>>> Of course QGIS will understand it.<br>
>>>>> But this is because you (qgis group) manage it to work.<br>
>>>>><br>
>>>>> But other clients don't know that tag and so they are not able to<br>
>>> extract<br>
>>>>> all the information from Capabilities response.<br>
>>>>> This is a bad practice also because create artiiciosally an<br>
>>> incopatibility<br>
>>>>> with other products.<br>
>>>>> Instead Inspire ask for INteroperability from every product.<br>
>>>>><br>
>>>>> Interoperability don't mean use all the same unique product. (This is<br>
>>> the<br>
>>>>> microsoft philosophy)<br>
>>>>> Interoperability mean All the product must use the same little set of<br>
>>>>> command and the response at these command should be compatible<br>
>>>>> (interoperable) between all of them<br>
>>>>><br>
>>>>> Actulally this is not true for the response xml of qgis-server at a<br>
>>>>> getcapability request.<br>
>>>>><br>
>>>>> Hope to be better explain, now.<br>
>>>>><br>
>>>>> Andrea.<br>
>>>>><br>
>>>>><br>
>>>>> 2014-06-07 20:49 GMT+02:00 Andrea Peri <<a href="mailto:aperi2007@gmail.com">aperi2007@gmail.com</a>>:<br>
>>>>><br>
>>>>>> Hi Alex,<br>
>>>>>><br>
>>>>>> The question is not the print capability.<br>
>>>>>><br>
>>>>>> The question is to LOST THE INTEROPERABILITY<br>
>>>>>><br>
>>>>>> If qgis response an xml that is not OGC complaint it is not<br>
>>> interoperable<br>
>>>>>> with other product.<br>
>>>>>><br>
>>>>>> As example:<br>
>>>>>><br>
>>>>>> if an public Administration will eed to do a cascading wms with the<br>
>>> server<br>
>>>>>> wms of another public administration.<br>
>>>>>> The server before of all call for a GetCapability.<br>
>>>>>><br>
>>>>>> If the response has a tag proprietary. If fail.<br>
>>>>>> This need Not Interoperable.<br>
>>>>>><br>
>>>>>> I dont say do not do a getprint.<br>
>>>>>><br>
>>>>>> I say remove tha tag GetPrint from the GetCapabilities response.<br>
>>>>>> It is not a OGC tag and so that response is not interoperable as<br>
>>> requested<br>
>>>>>> from Inspire specification.<br>
>>>>>><br>
>>>>>> Regards,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 2014-06-07 20:36 GMT+02:00 Alex Mandel <<a href="mailto:tech_dev@wildintellect.com">tech_dev@wildintellect.com</a>>:<br>
>>>>>><br>
>>>>>> On 06/07/2014 11:19 AM, Andrea Peri wrote:<br>
>>>>>>>> Hi,<br>
>>>>>>>><br>
>>>>>>>> AFAIK the qgis server is not complaint with Inspire.<br>
>>>>>>>><br>
>>>>>>>> This beacausethe Response to GetCapabilities is not responding to the<br>
>>>>>>>> requisite that the OGC will require for it.<br>
>>>>>>>><br>
>>>>>>>> Originally the qgis was simply generate an incompatible response for<br>
>>> the<br>
>>>>>>>> XSD of OGC.<br>
>>>>>>>><br>
>>>>>>>> The response is ncompatible for thre thinks:<br>
>>>>>>>><br>
>>>>>>>> 1) the GetCapabilities is in the wrong namespace.<br>
>>>>>>>> This is a silly question anc could be easily resolved.<br>
>>>>>>>><br>
>>>>>>>> 2)<br>
>>>>>>>> The presence of the GetStyle that is dismissed from OGC wms 1.3.0.<br>
>>>>>>>> Please notice that the Inspire require the WMS 1.3.0 .<br>
>>>>>>>> To resolve this the QGIS groups has copied the XSD of OGC and<br>
>>> modifica<br>
>>>>>>> it<br>
>>>>>>>> to redirect to a different XSD not in the OGC site.<br>
>>>>>>>><br>
>>>>>>>> 3) The presence of a Proprietary tag inserted without any reference<br>
>>> to<br>
>>>>>>> any<br>
>>>>>>>> standard.<br>
>>>>>>>> The GetPrint.<br>
>>>>>>>> This is not present in any other product.<br>
>>>>>>>><br>
>>>>>>>> My question is for any person of a Public Administration that plan or<br>
>>>>>>> are<br>
>>>>>>>> funding QGIS.<br>
>>>>>>>><br>
>>>>>>>> In Europe the Inspire directive will ask to promove the<br>
>>>>>>> Interoperability.<br>
>>>>>>>><br>
>>>>>>>> The interoperability strategy ask that every produc that allow the<br>
>>>>>>> inspire<br>
>>>>>>>> directive will speak the same language using the same tags and<br>
>>>>>>>> functionality.<br>
>>>>>>>><br>
>>>>>>>> The QGIS solution to add a proprietary tag and to write a own<br>
>>> different<br>
>>>>>>> xsd<br>
>>>>>>>> that overlap the standard OGC xsd will create the presuppost (AFAIK)<br>
>>> to<br>
>>>>>>>> vilate the Inspire directive.<br>
>>>>>>>><br>
>>>>>>>> If this is true A Public Administration should not use the QGIS.<br>
>>>>>>>><br>
>>>>>>>> This is a realproblem for us that invest many fund on qgis.<br>
>>>>>>>><br>
>>>>>>>> So I like toknow the opinion of other public administration.<br>
>>>>>>>><br>
>>>>>>>> Before still fund a product that seem to violate the Inspire<br>
>>> directive<br>
>>>>>>>> principles.<br>
>>>>>>>><br>
>>>>>>>> Thx,<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>> To me the question is flipped. What needs to be funded, probably by EU<br>
>>>>>>> agencies to ensure INSPIRE compliance of QGIS Server?<br>
>>>>>>> It looks like you've put together the list of what needs to be fixed,<br>
>>> so<br>
>>>>>>> the target should be easier. I am little puzzled about not allowing<br>
>>> for<br>
>>>>>>> extra functions that are not in the standard. Unless the WMS has a<br>
>>> print<br>
>>>>>>> standard an extra print add-on doesn't break any expectations. Who<br>
>>>>>>> knows, maybe that should be submitted as an extension to WMS.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Note, this should have no effect on funding and usage of QGIS desktop.<br>
>>>>>>> Maybe Paolo has good numbers on if EU agencies are funding Server vs<br>
>>>>>>> Desktop features.<br>
>>>>>>><br>
>>>>>>> Thanks,<br>
>>>>>>> Alex<br>
>>>>>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Qgis-user mailing list<br>
>> <a href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
>><br>
><br>
</div></div>> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty àèìòù<br>-----------------<br>
</div>