<div dir="ltr"><div><div><div><div>Yes also this is possible,<br></div>but pay attention to use it correctly.<br></div>I guess it is no really simple to use (ie to define the extension).<br></div><div><br></div><div>In the SLD world this was allowed and a unfortunately and worst understanding of it will born a lot of incompatible dialects.<br>
</div><div>Also in the metadata world (iso19115) the possibility to extend the specs will produce incompatibility monster.<br>:)<br><br></div>I guess surely better and easy is put the new functions in in a distinct and new kind of request.<br>
<br></div>Andrea.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-07 21:56 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">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>
<div class="HOEnZb"><div class="h5"><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 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 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 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 mean<br>
>> your response is wrong."<br>
>><br>
>> Of course there are some client wms that don0t do a validation of 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 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 extract<br>
>> all the information from Capabilities response.<br>
>> This is a bad practice also because create artiiciosally an 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 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 interoperable<br>
>>> with other product.<br>
>>><br>
>>> As example:<br>
>>><br>
>>> if an public Administration will eed to do a cascading wms with the 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 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 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 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 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 different<br>
>>>> xsd<br>
>>>>> that overlap the standard OGC xsd will create the presuppost (AFAIK) 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 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, so<br>
>>>> the target should be easier. I am little puzzled about not allowing for<br>
>>>> extra functions that are not in the standard. Unless the WMS has a 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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty àèìòù<br>-----------------<br>
</div>