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

Reply via email to