Part 3, "CQL2 functions"... only for CQL2?

[aaime]

Given that the definition of the functions resource is in the filtering part of the standard, and that functions are a general construct that could be re-used in other filtering languages, should it have its own conformance class in Part 3, rather than referring to the specifics of CQL2 language?

E.g. Filter encoding also supports functions and the functions endpoint would be useful for it as well.

[m-mohr]

Looks like OGC is reinventing the wheel here. The functions look pretty similar to openEO's pre-defined processes and the CQL2 seems to evolve into yet another processing language such as openEO's process definition (process graph).

CQL2 is a "query language" as such it should be restricted to querying with a common set of operators that are useful for querys. These are defined in conformance classes, as such functions are not needed. Functions seem out of scope and should be left to specific processing languages.

[jerstlouis]

@m-mohr What I proposed befpre is a registry of well-known functions / processes (a function is pretty much the same as a process since it returns an output for a given set of inputs).

This would be separate from the functions that a particular deployment / implementation makes available (and lists at /functions) but there could be a way to identify that these functions (possibly with the same name) corresponds to a particular well-known process / function.

[m-mohr]

Yes, exactly, that's what I'm saying. You are reinventing the wheel by setting up your own functions and registry. All this is available in openEO, why reinvent the wheel?

[aaime]

Extensible functions have been part of OGC Filter since its inception, CQL2 is just supporting what has been available since WFS 1.0, I believe.

[m-mohr]

@aaime Is there a list of functions or can anyone just define their own functions, which leads to no interoperability between implementations? If there's a list of pre-defined functions, could you point me towards where these functions are defined, please? Thank you.

[aaime]

I agree that having a list of well-known functions is better and allows for interoperability. There has never been any such list in OGC Filter. However, please read the title and description of the issue, it has nothing to do with pre-defined functions, it's just about not limiting the list of functions exposed by Part 3 to CQL2.

Well known functions is a worthy goal, and not in contrast with exposing a list of functions. It just seems worth its own separate ticket.

[pvretano]

CQL2 is meant to be a generic predicate language that can be used in a number of contexts (e.g. for feature filtering features or for band-math expressions in coverages). As such, in relation to extension functions, we provide hooks in the language for extensibility but we don't define the set of extension functions since the set of extension function relevant to one community of interest may mean nothing to another.

@aaime I would expect communities of interest to define their list of functions as one or more conformance classes that can be advertised in the server's conformance declaration thus letting clients know that extension function set "X" is implemented on a particular server while extension function set "Y" is not. I expect these sets of extension function documents to be defined as separate standards and not necessarily be part of CQL2. As I said, CQL2 just provides the hooks ... not the specific extension functions. If it turns out that some particular extension function is generally useful then the SWG can consider promoting it to be part of the CQL2 language.

So yes, @m-mohr, you can define your own functions if you like so the set of openEO functions, I suppose, could be added to CQL2 as a set of extension functions with a conformance class URI that can be advertised in the server's conformance declaration.

The fact that openEO has similar capablities is neither here nor there. Parallel efforts and great minds think alike I guess. However, as @aaime pointed out, functions have been part of Filter since almost the begining (20+ years I guess) and CQL2 is simply trying to cover similar ground. Like CQL2, Filter did not define which "extension" functions to add either.

[jerstlouis]

@m-mohr We might need a new issue for the Well-known Processes, but it was a recommendation in the Executive Summary for Testbed 17 GDC. It was also in the description of opengeospatial/ogcapi-processes#47 for Part 3, also mentioned here in this repo #705 (however it was clarified that things like DATE, TIMESTAMP, POINT, POLYGON are not well-known functions but instance constructors).

The idea of a well-known functions would be that you can register them in a new OGC Defnition Server register and you could identify a function provided by the implementation as corresponding to a particular to a well-known function by specifying that URI in a property.

[cportele]

Meeting 2024-11-18:

• We agreed, it would be appropriate as a separate requirements class and it can document functions in any language. However, since Part 3 has just been published, this can only happen in a future version 1.1.
• Regarding the side discussion: Functions are the extension point for CQL2 and it has been like that from the beginning. It is a key concept of the language.