I just checked the WMS 1.3.0 specification document http://portal.opengeospatial.org/files/?artifact_id=14416
Extended optional features are allowed. There is a specific way to include them. See section 6.9.5 "Extended capabilities and operations" <_ExtendedCapabilities> or <_ExtendedOperations> So perhaps we just need to wrap those extra options in a specific tag for them to pass schema testing. Thanks, Alex On 06/07/2014 12:35 PM, Alex Mandel wrote: > I understand the issue now. In order to be WMS 1.3 complaint you can > only use what's in the spec. > > Looking at an analogy with html specs I find this limitation appalling > short-sighted. It means there can be no innovation testing new features > with the spec unless you manage to get it into the future spec. I find > it hard to comprehend that clients don't just skip tags that fail to > match a known tag. In html land its very common for some browsers to > know some non-standard tags, which are new features in testing to be > proposed or reworked into future standards. IE's policy of only adhering > to the spec and including no experimental tag support has been seen be > web designers as discouraging to any change. Why, because their is no > way to publicly test new ideas. > > So from the QGIS side, in order to comply we would need to reply with > only allowed tags if a user requests WMS=1.3.0, we can reply with more > stuff like GetPrint if they don't specify that version. Or perhaps we > have to invent a 1.3.0+ variant specifically for when a user knows it's > QGIS server. > > Anyone more familiar with WMS that can shed more light on the best way > to work around this issue and have both compliance and the ability to > add extra features that have no standard equivalent yet. > > My point still stands, that EU agencies with this concern should be > funding compliance efforts, not removing funding for lack of compliance. > > Thanks, > Alex > > On 06/07/2014 12:23 PM, Andrea Peri wrote: >> Hi, >> I need to be more clear. >> My english is tremendous. >> :) >> >> The Interoperability mean to have a small set of operation euals on EVERY >> Server WMS. >> >> Equals mena same reqeust , same response. >> >> So when a Cleit WMS send a Request of GetCapabilities, The response should >> be the same from QGIS-server or from GeoServer or From Mapserver. >> >> The same response mean that every product use the same dialect the same >> tags and so on. >> >> >> The XSD OGC is the dictionary that every wms client and server should use >> to know the right language and tags. >> >> When the QGIS_Server response to a request GetCapbility with an XML that >> contains the GetPrint tags. >> The client wms say "hey what is this ? It is not in the XSD OGC. This mean >> your response is wrong." >> >> Of course there are some client wms that don0t do a validation of response, >> they HOPE that the response will be exactly as they exected. >> If this is not true. They go in crash or other bad situation. >> >> Again the resence of a Tag not compliant with XSD OGC will create >> incompatibility. >> >> Think to a client that will parse the xml response and say: >> >> ok the GetLegendGraphics tag is passed now there is "this well know tag". >> >> Instead arrive a GetPrint tags. >> >> The client wms become crazy. >> >> Of course QGIS will understand it. >> But this is because you (qgis group) manage it to work. >> >> But other clients don't know that tag and so they are not able to extract >> all the information from Capabilities response. >> This is a bad practice also because create artiiciosally an incopatibility >> with other products. >> Instead Inspire ask for INteroperability from every product. >> >> Interoperability don't mean use all the same unique product. (This is the >> microsoft philosophy) >> Interoperability mean All the product must use the same little set of >> command and the response at these command should be compatible >> (interoperable) between all of them >> >> Actulally this is not true for the response xml of qgis-server at a >> getcapability request. >> >> Hope to be better explain, now. >> >> Andrea. >> >> >> 2014-06-07 20:49 GMT+02:00 Andrea Peri <[email protected]>: >> >>> Hi Alex, >>> >>> The question is not the print capability. >>> >>> The question is to LOST THE INTEROPERABILITY >>> >>> If qgis response an xml that is not OGC complaint it is not interoperable >>> with other product. >>> >>> As example: >>> >>> if an public Administration will eed to do a cascading wms with the server >>> wms of another public administration. >>> The server before of all call for a GetCapability. >>> >>> If the response has a tag proprietary. If fail. >>> This need Not Interoperable. >>> >>> I dont say do not do a getprint. >>> >>> I say remove tha tag GetPrint from the GetCapabilities response. >>> It is not a OGC tag and so that response is not interoperable as requested >>> from Inspire specification. >>> >>> Regards, >>> >>> >>> >>> 2014-06-07 20:36 GMT+02:00 Alex Mandel <[email protected]>: >>> >>> On 06/07/2014 11:19 AM, Andrea Peri wrote: >>>>> Hi, >>>>> >>>>> AFAIK the qgis server is not complaint with Inspire. >>>>> >>>>> This beacausethe Response to GetCapabilities is not responding to the >>>>> requisite that the OGC will require for it. >>>>> >>>>> Originally the qgis was simply generate an incompatible response for the >>>>> XSD of OGC. >>>>> >>>>> The response is ncompatible for thre thinks: >>>>> >>>>> 1) the GetCapabilities is in the wrong namespace. >>>>> This is a silly question anc could be easily resolved. >>>>> >>>>> 2) >>>>> The presence of the GetStyle that is dismissed from OGC wms 1.3.0. >>>>> Please notice that the Inspire require the WMS 1.3.0 . >>>>> To resolve this the QGIS groups has copied the XSD of OGC and modifica >>>> it >>>>> to redirect to a different XSD not in the OGC site. >>>>> >>>>> 3) The presence of a Proprietary tag inserted without any reference to >>>> any >>>>> standard. >>>>> The GetPrint. >>>>> This is not present in any other product. >>>>> >>>>> My question is for any person of a Public Administration that plan or >>>> are >>>>> funding QGIS. >>>>> >>>>> In Europe the Inspire directive will ask to promove the >>>> Interoperability. >>>>> >>>>> The interoperability strategy ask that every produc that allow the >>>> inspire >>>>> directive will speak the same language using the same tags and >>>>> functionality. >>>>> >>>>> The QGIS solution to add a proprietary tag and to write a own different >>>> xsd >>>>> that overlap the standard OGC xsd will create the presuppost (AFAIK) to >>>>> vilate the Inspire directive. >>>>> >>>>> If this is true A Public Administration should not use the QGIS. >>>>> >>>>> This is a realproblem for us that invest many fund on qgis. >>>>> >>>>> So I like toknow the opinion of other public administration. >>>>> >>>>> Before still fund a product that seem to violate the Inspire directive >>>>> principles. >>>>> >>>>> Thx, >>>>> >>>>> >>>> >>>> To me the question is flipped. What needs to be funded, probably by EU >>>> agencies to ensure INSPIRE compliance of QGIS Server? >>>> It looks like you've put together the list of what needs to be fixed, so >>>> the target should be easier. I am little puzzled about not allowing for >>>> extra functions that are not in the standard. Unless the WMS has a print >>>> standard an extra print add-on doesn't break any expectations. Who >>>> knows, maybe that should be submitted as an extension to WMS. >>>> >>>> >>>> Note, this should have no effect on funding and usage of QGIS desktop. >>>> Maybe Paolo has good numbers on if EU agencies are funding Server vs >>>> Desktop features. >>>> >>>> Thanks, >>>> Alex >>>> _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
