Hi Andre and Nuno, Thanks a lot for your feedback.
Indeed reducing the verbosity of the tag names will help a lot. Nuno's example format looks nice: <PS><P n="mmsi">538008302,244060802,538008505</P><P n="mmsi">22,44</P></PS>, <PS><P n="csvInput">acv,rrp;1,0;0,7;22,1</P></PS> Also I agree positional layer parameters should be respected, in case of no parameters for a layer we should just add an empty tag on the layer position: <PS/> Regards, Fernando Mino == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Fernando Mino Software Engineer @fmy2kec GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail. On Tue, Jul 5, 2022 at 7:26 AM Nuno Oliveira < nuno.olive...@geosolutionsgroup.com> wrote: > Hi Andrea, > thank you for the feedback, find my replies below: > > On Mon, Jul 4, 2022 at 5:25 PM Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> Hi all, >> I can understand the desire to use a more structured format rather than >> fiddling with escape codes when dealing with >> complex view params. At the same time, there is a practical limit... >> let's look at content and size of your example: >> >> <Layer name="Layer1"><Parameter name="mmsi">538008302, >> 244060802,538008505</Parameter></Layer><Layer name="Layer3"><Parameter >> name="mmsi">22,44</Parameter></Layer><Layer name="Layer6"><Parameter >> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >> >> The XML most often cited downside is verbosity, and the above is already >> 250 chars. URLs have a practical size limit of 2000 chars >> <https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers>, >> adding a few more params in there (or other request parameters) and you'll >> quickly get to the maximum... at which point you can still do the request, >> but it's going to have to switch to a POST request with form-url-encoded >> body. >> > > Right, I guess for complex use cases switch to POST encoding will need to > be done anyway, that say, we could shorten a bit the syntax: > <L n="Layer1"><P n="mmsi">538008302,244060802,538008505</P></L><L > name="Layer3"><Parameter name="mmsi">22,44</P></L><L name="Layer6"><P > name="csvInput">acv,rrp;1,0;0,7;22,1</P></L> > > From 250 to 180. > > >> >> Also, the idea of naming layers is at odds with OGC protocols: everything >> in a GetMap request is positionals, each multi-value parameter is an array >> of values (layers, styles, filters and so on) where the values are >> corresponding by position. Having one parameter breaking the well >> established pattern is weird, not to mention, you'll have to maintain the >> positional approach for the current format. >> > > Right, I didn't think about the storage Java side, I guess relying on the > order will help reduce the size even more: > > <PS><P n="mmsi">538008302,244060802,538008505</P><P > n="mmsi">22,44</P></PS>, <PS><P n="csvInput">acv,rrp;1,0;0,7;22,1</P></PS> > > Down to 126 chars. > > Kind regards, > Nuno Oliveira > > >> >> Cheers >> Andrea >> >> On Mon, Jul 4, 2022 at 5:20 PM Fernando Mino < >> fernando.m...@geosolutionsgroup.com> wrote: >> >>> Hi Nuno, thanks a lot for your feedback, replying to your inputs: >>> >>> >>> Proposed XML alternative format: >>>>> The XML alternative format will include the following tags: >>>>> - <Layer> : defines a layer parameters, using the same layers order as >>>>> the regular view parameters format. >>>>> >>>> >>>> -1 here, I would recommend not relying on the order, but instead tying >>>> a parameter to a layer based on an XML tag, for example: >>>> >>>> <Layer name="layer1"><Parameter name="mmsi">22,44</Parameter></Layer> >>>> >>> >>> Indeed having explicit layer name makes sense, since we can have layers >>> without parameters and using the name as identification we can set only the >>> ones we want. The updated example: >>> >>> &viewParams=<Layer name="Layer1"><Parameter >>> name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer >>> name="Layer3"><Parameter name="mmsi">22,44</Parameter></Layer><Layer >>> name="Layer6"><Parameter >>> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >>> >>> >>>> >>>> - <Parameter> : To be included inside the <Layer> element. Defines a >>>>> parameter on its nested element value, setting its parameter name using >>>>> the >>>>> "name" attribute. >>>>> >>>>> Example: >>>>> &viewParams=<Layer><Parameter >>>>> name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer><Parameter >>>>> name="mmsi">22,44</Parameter></Layer><Layer><Parameter >>>>> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >>>>> >>>> >>>> I'm assuming that the values will then be used as-is in the downstream >>>> SQL query? In terms of XML encoding, this will follow a similar path to >>>> other XML parameters currently support in GeoServer? We will be able to >>>> escape reserved characters, the XML prefix and namespace will be optional? >>>> >>> >>> >>> - Yes the values will be used in the internal SQL query parameters. >>> - Yes we will use the same approach as already existing Filter KVP >>> parsers, layers parsers. >>> - We will use the same escape strategy as current view parameters >>> implementation for all the values. >>> - Yes, the XML prefix and namespace are optional. >>> >>> >>> >>>> >>>>> >>>>> Current format support and backward compatibility: >>>>> The new alternative format will be only activated when a well formed >>>>> XML including the Layer and Parameter tags are provided as value for the >>>>> viewParams URL parameter in the request. >>>>> If this condition criteria is not accomplished, the regular view >>>>> parameter format will be used, respecting backward compatibility and >>>>> regular use cases. >>>>> >>>> >>>> I would suggest adding a new parameter, *viewParamsFormat* to define >>>> the view parameters format explicitly, looks to me like it will be more >>>> efficient than trying each time to parsing n XML The parameter would be >>>> optional, and if not provided the default URL encoding would be used. >>>> >>>> >>> >>> This makes sense and is indeed more efficient. I will add it to the >>> plan making the *viewParamsFormat *parameter optional using the regular >>> view params format as the default (allowing backward compatibility). >>> Example to activate the XML parsing: >>> &viewParamsFormat=xml >>> >>> Regards, >>> >>> Fernando Mino >>> >>> == >>> >>> GeoServer Professional Services from the experts! >>> >>> Visit http://bit.ly/gs-services-us for more information. >>> >>> == >>> >>> Fernando Mino >>> >>> Software Engineer >>> >>> @fmy2kec >>> >>> GeoSolutions Group >>> phone: +39 0584 962313 >>> >>> fax: +39 0584 1660272 >>> >>> https://www.geosolutionsgroup.com/ >>> >>> http://twitter.com/geosolutions_it >>> >>> ------------------------------------------------------- >>> >>> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >>> precisa che ogni circostanza inerente alla presente email (il suo >>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >>> >>> This email is intended only for the person or entity to which it is >>> addressed and may contain information that is privileged, confidential or >>> otherwise protected from disclosure. We remind that - as provided by >>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >>> e-mail or the information herein by anyone other than the intended >>> recipient is prohibited. If you have received this email by mistake, please >>> notify us immediately by telephone or e-mail. >>> >>> >>> On Mon, Jul 4, 2022 at 4:57 AM Nuno Oliveira < >>> nuno.olive...@geosolutionsgroup.com> wrote: >>> >>>> Hi Fernando, >>>> overall looks like a good addition, but I have a couple of comments, >>>> please see them below: >>>> >>>> On Fri, Jul 1, 2022 at 10:13 PM Fernando Mino < >>>> fernando.m...@geosolutionsgroup.com> wrote: >>>> >>>>> Dear community, >>>>> >>>>> This is an idea proposal to enhance GeoServer view parameters to allow >>>>> an XML format with more complex values definitions without the limit on >>>>> not >>>>> using reserved characters as the current plain format. >>>>> >>>> >>>>> Current GeoServer view params documentation: >>>>> >>>>> https://docs.geoserver.org/master/en/user/data/database/sqlview.html#using-a-parametric-sql-view >>>>> >>>>> Motivation: >>>>> To have the ability of sending complex values into view parameters, >>>>> like comma separated sublists, semicolon and comma separated inner >>>>> sub-parameters, CSV sets, JSON/XML, etc. >>>>> >>>> >>>> Right, JSON support in RDBS is becoming more and more efficient, and I >>>> can see this being handy to pass down complex JSON expressions. >>>> >>>> >>>>> >>>>> Proposed XML alternative format: >>>>> The XML alternative format will include the following tags: >>>>> - <Layer> : defines a layer parameters, using the same layers order as >>>>> the regular view parameters format. >>>>> >>>> >>>> -1 here, I would recommend not relying on the order, but instead tying >>>> a parameter to a layer based on an XML tag, for example: >>>> >>>> <Layer name="layer1"><Parameter name="mmsi">22,44</Parameter></Layer> >>>> >>>> >>>>> - <Parameter> : To be included inside the <Layer> element. Defines a >>>>> parameter on its nested element value, setting its parameter name using >>>>> the >>>>> "name" attribute. >>>>> >>>>> Example: >>>>> &viewParams=<Layer><Parameter >>>>> name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer><Parameter >>>>> name="mmsi">22,44</Parameter></Layer><Layer><Parameter >>>>> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >>>>> >>>> >>>> I'm assuming that the values will then be used as-is in the downstream >>>> SQL query? In terms of XML encoding, this will follow a similar path to >>>> other XML parameters currently support in GeoServer? We will be able to >>>> escape reserved characters, the XML prefix and namespace will be optional? >>>> >>>> >>>>> >>>>> >>>>> Current format support and backward compatibility: >>>>> The new alternative format will be only activated when a well formed >>>>> XML including the Layer and Parameter tags are provided as value for the >>>>> viewParams URL parameter in the request. >>>>> If this condition criteria is not accomplished, the regular view >>>>> parameter format will be used, respecting backward compatibility and >>>>> regular use cases. >>>>> >>>> >>>> I would suggest adding a new parameter, *viewParamsFormat* to define >>>> the view parameters format explicitly, looks to me like it will be more >>>> efficient than trying each time to parsing n XML The parameter would be >>>> optional, and if not provided the default URL encoding would be used. >>>> >>>> >>>>> >>>>> Implementation hints: >>>>> Before writing the complete plan/proposal I would like to know the >>>>> community feedback about this enhancement idea, but summarizing we should >>>>> have: >>>>> - New KVP parser implementation for XML formatted view parameters. >>>>> - New tests checking this new implementation and checking backward >>>>> compatibility. >>>>> - A new section on GeoServer documentation covering this new format. >>>>> >>>>> Naturally, any feedback to this enhancement is welcome. Thanks!!! >>>>> >>>>> Regards, >>>>> >>>>> Fernando Mino >>>>> >>>>> == >>>>> >>>>> GeoServer Professional Services from the experts! >>>>> >>>>> Visit http://bit.ly/gs-services-us for more information. >>>>> >>>>> == >>>>> >>>>> Fernando Mino >>>>> >>>>> Software Engineer >>>>> >>>>> @fmy2kec >>>>> >>>>> GeoSolutions Group >>>>> phone: +39 0584 962313 >>>>> >>>>> fax: +39 0584 1660272 >>>>> >>>>> https://www.geosolutionsgroup.com/ >>>>> >>>>> http://twitter.com/geosolutions_it >>>>> >>>>> ------------------------------------------------------- >>>>> >>>>> Con riferimento alla normativa sul trattamento dei dati personali >>>>> (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati >>>>> “GDPR”), >>>>> si precisa che ogni circostanza inerente alla presente email (il suo >>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >>>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >>>>> >>>>> This email is intended only for the person or entity to which it is >>>>> addressed and may contain information that is privileged, confidential or >>>>> otherwise protected from disclosure. We remind that - as provided by >>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of >>>>> this >>>>> e-mail or the information herein by anyone other than the intended >>>>> recipient is prohibited. If you have received this email by mistake, >>>>> please >>>>> notify us immediately by telephone or e-mail. >>>>> _______________________________________________ >>>>> Geoserver-devel mailing list >>>>> Geoserver-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>> >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Nuno Oliveira >>>> >>>> == >>>> GeoServer Professional Services from the experts! >>>> >>>> Visit http://bit.ly/gs-services-us for more information. >>>> == >>>> >>>> Nuno Miguel Carvalho Oliveira >>>> @nmcoliveira >>>> Technical Lead / Project Manager >>>> >>>> >>>> GeoSolutions Group >>>> phone: +39 0584 962313 >>>> fax: +39 0584 1660272 >>>> >>>> https://www.geosolutionsgroup.com/ >>>> http://twitter.com/geosolutions_it >>>> ------------------------------------------------------- >>>> >>>> >>>> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >>>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >>>> precisa che ogni circostanza inerente alla presente email (il suo >>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >>>> >>>> This email is intended only for the person or entity to which it is >>>> addressed and may contain information that is privileged, confidential or >>>> otherwise protected from disclosure. We remind that - as provided by >>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >>>> e-mail or the information herein by anyone other than the intended >>>> recipient is prohibited. If you have received this email by mistake, please >>>> notify us immediately by telephone or e-mail. >>>> >>> _______________________________________________ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> >> >> -- >> >> Regards, >> >> Andrea Aime >> >> == >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> == >> >> Ing. Andrea Aime >> @geowolf >> Technical Lead >> >> GeoSolutions Group >> phone: +39 0584 962313 >> >> fax: +39 0584 1660272 >> >> mob: +39 333 8128928 >> >> https://www.geosolutionsgroup.com/ >> >> http://twitter.com/geosolutions_it >> >> ------------------------------------------------------- >> >> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >> precisa che ogni circostanza inerente alla presente email (il suo >> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >> >> This email is intended only for the person or entity to which it is >> addressed and may contain information that is privileged, confidential or >> otherwise protected from disclosure. We remind that - as provided by >> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >> e-mail or the information herein by anyone other than the intended >> recipient is prohibited. If you have received this email by mistake, please >> notify us immediately by telephone or e-mail >> > > > -- > > Regards, > > Nuno Oliveira > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Nuno Miguel Carvalho Oliveira > @nmcoliveira > Technical Lead / Project Manager > > > GeoSolutions Group > phone: +39 0584 962313 > fax: +39 0584 1660272 > > https://www.geosolutionsgroup.com/ > http://twitter.com/geosolutions_it > ------------------------------------------------------- > > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail. >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
