Yes also this is possible, but pay attention to use it correctly. I guess it is no really simple to use (ie to define the extension).
In the SLD world this was allowed and a unfortunately and worst understanding of it will born a lot of incompatible dialects. Also in the metadata world (iso19115) the possibility to extend the specs will produce incompatibility monster. :) I guess surely better and easy is put the new functions in in a distinct and new kind of request. Andrea. 2014-06-07 21:56 GMT+02:00 Alex Mandel <[email protected]>: > 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 > >>>> > > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù -----------------
_______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
