The reserved words are still just tokens in the grammar: http://old.geotools.org/ECQL-Parser-Design_110493908.html
We already have some special cases to recognize odd patterns (and encode odd patterns) for ECQL constructs like "property IN (1,2,3)" which is mapped to filter "in(1,2,3) == TRUE" -- Jody Garnett On Tue, 30 Apr 2019 at 14:59, Niels Charlier <ni...@scitus.be> wrote: > I meant the CQL parser, including if you're parsing just an expression, > not an actual filter (CQL.toExpression). This method is called from the > AbstractStyleBuilder, app-schema and CSW. But indeed the function would > still work fine if you use filterfactory methods to build the expression > from scratch, and probably also with XML parsers. > > I think the CQL parser is automatically generated. I can't think of any > language that allows reserved words to be used for identifiers. This is > because reserved words are already detected and separated from identifiers > in the tokenizer stage. > On 30/04/2019 17:31, Andrea Aime wrote: > > On Tue, Apr 30, 2019 at 11:25 AM Niels Charlier <ni...@scitus.be> wrote: > >> Hello, >> >> I discovered that the implemented and documented filter function "not" >> doesn't actually work. >> > > In what context? See below > > >> >> The parser treats the word "not" as a reserved word, used for filters, >> therefore it does not manage to parse it as an identifier inside an >> expression. >> > > "The parser", but filter functions can be created via code directly, and > via multiple parsers. > I'm guessing you mean CQL, where indeed NOT is a reserved keyword? > Would it work if you create it by code, or create it as part of a OGC > Filter 1.0 for example? Or as part of SLD? > > >> Perhaps I am missing something, but otherwise the function should >> probably be renamed or removed? >> > > Or, if the problem is CQL specific, get the parser fixed so that it can > tell the difference between NOT and NOT(). > Does not sound easy, but I'd avoid removing functions, they can be used in > a variety of contexts (e.g., SLD). > Maybe just add an "alias" (a delegating function) that uses a different > name for usage in CQL, if modifying > the javacc parser looks too hard? > > Cheers > Andrea > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it 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.* > > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel