Deprecate processing:expression in favor of this extension?

[m-mohr]

This seems generally the better place, but on the other hand processing:expression allows embedding some cases where this requires linking.

See also https://github.com/stac-extensions/processing#expression-object and stac-extensions/processing#31

[fmigneault]

I am against the deprecation.
Without processing:expression, the extension looses most of in meaning. I think the other fields (processing:lineage, processing:version, processing:datetime, etc.) are not the most commonly used fields. They are optional metadata that supplement the expression for more context. By themselves (without an expression), they don't mean much.

The processing:expression is used by STAC MLM in multiple ways, notably:

1. It can be employed in another derived product STAC Item to refer back to the STAC MLM Item, such as to provide a reference to which AI model generated the derived product (https://github.com/stac-extensions/mlm/blob/main/best-practices.md#processing-extension). In that sense, the reference is not really an "application", but a complex combination of runtime scripts, datasets and model invocation. The processing:expression combined with processing:level = L4 (Model output or results...) are much more representative of this than a plain script or application.

2. The Model Inputs and Model Outputs can embedded a structure based on the processing:expression schema (see https://github.com/stac-extensions/mlm/blob/main/README.md#processing-expression), can also reuse it on a per-bands/cube:variables-like definitions of the model inputs/outputs (https://github.com/stac-extensions/mlm/blob/main/README.md#model-band-or-variable-object), and also within Value Scaling Object definitions to provide further pre/post-processing operations. These variants offer flexibility since running an AI on a data product varies a lot on case-by-case basis. A key element is that these definitions may themselves inform how to prepare input/derived STAC Items. There is not a pre-made "application" to do this, since the processing requires per-model consideration depending on the employed datasets. The derived STAC Items can then inform users how the model produced the data, an how to run a given processing:expression to make it consumable by other GIS applications.

I think the 2 extensions (application and processing) definitely share certain concepts (e.g., which coding language is the application/processing implemented with? and how to run them?), but they can also represent and fulfill vastly different operations.

For example, pointing at an application script doesn't communicate a normalization operation like
{"format": "gdal-calc", "expression": "( A * min(A) ) / ( max(A) - min(A) )" } does. While a generic GDAL, CQL2, or other expression is not necessarily "executable" directly, it can communicate fairly verbosely the intent of what should be happening.

I don't think processing:expression and application:... are mutually exclusive either. In STAC MLM, we actually defined Source Code Asset and Container Asset to provide scripts in a similar fashion to what application does (would make sense to actually update and reuse application extension more adequately for this). However, it makes sense to provide a processing:expression (in the format specified in stac-extensions/processing#31) pointing to a given application:... Asset when it is employed in a specific per-band/variable operation, since there could be many scripts included in the STAC Item, and how/when to use them can be messy. They work best when combined.