CQL: give CASEI and ACCENTI distinct conformance classes

[aaime]

In the current standard, it seems one cannot implement only CASEI and advertise the "http://www.opengis.net/spec/cql2/1.0/req/case-insensitive-comparison", as that seems to include also the ACCENTI function.

I find this setup onerous from the implementation point of view, while case insensitive comparisons are easily implemented in most data sources, and are already implemented by anyone that dealt with Filter Encoding, accent insensitive requires an ad-hoc setup in the data source, and sometimes even language-specific, e.g., see:
https://www.postgresql.org/docs/12/collation.html

May I suggest giving the two functions separate conformance classes?

[pvretano]

@aaime we already considered that and decided to put them in one conformance class (see #641 (comment)). The issue does leave room for reconsidering and I can see your point too so I guess we will revisit the issue at the next SWG meeting. Personally I'm agnostic about the issue ... either way works for me.

[aaime]

@pvretano say one is trying to do a OGC API Features that proxies a WFS 2.0. I believe case insensitive could be cascaded, but one cannot cascade accent insensitive filters. So either one declare it can do neither, or will do both, but the accent insensitive filters will have to be processed locally, after fetching data, rather than cascading it.

Does not seem ideal to me :-)

[cportele]

Meeting 2022-02-14: Clemens agrees with @aaime after updating his implementation to CQL2 and ACCENTI will only work with some backends. We also agreed to Andrea's reasoning. We agreed to change our previous decision and create separate conformance classes. @cportele will create a PR together with the work on the abstract test suite.