Add federation prop to JsonSchema component?

[christophfriedrich]

The federation:backend spec explicitly says that this key "can also be embedded deeply into a hierarchical structure, e.g. for process or file format parameters." So when setting up a test case for displaying it in a ProcessParameterModal, I put it very deeply: On a parameter of a reducer.

Displaying in the ProcessParameterModal worked well. But in a ProcessModal, i.e. with more stuff around it, the federation object gets lost:

The ProcessParameter with key "reducer" still knows it, as it is a direct child of the Process, which passes it on. But the JsonSchema below doesn't have that prop anymore, so can't pass it on to the next ProcessParameter.

Only then I realised that I had added it to a schema property and I'm not sure whether that is legal? So that's the first question. See below for the process JSON (it's the aggregate_spatial from https://openeocloud.vito.be/openeo/1.0.0/processes with the added federation:backends line).

And if the answer is yes, the followup question is: Do we then add the federation prop to the JsonSchema component? That feels somewhat off.

{
            ...
            "federation:backends": [
                "vito",
                "eodc"
            ],
            "id": "aggregate_spatial",
            ...
            "parameters": [
                {
                    "description": "A raster data cube.\n\nThe data cube must have been reduced to only contain two spatial dimensions and a third dimension the values are aggregated for, for example the temporal dimension to get a time series. Otherwise, this process fails with the `TooManyDimensions` exception.\n\nThe data cube implicitly gets restricted to the bounds of the geometries as if ``filter_spatial()`` would have been used with the same values for the corresponding parameters immediately before this process.",
                    "name": "data",
                    "schema": {
                        "subtype": "raster-cube",
                        "type": "object"
                    }
                },
                {
                    "description": "Geometries as GeoJSON on which the aggregation will be based.\n\nOne value will be computed per GeoJSON `Feature`, `Geometry` or `GeometryCollection`. For a `FeatureCollection` multiple values will be computed, one value per contained `Feature`. For example, a single value will be computed for a `MultiPolygon`, but two values will be computed for a `FeatureCollection` containing two polygons.\n\n- For **polygons**, the process considers all pixels for which the point at the pixel center intersects with the corresponding polygon (as defined in the Simple Features standard by the OGC).\n- For **points**, the process considers the closest pixel center.\n- For **lines** (line strings), the process considers all the pixels whose centers are closest to at least one point on the line.\n\nThus, pixels may be part of multiple geometries and be part of multiple aggregations.\n\nTo maximize interoperability, a nested `GeometryCollection` should be avoided. Furthermore, a `GeometryCollection` composed of a single type of geometries should be avoided in favour of the corresponding multi-part type (e.g. `MultiPolygon`).",
                    "name": "geometries",
                    "schema": {
                        "subtype": "geojson",
                        "type": "object"
                    }
                },
                {
                    "description": "A reducer to be applied on all values of each geometry. A reducer is a single process such as ``mean()`` or a set of processes, which computes a single value for a list of values, see the category 'reducer' for such processes.",
                    "name": "reducer",
                    "schema": {
                        "parameters": [
                            {
                                "description": "An array with elements of any type.",
                                "name": "data",
                                "schema": {
                                    "items": {
                                        "description": "Any data type."
                                    },
                                    "type": "array"
                                }
                            },
                            {
                                "default": null,
                                "description": "Additional data passed by the user.",
--->                            "federation:backends": ["vito"],
                                "name": "context",
                                "optional": true,
                                "schema": {
                                    "description": "Any data type."
                                }
                            }
                        ],
                        "returns": {
                            "description": "The value to be set in the vector data cube.",
                            "schema": {
                                "description": "Any data type."
                            }
                        },
                        "subtype": "process-graph",
                        "type": "object"
                    }
                },
                {
                    "default": "result",
                    "description": "The new dimension name to be used for storing the results. Defaults to `result`.",
                    "name": "target_dimension",
                    "optional": true,
                    "schema": {
                        "type": "string"
                    }
                },
                {
                    "default": null,
                    "description": "Additional data to be passed to the reducer.",
                    "name": "context",
                    "optional": true,
                    "schema": {
                        "description": "Any data type."
                    }
                }
            ],
            ...
        },

[m-mohr]

Let's keep it realistic: I don't expect any implementation yet to go deeper than the process parameter itself.
So focus should be Collection(s), Process(es), Process Parameter (both for pre-defined and user-defined), UDF Runtime, File Format, File Format Parameter (if there's an easy solution), Job(s), Service(s), Files. An implementation of those entities would be reasonable and be practical. All other edge cases withing JSON Schemas or so we can ignore for now. Could be something for later, but we can ignore this until it actually comes up in practice.

So: Yes, we shouldn't add the federation property to the JSON Schema component yet.