Formal definition of the Echo process

[pvretano]

Currently the specification says that server that intend to run CITE certification should deploy an "Echo" process. However, there is no formal definition and there probably should be. I don't think that the Echo processes needs to test every possible input type but maybe a set of "common" types as determined by the SWG. We should also try to make it "extensible" somehow for those server that want to test more that just the basics.

[jerstlouis]

Personally, I strongly feel that it really should be possible to run CITE certification without an Echo process.

Yes, it means a bit more work for the ETS, but the whole point of the OGC Process Description conformance class, just like an eventual OpenAPI Process Description, is to be able to describe how to execute a process in a way that is easy for a computer program to understand.

Just like with the Features test, it could default to the first 3 processes, or allow to select a number of processes to test. Then based on the process description, the ETS could easily fill in the inputs per the input schemas and test the outputs again per their schemas.

This would make the ETS much more useful in practice, and would not require implementers to set up this custom Echo process and avoid requiring them to support any data types that are not needed by their processes.

I believe often implementers may be developing a single process that they want to make available through OGC API - Processes, and it should be as easy as possible for them to conform.

[pvretano]

@jerstlouis don't disagree about the echo process although at the time it seemed like a good idea to make the work of developing the CITE tests a little easier. It's not ideal I know but since CITE has already gone down that path we should probably tread carefully and continue to maintain the Echo approach until a new version of the CITE suite can be developed that does not rely on it. With regard to the deployment of OAPIP, my experience has been that OAPIP implementations are created to deploy one or more libraries of processes (like GDAL) ... which is why at one point I was kinda advocating for a hierarchical (there's that word again ... LOL!) organization for the processes.

[jerstlouis]

since CITE has already gone down that path we should probably tread carefully and continue to maintain the Echo approach until a new version of the CITE suite can be developed that does not rely on it.

Of course, agreed. It is a good first step, and the Echo process description can even initially be used to first test this generic process execution capability. However, I don't think the specification should go any further than the current Recommendation A.1 in terms of the details of this Echo process, since it's really specific to the current CITE test limitations.

With regard to the deployment of OAPIP, my experience has been that OAPIP implementations are created to deploy one or more libraries of processes (like GDAL)

That is one category of implementations. But since these libraries are widely available for anyone to run locally, what I think is even more useful is organizations providing access to a unique processing capability / algorithm that they are developing via OGC API - Processes. An example in this category: the SimStadt building energy calculation process that Steinbeiss provided for Testbed 18.

[fmigneault]

Would it be possible for CITE to use an OpenAPI examples entry for Echo under POST /processes body, and validate the result against the corresponding examples of the response from GET /processes/Echo? That does require the evaluated server to support DRU. Servers that do not support it would have to match exactly a pre-deployed Echo that matches exactly what is defined in the DRU-aware deployment.

[bpross-52n]

SWG meeting from 2024-04-15: We will talk to the CITE team to enhance the test to be able to use processes with examples and not require an echo process.

[pvretano]

19-AUG-2024 SWG meeting: We are waiting for CITE input on this issue but the SWG feels that this is not a blocks issue for moving Parts 1 and 2 forward to the OAB, RFC and ultimately adoption vote.