Add more example expression objects

[fmigneault]

I think that (at least) 3 common definitions should be provided for https://github.com/stac-extensions/processing#expression-object to better guide users.

• a generic "python script entry points" similar to what setup(entry_point=...) or poetry.scripts expect (e.g.: my_package.my_module:some_function or my_package.my_module:SomeClass.a_method)

• a URI based reference to a script or executable (somewhat relates to #29 about the href requirement) (for this, I would suggest that "expression": {"href": "<uri>", "type"; "<media-type>"} is used, since expression allows anything)

• some docker container or similar, using an expression like ghcr.io/NAMESPACE/IMAGE_NAME:latest (or a more explicit docker run call)

[emmanuelmathot]

The processing extension initially aims at tracing the processing lineage of the item. I understand you want to specify possible processing on the item? The expression object is left free to add any data structure that would represent the processing applied. If you want to provide with more processing format and related convention, feel free to provide them with examples.

[fmigneault]

I agree. If the above suggestions are valid, I can open a PR to add the examples. Users are always free to define whichever format that suits their needs, but if we push them toward a common strategy with good examples, it can help "standardizing" some work later on.

Also related, once the Machine Learning Model (MLM) extension will be released, I plan to suggest another example similar to the following for STAC Items representing a derived product resulting from model predictions (eg: land-cover).

{
  "processing:level": "L4",
  "processing:expression": {
    "format": "stac-mlm",
    "expression": {
      "href": "<URI-to-MLM-STAC-Item>",
      "type": "application/geo+json"
    }
  }
}

As described in https://github.com/crim-ca/dlm-extension/blob/validate/best-practices.md#processing-extension