/functions: Adding a well-known function URI for identification

[jerstlouis]

As suggested in #964 (comment)

It was a recommendation in the Executive Summary for Testbed 17 GDC to define a concept of Well-known function / process register. 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.

This well-known function URI could be an optional property of a function description in the /functions end-point.

[cportele]

Meeting 2024-11-18: We agree in principle, but it is unclear what makes the URI "well-known" and what one gets back when the URIs are resolved. This needs more thoughts and discussion.

[m-mohr]

I never realized custom functions are allowed in CQL2, it seems I missed that when reading the spec. Maybe it's too late to post this, but I'll still do it for awareness. As already mentioned in #694, I don't think it's a good idea to make CQL2 extensible by server-specific functions. Those functions should only be defined by OGC via conformance classes and then you don't need /functions. Having server-specific functions breaks the whole interoperability of CQL2. In the end OGC ends up with multiple processing languages, CQL2 and MOAW at least (even ignoring openEO for now). But why does OGC need two langauges that do very similar things?

[jerstlouis]

@m-mohr

As already mentioned in #694, I don't think it's a good idea to make CQL2 extensible by server-specific functions.

You probably meant #964. CQL2 is now an approved/published and is extensible by server-specific functions.

Having server-specific functions breaks the whole interoperability of CQL2.

Indeed a CQL2 expression using custom-functions will not work as-is on multiple servers implementing different functions, or naming the same functions differently. The well-known function URI proposed here at least addresses the possibility that a client recognizing functions by URI can compose a CQL2 expression using functions it recognizes to have a particular semantic and expected inputs/outputs by URI.

The concept of well-known functions/processes would work for identifying both CQL2 functions (/functions) as well as for identifying processes (/processes).

The nested processes concept of Processes - Part 3 ("MOAW") extends OGC API - Processes with the ability of the input to a process to be the output of another process. The input/output field modifiers defined in Part 3 allows to use CQL2 to modify the inputs/outputs of processes inside a workflow definition, allowing the two to work together.

It's essentially a choice of implementations to decide whether to present something as a "process" (that can be chained in process graph trees of execution requests/workflow definition) or a "function" (that can be chained in function call expressions), but conceptually a function is the same as a process: it takes inputs and return an output. Functions are simpler to express in filtering expressions and raster expressions, whereas processes can potentially represent more complex things like deployed processes in containers.

[cportele]

Having server-specific functions breaks the whole interoperability of CQL2.

No. Based on the conformance classes, clients can determine the standardized functions they can use.

If a server supports additional custom functions, clients may use those, too. I expect that most general clients will only use the standardized functions.

If a community of interest specifies additional functions, clients supporting that community will likely also support those functions, if a server supports those.

Additional functions that turn out to be useful to many could then be candidates for standardization in a future version of CQL2 in additional requirements classes.

[aaime]

Based on my experience with GeoServer, the number one use case for custom functions is styling, which is an avid user of both filters and expressions. They are used not only to pick the right features to render, but also for calculation, inline logical expressions, formatting, and geometry replacement.

SE 1.1 had introduced a few well-known functions, Recode, Categorize, Interpolate, and over the past 20 years, GeoServer has accumulated a number of functions that are mostly dedicated to styling.

Other cases where functions have been used beyond styles, are processing of JSON data structures (JSON/JSONB columns in PostgreSQL for example), where a JSON pointer or JSON path can be used to drill into a complex JSON to either extract a particular property value or check a condition. In this incarnation, we have been using them also for WFS filtering, or to support templated outputs (e.g. transforming a flat database table or a relational model into a JSON-LD output).

[m-mohr]

It breaks interoperability because the functions are not standardized and you can't use them on other backends.

If a community of interest specifies additional functions

In this case the community should define these functions commonly and defined a conformance class. The same applies for Styling and JSON.