You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: extensions/processing-parameters/README.md
+9-9Lines changed: 9 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Processing Parameters Extension
2
2
3
-
The Processing Parameters Extension to the openEO API provides an interface to explore and handle additional processing options that a back-end can offer for the three processing modes (synchronous processing, batch jobs, secondary web services).
3
+
The Processing Parameters Extension to the openEO API provides an interface to explore and handle additional processing parameters that a back-end can offer for the three processing modes (synchronous processing, batch jobs, secondary web services).
4
4
5
5
- Version: **0.1.0**
6
6
- Stability: **experimental**
@@ -10,8 +10,8 @@ The Processing Parameters Extension to the openEO API provides an interface to e
10
10
**Note:** This document only documents the additions to the specification.
11
11
Extensions can not change or break existing behavior of the openEO API.
12
12
13
-
This extension adds a new endpoint (`GET /processing_options`, see [OpenAPI document](openapi.yaml))
14
-
to discover the additional processing options that a back-end offers.
13
+
This extension adds a new endpoint (`GET /processing_parameters`, see [OpenAPI document](openapi.yaml))
14
+
to discover the additional processing parameters that a back-end offers.
15
15
16
16
Additionally, this extension allows to provide specific default values for user-defined processes (UDPs, see below).
17
17
@@ -21,12 +21,12 @@ In both cases, the parameters and its values are provided separately for each pr
21
21
22
22
UDPs can provide default values for specific processing parameters.
23
23
24
-
The values for each parameter are provided separately for each processing mode.
24
+
The values for each parameter (so called 'options') are provided separately for each processing mode.
25
25
The following properties are added to the top-level of a UDP for the respective processing modes:
26
26
27
-
-`default_synchronous_parameters` for synchronous processing
28
-
-`default_job_parameters` for batch jobs
29
-
-`default_service_parameters` for secondary web services
27
+
-`default_synchronous_options` for synchronous processing
28
+
-`default_job_options` for batch jobs
29
+
-`default_service_options` for secondary web services
30
30
31
31
The schema for each of these properties is:
32
32
@@ -38,7 +38,7 @@ additionalProperties:
38
38
39
39
The keys of the object are the respective parameter names.
40
40
The values of the object are the default values for the parameters.
41
-
Schematic restrictions are not defined for the object, but the schemas for the parameters as defined in `GET /processing_options` apply to the given values.
41
+
Schematic restrictions are not defined for the object, but the schemas for the parameters as defined in `GET /processing_parameters` apply to the given values.
42
42
These values provide the defaults unless a user overrides them in the actual data processing request (e.g. `POST /jobs`, see below).
43
43
44
44
## Resolving parameters
@@ -48,7 +48,7 @@ list defines how the parameters must be resolved. The prioritization is as follo
48
48
49
49
1. If present, use the parameter specified in the processing request directly (e.g. in `POST /jobs` as a top-level property)
50
50
2. If present, use the default parameter specified in the UDP
51
-
3. Otherwise, use the default value for the parameter as specified in `GET /processing_options`
51
+
3. Otherwise, use the default value for the parameter as specified in `GET /processing_parameters`
52
52
53
53
"Present"means that the property is present in the JSON representation regardless of the value given, i.e.
54
54
properties are present if an empty string, an empty array, an empty object, `false`, `0`, or `null` are provided.
Copy file name to clipboardExpand all lines: extensions/processing-parameters/openapi.yaml
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ info:
3
3
title: openEO API - Processing Parameters Extension
4
4
version: 0.1.0
5
5
description: >-
6
-
The Processing Parameters Extension to the openEO API provides an interface to explore and handle additional processing options that a back-end can offer for the three processing modes (synchronous processing, batch jobs, and secondary web services).
6
+
The Processing Parameters Extension to the openEO API provides an interface to explore and handle additional processing parameters that a back-end can offer for the three processing modes (synchronous processing, batch jobs, and secondary web services).
7
7
The openEO API specification allows back-ends to accept "additional back-end specific properties" for each of the processing modes.
8
8
As the openEO API specification does not define the name and schemas of these properties, this extension provides a standardized way to define and document these properties.
9
9
contact:
@@ -44,15 +44,15 @@ servers:
44
44
the version number of the API. Use the version number returned from
45
45
`GET /` instead.
46
46
paths:
47
-
/processing_options:
47
+
/processing_parameters:
48
48
get:
49
-
summary: Additional processing options
50
-
operationId: list-processing-options
49
+
summary: Additional processing parameters
50
+
operationId: list-processing-parameters
51
51
description: |-
52
-
Lists additional custom processing options
52
+
Lists additional custom processing parameters
53
53
that a back-end offers for the different processing modes (synchronous processing, batch jobs, secondary web services).
54
-
The options specified here can be added to the corresponding `POST` requests at the top-level of the object that is sent as the payload.
55
-
All options SHOULD explicitly be made optional with reasonable defaults as otherwise the interoperability between the implementations decreases.
54
+
The parameters specified here can be added to the corresponding `POST` requests at the top-level of the object that is sent as the payload.
55
+
All parameters SHOULD explicitly be made optional with reasonable defaults as otherwise the interoperability between the implementations decreases.
0 commit comments