Rename "id" to "process" and use full URI to process

[Jerome St-Louis]

This facilitates sharing process execution as a client will know where to POST the execution request to.
It also allows nested processes as inputs for the chained workflows extension.

[Jerome St-Louis]

If going with the suggestion in #124 where the client can POST to /processes/{processId}, then the process element could be made optional (defaulting to the end-point to which you POST).

[Jerome St-Louis]

Clarifications we discussed in the 2021-02-21 SWG meeting:

• If adopting this approach, a process receiving an execute request could ignore the top-level "process" to enable re-using the same execute request with multiple end-points (the process already knows that it is itself being executed)
• In Workflows, the full process URL is essential for nested processes to be able to invoke the nested processing end-points
• In Workflows, "process" in also what identifies a nested process execution another type of input, like "href" or "collection" or "value".

[ghobona]

@jerstlouis If I understand correctly, the first bullet is proposing to support a request and payload structure such as:

URL: http://localhost:8080/processes/EchoProcess

{
	"inputs": {
		"complexInputId": {
			"format": {
				"mediaType": "application/xml"
			},
			"value": "<test/>"
		},
		"complexInputsId": [
			{
				"format": {
					"mediaType": "text/plain",
					"encoding": "UTF-8"
				},
				"value": "test"
			},
			{
				"format": {
					"mediaType": "text/plain",
					"encoding": "UTF-8"
				},
				"href": "https://test.data/test.txt"
			}
		],
		"literalInputId": {
			"dataType": {
				"name": "double"
			},
			"value": "0.05"
		},
		"boundingboxInputId": {
			"bbox": [
				51.9,
				7,
				52,
				7.1
			],
			"crs": "EPSG:4326"
		}
	},
	"outputs": {
		"literalOutputId": {
			"transmissionMode": "value"
		},
		"boundingboxOutput": {
			"transmissionMode": "value"
		},
		"complexOutputId": {
			"format": {
				"mediaType": "application/xml"
			},
			"transmissionMode": "value"
		},
		"complexOutputsId": {
			"format": {
				"mediaType": "text/plain"
			},
			"transmissionMode": "reference"
		}
	},
	"response": "document",
	"mode": "async"
}

Note that the example above removes the 'id' property from the current Execute example.

@jerstlouis Could you please confirm that the example above reflects what you are proposing?

[Jerome St-Louis]

@ghobona In general the proposal would be for such an execute requests to include

"process" : "http://localhost:8080/processes/EchoProcess"

but the first bullet of the clarifications means that for the top-level process (i.e. excluding workflows nested processes) this "process" be optional, if we were to also approve #124 where the execution end-point can already point to a dedicated process.

A reason for including the process in the execute request would be to share it as something meant to always be executed for that particular end-point (e.g. drag & drop it in QGIS and it knows where to POST it to).
A reason for not including the process in the execute request would be to re-use it with multiple processing end-points.

[ghobona]

@jerstlouis Thanks for the clarification.

[Jerome St-Louis]

"id" was removed from Part 1 and "process" was added in Part 3. Can we close?