Adopt and publish API & Process Profiles

m-mohr commented 10 months ago

Background

In the openEO Platform project the desire came up to define profiles pro API and process compliance. We initiated a working group (consisting of VITO, EODC, Sinergise, EURAC and me) that worked on these profiles. It felt more helpful to define a generic set of profiles for openEO in general and not just openEO Platform specific profiles. As such we've defined requirements grouped into a set of profiles for the openEO API and the openEO Processes. This helps to classify the implementation status of an openEO instance and gives recommendations to implementors which functionality to prioritize.

Proposal

I'm proposing here (on behalf of the working group) to adopt and publish these API and process profiles.

API

An overview of the openEO API profiles can be found below. Documentation with list of requirements per profile is here: https://github.com/Open-EO/openeo.org/blob/profiles/documentation/1.0/developers/profiles/api.md

Processes

An overview of the openEO Processes profiles can be found below. Documentation with list of processes/requirements per profile is here: https://github.com/Open-EO/openeo.org/blob/profiles/documentation/1.0/developers/profiles/processes.md

PR

The full PR to update openeo.org, the list of profiles and some background information can be found here: https://github.com/Open-EO/openeo.org/pull/82

Additional context

This will be on the agenda of the next PSC meeting, you can nevertheless already vote +1 if you want so. The proposal won't be accepted before the next PSC meeting. According to the PSC guidelines the proposal gets accepted if there are not enough votes until Dec 18 2023.

m-mohr commented 10 months ago

+1

jdries commented 10 months ago

Wanted to add my +1 here, but perhaps just wanted to ask some additional clarification on the advanced category and onwards: we include a number of experimental processes there, and processes that I haven't even really seen in practice, so why do we include them already in the profile? Isn't it safer to leave them out?

Some examples: run_udf_externally (known implementations?) flatten/unflatten dimension -> for me that's still under quite a bit of discussion cloud_detection (known implementations?)

By the way, I think the fact that we put merge_cubes only in L3 deserves special mention. It means that data fusion use cases require an L3 backend or an L2+merge_cubes kind of backend. Maybe we can mention that in the overview description?

m-mohr commented 10 months ago

additional clarification on the advanced category and onwards: we include a number of experimental processes there, and processes that I haven't even really seen in practice, so why do we include them already in the profile? Isn't it safer to leave them out?

We tried to map them all and in the openEO profiles experimental processes shall only lead to a warning/notice, not lead to not passing the compliance test. This is also mentioned in the documents. We did say that in openEO Platform experimental processes shall fail the compliance tests, but this should only be the case for L1 and L2 (i.e. everything that LP depends on). I'll clarify that. It then only applies to nan and inspect, which I suspect will become stable rather sooner than later anyway.

Some examples: run_udf_externally (known implementations?)

None. But it would only lead to a notice, not a failure in openEO tests as it is experimental. A profile (L3-UDF) for a single process (run_udf) seems not ideal and then there's no other good place to put it. So just implementing run_udf would effectively make you pass the L3-UDF profile.

flatten/unflatten dimension, cloud_detection

There was at least one implementation in the past afaik, but that has gone away it seems. Again, missing them would just lead to a warning/notice.

By the way, I think the fact that we put merge_cubes only in L3 deserves special mention. It means that data fusion use cases require an L3 backend or an L2+merge_cubes kind of backend. Maybe we can mention that in the overview description?

You can add additional processes at any point. You can even not be L1 compliant and implement merge_cubes on top. These are "minimum requirements" and don't exclude you from implementing more. I'm not sure what to add to the PR, please add a proposal to the corresponding PR.

Hope this helps.