From 76f602a4a4baad010b2636ae508fd1af5def77dc Mon Sep 17 00:00:00 2001 From: Francis Charette Migneault Date: Sat, 18 Jul 2026 13:39:36 -0400 Subject: [PATCH] Part 3: cleanup of collection input/output in core, update standard references, use https and define terms --- .../ATS_collection-input_access.adoc | 4 +- .../ATS_collection-input_filtering.adoc | 2 +- .../ATS_collection-input_pass-through.adoc | 4 +- ...S_collection-input_property-selection.adoc | 2 +- .../ATS_collection-input_referencing.adoc | 4 +- ...lection-output_data-access-mechanisms.adoc | 6 +- ...lection-output_response-response-many.adoc | 4 +- ...llection-output_response-response-one.adoc | 4 +- .../local-filtering/ATS_local-filtering.adoc | 4 +- .../ATS_remote-collections_access.adoc | 4 +- .../ATS_remote-collections_referencing.adoc | 4 +- .../PER_collection-output_dynamic.adoc | 2 +- ...llection-output_response-response-one.adoc | 2 +- .../PER_collection-output_static.adoc | 2 +- ...ults-success-async-many-other-formats.adoc | 2 +- ...-async-one-multi-valued-other-formats.adoc | 2 +- .../PER_process-execute-sync-one-result.adoc | 4 +- ...-one-multi-valued-json-prefer-minimal.adoc | 2 +- ...ync-one-multi-valued-json-prefer-none.adoc | 2 +- ...lti-valued-json-prefer-representation.adoc | 2 +- ...success-sync-many-json-prefer-minimal.adoc | 2 +- ...te-success-sync-many-json-prefer-none.adoc | 2 +- ...-sync-many-json-prefer-representation.adoc | 2 +- ...-one-multi-valued-json-prefer-minimal.adoc | 2 +- ...ync-one-multi-valued-json-prefer-none.adoc | 2 +- ...lti-valued-json-prefer-representation.adoc | 2 +- .../REQ_collection-input_access.adoc | 8 +- .../REQ_collection-input_filtering.adoc | 4 +- .../REQ_collection-input_pass-through.adoc | 2 +- ...Q_collection-input_property-selection.adoc | 6 +- .../REQ_collection-input_referencing.adoc | 8 +- ...lection-output_data-access-mechanisms.adoc | 4 +- ...lection-output_response-response-many.adoc | 2 +- ...llection-output_response-response-one.adoc | 2 +- .../core/REQ_job-result-op-0th.adoc | 2 +- .../core/REQ_job-result-op-Nth.adoc | 2 +- core/requirements/core/REQ_job-result-op.adoc | 2 +- .../REQ_job-results-success-async-many.adoc | 2 +- ...REQ_job-results-success-async-one-Nth.adoc | 2 +- ...esults-success-async-one-multi-valued.adoc | 2 +- .../REQ_job-results-success-async-one.adoc | 2 +- ...cute-success-sync-one-default-content.adoc | 2 +- .../REQ_process-execute-success-sync-one.adoc | 2 +- .../local-filtering/REQ_local-filtering.adoc | 4 +- .../REQ_data-access-apis.adoc | 2 +- .../REQ_remote-collections_access.adoc | 6 +- .../REQ_remote-collections_referencing.adoc | 6 +- core/sections/clause_2_conformance.adoc | 10 +-- .../clause_4_terms_and_definitions.adoc | 57 +++++++++------ core/sections/clause_7_core.adoc | 10 +-- core/sections/clause_8_collections.adoc | 26 +++---- .../clause_9_process-description.adoc | 6 +- .../clause_4_terms_and_definitions.adoc | 8 +- .../clause_4_terms_and_definitions.adoc | 6 +- extensions/workflows/21-009.adoc | 9 +-- .../PER_collection-output_expiry.adoc | 8 -- ...EQ_collection-input_collection-access.adoc | 9 --- ...ollection-input_referenced-collection.adoc | 8 -- ...collection-output_collection-response.adoc | 9 --- ...lection-output_data-access-mechanisms.adoc | 8 -- ...llection-output_landing-page-response.adoc | 9 --- .../REQ_collection-output_landing-page.adoc | 9 --- ...ction-output_response-query-parameter.adoc | 7 -- ...ployable-workflows_deploying-workflow.adoc | 4 +- ..._remote-collections_collection-access.adoc | 9 --- ...ote-collections_referenced-collection.adoc | 9 --- .../requirements_class_collection-input.adoc | 9 --- .../requirements_class_collection-output.adoc | 23 ------ .../requirements_class_cwl-workflows.adoc | 6 +- ...quirements_class_deployable-workflows.adoc | 18 ++--- ...irements_class_input-fields-modifiers.adoc | 6 +- .../requirements_class_nested-processes.adoc | 12 +-- .../requirements_class_openeo-workflows.adoc | 4 +- ...rements_class_output-fields-modifiers.adoc | 4 +- ...requirements_class_remote-collections.adoc | 9 --- ...uirements_class_remote-core-processes.adoc | 4 +- .../sections/annex-b-coastal-erosion.adoc | 10 ++- .../sections/annex-bibliography.adoc | 2 +- .../workflows/sections/annex-history.adoc | 1 + .../sections/clause_0_front_material.adoc | 4 +- .../sections/clause_11_collection_output.adoc | 63 ---------------- .../sections/clause_12_cwl_workflows.adoc | 4 +- .../sections/clause_13_openeo_workflows.adoc | 2 +- .../sections/clause_14_media_types.adoc | 8 +- .../workflows/sections/clause_1_scope.adoc | 2 +- .../sections/clause_2_conformance.adoc | 73 +++++++------------ .../sections/clause_3_references.adoc | 20 ++--- .../clause_4_terms_and_definitions.adoc | 39 ++++++++-- .../sections/clause_5_conventions.adoc | 2 +- .../sections/clause_7_nested_processes.adoc | 5 +- .../sections/clause_8_collection_input.adoc | 43 ----------- ...lause_9_input_output_fields_modifiers.adoc | 41 +++++++---- 92 files changed, 298 insertions(+), 483 deletions(-) delete mode 100644 extensions/workflows/recommendations/collection-output/PER_collection-output_expiry.adoc delete mode 100644 extensions/workflows/requirements/collection-input/REQ_collection-input_collection-access.adoc delete mode 100644 extensions/workflows/requirements/collection-input/REQ_collection-input_referenced-collection.adoc delete mode 100644 extensions/workflows/requirements/collection-output/REQ_collection-output_collection-response.adoc delete mode 100644 extensions/workflows/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc delete mode 100644 extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page-response.adoc delete mode 100644 extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page.adoc delete mode 100644 extensions/workflows/requirements/collection-output/REQ_collection-output_response-query-parameter.adoc delete mode 100644 extensions/workflows/requirements/remote-collections/REQ_remote-collections_collection-access.adoc delete mode 100644 extensions/workflows/requirements/remote-collections/REQ_remote-collections_referenced-collection.adoc delete mode 100644 extensions/workflows/requirements/requirements_class_collection-input.adoc delete mode 100644 extensions/workflows/requirements/requirements_class_collection-output.adoc delete mode 100644 extensions/workflows/requirements/requirements_class_remote-collections.adoc delete mode 100644 extensions/workflows/sections/clause_11_collection_output.adoc delete mode 100644 extensions/workflows/sections/clause_8_collection_input.adoc diff --git a/core/abstract_tests/collection-input/ATS_collection-input_access.adoc b/core/abstract_tests/collection-input/ATS_collection-input_access.adoc index 03251f0b..ac6c8133 100644 --- a/core/abstract_tests/collection-input/ATS_collection-input_access.adoc +++ b/core/abstract_tests/collection-input/ATS_collection-input_access.adoc @@ -4,7 +4,7 @@ [%metadata] identifier:: /conf/collection-input/collection-access target:: /req/collection-input/collection-access -test-purpose:: Verify that the server supports the <> that is advertises for collection input. +test-purpose:: Verify that the server supports the <> that is advertises for collection input. test-method:: + -- @@ -12,6 +12,6 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. For each of the identified inputs verify that the server supports the specified <> by inspecting the server's conformance document obtained from the `/conformance` endpoint. +3. For each of the identified inputs verify that the server supports the specified <> by inspecting the server's conformance document obtained from the `/conformance` endpoint. -- ==== diff --git a/core/abstract_tests/collection-input/ATS_collection-input_filtering.adoc b/core/abstract_tests/collection-input/ATS_collection-input_filtering.adoc index 89e805ff..72b94aa6 100644 --- a/core/abstract_tests/collection-input/ATS_collection-input_filtering.adoc +++ b/core/abstract_tests/collection-input/ATS_collection-input_filtering.adoc @@ -12,7 +12,7 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). 4. In the specification of the collection input, specify one or more filtering elements as defined in <>. diff --git a/core/abstract_tests/collection-input/ATS_collection-input_pass-through.adoc b/core/abstract_tests/collection-input/ATS_collection-input_pass-through.adoc index 9bf071a1..8af5e641 100644 --- a/core/abstract_tests/collection-input/ATS_collection-input_pass-through.adoc +++ b/core/abstract_tests/collection-input/ATS_collection-input_pass-through.adoc @@ -12,9 +12,9 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). -4. In the specification of the collection input, specify the `passThroughParameters` element, as defined in <>, and include query parameters specific to the selected <>. +4. In the specification of the collection input, specify the `passThroughParameters` element, as defined in <>, and include query parameters specific to the selected <>. 5. Verify that the execute request completes successfully -- diff --git a/core/abstract_tests/collection-input/ATS_collection-input_property-selection.adoc b/core/abstract_tests/collection-input/ATS_collection-input_property-selection.adoc index 6bbea5b0..807eb00a 100644 --- a/core/abstract_tests/collection-input/ATS_collection-input_property-selection.adoc +++ b/core/abstract_tests/collection-input/ATS_collection-input_property-selection.adoc @@ -12,7 +12,7 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). 4. In the specification of the collection input, specify one or more property-selection elements using the `properties` (and optionally the `aliases`) parameter as defined in <>. diff --git a/core/abstract_tests/collection-input/ATS_collection-input_referencing.adoc b/core/abstract_tests/collection-input/ATS_collection-input_referencing.adoc index a8efd3d4..c297b3d7 100644 --- a/core/abstract_tests/collection-input/ATS_collection-input_referencing.adoc +++ b/core/abstract_tests/collection-input/ATS_collection-input_referencing.adoc @@ -12,9 +12,9 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that includes the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that includes the identified inputs and using a supported <> (see test: <> to identify supported <>). -4. Use the `collection` parameter in the <>, as defined in <>, to reference local collection from which input values are retrieved using one of the supported <>. +4. Use the `collection` parameter in the <>, as defined in <>, to reference local collection from which input values are retrieved using one of the supported <>. 5. Verify that the execute request completes successfully. -- diff --git a/core/abstract_tests/collection-output/ATS_collection-output_data-access-mechanisms.adoc b/core/abstract_tests/collection-output/ATS_collection-output_data-access-mechanisms.adoc index 7ad399f2..2a75612b 100644 --- a/core/abstract_tests/collection-output/ATS_collection-output_data-access-mechanisms.adoc +++ b/core/abstract_tests/collection-output/ATS_collection-output_data-access-mechanisms.adoc @@ -4,12 +4,12 @@ [%metadata] identifier:: /conf/collection-output/data-access-mechanisms target:: /req/collection-output/data-access-mechanisms -test-purpose:: Verify that the <> for an output collection includes data access links using at least one supported <>. +test-purpose:: Verify that the <> for an output collection includes data access links using at least one supported <>. test-method:: + -- -1. Retrieve the <> for an output collection. +1. Retrieve the <> for an output collection. -2. Verify that the <> includes at least one data access link using a supported <> (e.g. features, coverages); +2. Verify that the <> includes at least one data access link using a supported <> (e.g. features, coverages); -- ==== diff --git a/core/abstract_tests/collection-output/ATS_collection-output_response-response-many.adoc b/core/abstract_tests/collection-output/ATS_collection-output_response-response-many.adoc index 7a3168b2..9c9a4b11 100644 --- a/core/abstract_tests/collection-output/ATS_collection-output_response-response-many.adoc +++ b/core/abstract_tests/collection-output/ATS_collection-output_response-response-many.adoc @@ -4,7 +4,7 @@ [%metadata] identifier:: /conf/collection-output/response-response-many target:: /req/collection-output/response-response-many -test-purpose:: Validate that the response for multiple explicitly or implicitly requested outputs is a <> document containing references to <>. +test-purpose:: Validate that the response for multiple explicitly or implicitly requested outputs is a <> document containing references to <>. test-method:: + -- @@ -20,6 +20,6 @@ test-method:: 6. Verify that the body of the response conforms to the <> schema. -7. Verify that that value of each collection output is a link to a <>. +7. Verify that that value of each collection output is a link to a <>. -- ==== diff --git a/core/abstract_tests/collection-output/ATS_collection-output_response-response-one.adoc b/core/abstract_tests/collection-output/ATS_collection-output_response-response-one.adoc index a617153d..1c5fb861 100644 --- a/core/abstract_tests/collection-output/ATS_collection-output_response-response-one.adoc +++ b/core/abstract_tests/collection-output/ATS_collection-output_response-response-one.adoc @@ -4,7 +4,7 @@ [%metadata] identifier:: /conf/collection-output/response-response-one target:: /req/collection-output/response-response-one -test-purpose:: Validate that the collection output for a single explicitly or implicitly requested output is a reference to a <>. +test-purpose:: Validate that the collection output for a single explicitly or implicitly requested output is a reference to a <>. test-method:: + -- @@ -16,6 +16,6 @@ test-method:: 4. Verify that the server responds with an HTTP status code of 303. -5. Verify that the response includes a https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2[`Location`] response header redirecting to a <> +5. Verify that the response includes a https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2[`Location`] response header redirecting to a <> -- ==== diff --git a/core/abstract_tests/local-filtering/ATS_local-filtering.adoc b/core/abstract_tests/local-filtering/ATS_local-filtering.adoc index 6d68fa71..0dead2ee 100644 --- a/core/abstract_tests/local-filtering/ATS_local-filtering.adoc +++ b/core/abstract_tests/local-filtering/ATS_local-filtering.adoc @@ -12,9 +12,9 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that include the identified inputs and using a supported <> (see test: <> to identify supported <>). -4. For each execute request, inspect the <> and identify query capabilities that are not supported by those remote servers (e.g. CQL2 filtering). +4. For each execute request, inspect the <> and identify query capabilities that are not supported by those remote servers (e.g. CQL2 filtering). 5. Include the identified unsupported filtering elements in the execute request (e.g. a CQL filter) as per the <> schema thus forcing the test server to perform the requested filtering locally. diff --git a/core/abstract_tests/remote-collections/ATS_remote-collections_access.adoc b/core/abstract_tests/remote-collections/ATS_remote-collections_access.adoc index fc6f1e7d..cf9fb47e 100644 --- a/core/abstract_tests/remote-collections/ATS_remote-collections_access.adoc +++ b/core/abstract_tests/remote-collections/ATS_remote-collections_access.adoc @@ -4,7 +4,7 @@ [%metadata] identifier:: /conf/remote-collections/access target:: /req/remote-collections/access -test-purpose:: Verify that the server supports the <> that it advertises for accessing input data from remote collections. +test-purpose:: Verify that the server supports the <> that it advertises for accessing input data from remote collections. test-method:: + -- @@ -12,6 +12,6 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. For each of the identified inputs verify that the server supports the the specified <> by inspecting the server's conformance document obtained from the `/conformance` endpoint. +3. For each of the identified inputs verify that the server supports the the specified <> by inspecting the server's conformance document obtained from the `/conformance` endpoint. -- ==== diff --git a/core/abstract_tests/remote-collections/ATS_remote-collections_referencing.adoc b/core/abstract_tests/remote-collections/ATS_remote-collections_referencing.adoc index 8f1b00e2..bbcc7e80 100644 --- a/core/abstract_tests/remote-collections/ATS_remote-collections_referencing.adoc +++ b/core/abstract_tests/remote-collections/ATS_remote-collections_referencing.adoc @@ -4,7 +4,7 @@ [%metadata] identifier:: /conf/remote-collections/referencing target:: /req/remote-collections/referencing -test-purpose:: Verify that the server correctly processes input data retrieved from remote collections using a supported <>. +test-purpose:: Verify that the server correctly processes input data retrieved from remote collections using a supported <>. test-method:: + -- @@ -12,7 +12,7 @@ test-method:: 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <>). -3. Compose <> that includes the identified inputs and using a supported <> (see test: <> to identify supported <>). +3. Compose <> that includes the identified inputs and using a supported <> (see test: <> to identify supported <>). 4. Use the `collection` parameter in the <>, as defined in <>, to reference remote collections from which input values will be retrieved. diff --git a/core/recommendations/collection-output/PER_collection-output_dynamic.adoc b/core/recommendations/collection-output/PER_collection-output_dynamic.adoc index df976896..a9cd4900 100644 --- a/core/recommendations/collection-output/PER_collection-output_dynamic.adoc +++ b/core/recommendations/collection-output/PER_collection-output_dynamic.adoc @@ -4,5 +4,5 @@ [%metadata] identifier:: /per/collection-output/dynamic -The server MAY arrange for the <> to be a "virtual" collection with processing being triggered at run-time each time the data of the collection is accessed using an <> and taking into account any spatial, temporal and other filters specified on that data access request. +The server MAY arrange for the <> to be a "virtual" collection with processing being triggered at run-time each time the data of the collection is accessed using an <> and taking into account any spatial, temporal and other filters specified on that data access request. ==== diff --git a/core/recommendations/collection-output/PER_collection-output_response-response-one.adoc b/core/recommendations/collection-output/PER_collection-output_response-response-one.adoc index e82740be..e9720b47 100644 --- a/core/recommendations/collection-output/PER_collection-output_response-response-one.adoc +++ b/core/recommendations/collection-output/PER_collection-output_response-response-one.adoc @@ -8,7 +8,7 @@ identifier:: /per/collection-output/response-response-one -- . The execution request includes the `response` query parameter. . The value of the `response` query parameter is `collection`. -. The number of <> or <> requested outputs is 1. +. The number of <> or <> requested outputs is 1. . The server implements the <> requirements class. . The execution request also includes the <> query parameter. . The value of the <> query parameter is `https://www.opengis.net/def/profile/OGC/0/ogc-results`. diff --git a/core/recommendations/collection-output/PER_collection-output_static.adoc b/core/recommendations/collection-output/PER_collection-output_static.adoc index fbf380c4..39f43e92 100644 --- a/core/recommendations/collection-output/PER_collection-output_static.adoc +++ b/core/recommendations/collection-output/PER_collection-output_static.adoc @@ -4,5 +4,5 @@ [%metadata] identifier:: /per/collection-output/static -The server MAY perform all the requested processing up front resulting in a fully materialized and static <>. +The server MAY perform all the requested processing up front resulting in a fully materialized and static <>. ==== diff --git a/core/recommendations/core/PER_job-results-success-async-many-other-formats.adoc b/core/recommendations/core/PER_job-results-success-async-many-other-formats.adoc index c0eaa1a1..516639b0 100644 --- a/core/recommendations/core/PER_job-results-success-async-many-other-formats.adoc +++ b/core/recommendations/core/PER_job-results-success-async-many-other-formats.adoc @@ -7,7 +7,7 @@ identifier:: /per/core/job-results-async-many-other-formats [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 2 or more. +. The number of requested (whether <> or <>) outputs in the <> is 2 or more. -- [.component,class=part] diff --git a/core/recommendations/core/PER_job-results-success-async-one-multi-valued-other-formats.adoc b/core/recommendations/core/PER_job-results-success-async-one-multi-valued-other-formats.adoc index a6bad41a..ca60546b 100644 --- a/core/recommendations/core/PER_job-results-success-async-one-multi-valued-other-formats.adoc +++ b/core/recommendations/core/PER_job-results-success-async-one-multi-valued-other-formats.adoc @@ -7,7 +7,7 @@ identifier:: /per/core/job-results-async-one-multi-valued-other-formats [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. -- diff --git a/core/recommendations/core/PER_process-execute-sync-one-result.adoc b/core/recommendations/core/PER_process-execute-sync-one-result.adoc index e413493b..8eebfd26 100644 --- a/core/recommendations/core/PER_process-execute-sync-one-result.adoc +++ b/core/recommendations/core/PER_process-execute-sync-one-result.adoc @@ -7,12 +7,12 @@ identifier:: /per/core/process-execute-sync-one-result [.component,class=conditions] -- . The <> is synchronous, -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. -- [.component,class=part] -- -In the case where a single output is requested (whether <> or <>), <> MAY be used to request that the response conform to the <> schema. +In the case where a single output is requested (whether <> or <>), <> MAY be used to request that the response conform to the <> schema. -- [.component,class=part] diff --git a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-minimal.adoc b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-minimal.adoc index dad2eeb8..f9481350 100644 --- a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-minimal.adoc +++ b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-minimal.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/job-results-async-one-multi-valued-json-prefer-minimal [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `minimal`. -- diff --git a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-none.adoc b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-none.adoc index fa60892d..ed4ad632 100644 --- a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-none.adoc +++ b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-none.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/job-results-async-one-multi-valued-json-prefer-none [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . A return preference is _**not**_ specified via the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[`prefer`] header. -- diff --git a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-representation.adoc b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-representation.adoc index dadc461b..0ad577f5 100644 --- a/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-representation.adoc +++ b/core/recommendations/core/REC_job-results-success-async-one-multi-valued-json-prefer-representation.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/job-results-async-one-multi-valued-json-prefer-representa [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `representation`. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc index bfd6f14f..050c44a7 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-many-json-prefer-minimal [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is 2 or more. +. The number of requested (whether <> or <>) outputs in the <> is 2 or more. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `minimal`. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc index af3ba3f7..8ab4767a 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-many-json-prefer-none [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is 2 or more. +. The number of requested (whether <> or <>) outputs in the <> is 2 or more. . No https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] accompanies the request. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc index 84e42414..1eed340f 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-many-json-prefer-representation [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is two (2) or more. +. The number of requested (whether <> or <>) outputs in the <> is two (2) or more. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `representation`. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-minimal.adoc b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-minimal.adoc index 7b9b397c..677fc37e 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-minimal.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-minimal.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-one-multi-valued-json-prefer-minimal [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `minimal`. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-none.adoc b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-none.adoc index de6df29c..378bc0aa 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-none.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-none.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-one-multi-valued-json-prefer-none [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . No https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] accompanies the request. -- diff --git a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-representation.adoc b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-representation.adoc index c71020ca..874cbd1e 100644 --- a/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-representation.adoc +++ b/core/recommendations/core/REC_process-execute-success-sync-one-multi-valued-json-prefer-representation.adoc @@ -7,7 +7,7 @@ identifier:: /rec/core/process-execute-sync-one-multi-valued-json-prefer-represe [.component,class=conditions] -- . The <> is synchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . In the <> the output is defined as having `maxOccurs>1`. . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `representation`. -- diff --git a/core/requirements/collection-input/REQ_collection-input_access.adoc b/core/requirements/collection-input/REQ_collection-input_access.adoc index 7fcf2b4a..cadc4b44 100644 --- a/core/requirements/collection-input/REQ_collection-input_access.adoc +++ b/core/requirements/collection-input/REQ_collection-input_access.adoc @@ -6,22 +6,22 @@ identifier:: /req/collection-input/collection-access [.component,class=description] -- -For referencing a <> as a source of <>: +For referencing a <> as a source of <>: -- [.component,class=part] -- -The server SHALL support accessing <> using at least one supported <>. +The server SHALL support accessing <> using at least one supported <>. -- [.component,class=part] -- -The server SHALL, in the <> and for each relevant input, indicate which <> can be used to retrieve input values for that input from the <>. +The server SHALL, in the <> and for each relevant input, indicate which <> can be used to retrieve input values for that input from the <>. -- ==== [NOTE] ==== -For <>, the specification is agnostic to how data flows from the <> to the process. +For <>, the specification is agnostic to how data flows from the <> to the process. ==== diff --git a/core/requirements/collection-input/REQ_collection-input_filtering.adoc b/core/requirements/collection-input/REQ_collection-input_filtering.adoc index 2fc8f20d..57d5e0f3 100644 --- a/core/requirements/collection-input/REQ_collection-input_filtering.adoc +++ b/core/requirements/collection-input/REQ_collection-input_filtering.adoc @@ -6,7 +6,7 @@ identifier:: /req/collection-input/filtering [.component,class=description] -- -To support the filtering of data accessed from a <> before providing that data as <>: +To support the filtering of data accessed from a <> before providing that data as <>: -- [.component,class=part] @@ -29,7 +29,7 @@ as defined in the <> schema. [.component,class=part] -- -These filtering parameters SHALL be mapped to corresponding query parameters in the <> chosen to retrieve input values from the <>. +These filtering parameters SHALL be mapped to corresponding query parameters in the <> chosen to retrieve input values from the <>. -- ==== diff --git a/core/requirements/collection-input/REQ_collection-input_pass-through.adoc b/core/requirements/collection-input/REQ_collection-input_pass-through.adoc index e64a7d25..3d116a1e 100644 --- a/core/requirements/collection-input/REQ_collection-input_pass-through.adoc +++ b/core/requirements/collection-input/REQ_collection-input_pass-through.adoc @@ -6,7 +6,7 @@ identifier:: /req/collection-input/pass-through [.component,class=description] -- -To support the ability to opaquely pass query parameters through to the <>: +To support the ability to opaquely pass query parameters through to the <>: -- [.component,class=part] diff --git a/core/requirements/collection-input/REQ_collection-input_property-selection.adoc b/core/requirements/collection-input/REQ_collection-input_property-selection.adoc index 70d74dec..a8173b4f 100644 --- a/core/requirements/collection-input/REQ_collection-input_property-selection.adoc +++ b/core/requirements/collection-input/REQ_collection-input_property-selection.adoc @@ -6,7 +6,7 @@ identifier:: /req/collection-input/property-selection [.component,class=description] -- -The support property and derived property selection from a <> before providing the data as <> +The support property and derived property selection from a <> before providing the data as <> -- [.component,class=part] @@ -22,12 +22,12 @@ as defined in the <> schema. [.component,class=part] -- -If supported by the <> chosen to retrieve input values from the <>, then the server SHALL map these parameters to the corresponding query parameters in the <>. +If supported by the <> chosen to retrieve input values from the <>, then the server SHALL map these parameters to the corresponding query parameters in the <>. -- [.component,class=part] -- -If NOT supported by the <> chosen to retrieve input values from the <>, then the server SHALL perform the property selection operation before providing the data as input to the process. +If NOT supported by the <> chosen to retrieve input values from the <>, then the server SHALL perform the property selection operation before providing the data as input to the process. -- ==== diff --git a/core/requirements/collection-input/REQ_collection-input_referencing.adoc b/core/requirements/collection-input/REQ_collection-input_referencing.adoc index d61a5391..03f4dd9d 100644 --- a/core/requirements/collection-input/REQ_collection-input_referencing.adoc +++ b/core/requirements/collection-input/REQ_collection-input_referencing.adoc @@ -6,7 +6,7 @@ identifier:: /req/collection-input/referencing .component,class=description] -- -For referencing a <> as a source of <>: +For referencing a <> as a source of <>: -- [.component,class=part] @@ -16,18 +16,18 @@ The server SHALL support inputs in an <> [.component,class=part] -- -The value of the `collection` parameter SHALL be URI or Relative-URI identifying a <> from which <> are retrieved. +The value of the `collection` parameter SHALL be URI or Relative-URI identifying a <> from which <> are retrieved. -- [.component,class=part] -- -The URI or Relative-URI path SHALL not extend past the collection element in order to allow the server to decide, based on the expected input value type from the <> and other factors, which supported <> should be employed to retrieve input values from the <>. +The URI or Relative-URI path SHALL not extend past the collection element in order to allow the server to decide, based on the expected input value type from the <> and other factors, which supported <> should be employed to retrieve input values from the <>. -- [.component,class=part] -- The server SHALL interpret Relative-URIs as relative to the parent process within which the containing collection object is nested. --- +-- ==== diff --git a/core/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc b/core/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc index 65e098cb..d3791a49 100644 --- a/core/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc +++ b/core/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc @@ -6,12 +6,12 @@ identifier:: /req/collection-output/data-access-mechanisms [.component,class=description] -- -For returning resulting output data as a response to <>: +For returning resulting output data as a response to <>: -- [.component,class=part] -- -The server SHALL support at least one <> corresponding to the data access links included in the target <>. +The server SHALL support at least one <> corresponding to the data access links included in the target <>. -- ==== diff --git a/core/requirements/collection-output/REQ_collection-output_response-response-many.adoc b/core/requirements/collection-output/REQ_collection-output_response-response-many.adoc index c201c037..389f4e10 100644 --- a/core/requirements/collection-output/REQ_collection-output_response-response-many.adoc +++ b/core/requirements/collection-output/REQ_collection-output_response-response-many.adoc @@ -28,7 +28,7 @@ The content of response SHALL conform to the <> sch [.component,class=part] -- -Each collection output in the response SHALL be a link to a <>. +Each collection output in the response SHALL be a link to a <>. -- ==== diff --git a/core/requirements/collection-output/REQ_collection-output_response-response-one.adoc b/core/requirements/collection-output/REQ_collection-output_response-response-one.adoc index 9034d7f5..a33d59ef 100644 --- a/core/requirements/collection-output/REQ_collection-output_response-response-one.adoc +++ b/core/requirements/collection-output/REQ_collection-output_response-response-one.adoc @@ -18,7 +18,7 @@ The server SHALL respond with an HTTP status code of https://datatracker.ietf.or [.component,class=part] -- -The response SHALL include a https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2[`Location`] response header redirecting to a <>. +The response SHALL include a https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2[`Location`] response header redirecting to a <>. -- ==== diff --git a/core/requirements/core/REQ_job-result-op-0th.adoc b/core/requirements/core/REQ_job-result-op-0th.adoc index e0be3954..fece11df 100644 --- a/core/requirements/core/REQ_job-result-op-0th.adoc +++ b/core/requirements/core/REQ_job-result-op-0th.adoc @@ -4,5 +4,5 @@ [%metadata] identifier:: /req/core/job-result-op-0th -For each output, with output identifier `outputID`, defined in the <> and requested (whether <> or <>) in an <>, the server SHALL support the HTTP GET operation at the path `/jobs/{jobID}/results/{outputID}/0`. +For each output, with output identifier `outputID`, defined in the <> and requested (whether <> or <>) in an <>, the server SHALL support the HTTP GET operation at the path `/jobs/{jobID}/results/{outputID}/0`. ==== diff --git a/core/requirements/core/REQ_job-result-op-Nth.adoc b/core/requirements/core/REQ_job-result-op-Nth.adoc index 4d69659b..44f41164 100644 --- a/core/requirements/core/REQ_job-result-op-Nth.adoc +++ b/core/requirements/core/REQ_job-result-op-Nth.adoc @@ -8,7 +8,7 @@ identifier:: /req/core/job-result-op-Nth [.component,class=conditions] -- . The output with output identifier `outputID` is defined in the <> as having `maxOccurs>1`. -. The output with output identifier `outputID` is <> or <> requested in an <>. +. The output with output identifier `outputID` is <> or <> requested in an <>. -- [.component,class=part] diff --git a/core/requirements/core/REQ_job-result-op.adoc b/core/requirements/core/REQ_job-result-op.adoc index 61b3fd34..c08cdd23 100644 --- a/core/requirements/core/REQ_job-result-op.adoc +++ b/core/requirements/core/REQ_job-result-op.adoc @@ -4,5 +4,5 @@ [%metadata] identifier:: /req/core/job-result-op -For each output, with output identifier `outputID`, defined in the <> and requested (whether <> or <>) in an <>, the server SHALL support the HTTP GET operation at the path `/jobs/{jobID}/results/{outputID}`. +For each output, with output identifier `outputID`, defined in the <> and requested (whether <> or <>) in an <>, the server SHALL support the HTTP GET operation at the path `/jobs/{jobID}/results/{outputID}`. ==== diff --git a/core/requirements/core/REQ_job-results-success-async-many.adoc b/core/requirements/core/REQ_job-results-success-async-many.adoc index 147228c8..11b1e3e3 100644 --- a/core/requirements/core/REQ_job-results-success-async-many.adoc +++ b/core/requirements/core/REQ_job-results-success-async-many.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/job-results-async-many [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 2 or more. +. The number of requested (whether <> or <>) outputs in the <> is 2 or more. . The results are retrieved from the `/jobs/{jobID}/results` endpoint. -- diff --git a/core/requirements/core/REQ_job-results-success-async-one-Nth.adoc b/core/requirements/core/REQ_job-results-success-async-one-Nth.adoc index ba9230d3..7b07b7b2 100644 --- a/core/requirements/core/REQ_job-results-success-async-one-Nth.adoc +++ b/core/requirements/core/REQ_job-results-success-async-one-Nth.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/job-results-async-one-Nth [.component,class=conditions] -- . The <> is asynchronous, -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . The requested output with identifier `outputID` is defined in the <> as having `maxOccurs>1`. . The path `/jobs/{jobID}/results/{outputID}/{N}` is accessed to retrieve the 0-based _N^th^_ value from the array of values produced for this output. -- diff --git a/core/requirements/core/REQ_job-results-success-async-one-multi-valued.adoc b/core/requirements/core/REQ_job-results-success-async-one-multi-valued.adoc index b8bf9ba5..670e6bf4 100644 --- a/core/requirements/core/REQ_job-results-success-async-one-multi-valued.adoc +++ b/core/requirements/core/REQ_job-results-success-async-one-multi-valued.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/job-results-async-one-multi-valued [.component,class=conditions] -- . The <> is asynchronous. -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. - In its <> the requested output is defined as having `maxOccurs>1`. . The results are retrieved from the `/jobs/{jobID}/results/{outputID}` endpoint. -- diff --git a/core/requirements/core/REQ_job-results-success-async-one.adoc b/core/requirements/core/REQ_job-results-success-async-one.adoc index ed9ca989..5eb2cf87 100644 --- a/core/requirements/core/REQ_job-results-success-async-one.adoc +++ b/core/requirements/core/REQ_job-results-success-async-one.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/job-results-async-one [.component,class=conditions] -- . The <> is asynchronous, -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . The result is retrieved from the `/jobs/{jobID}/results/{outputID}` endpoint. -- diff --git a/core/requirements/core/REQ_process-execute-success-sync-one-default-content.adoc b/core/requirements/core/REQ_process-execute-success-sync-one-default-content.adoc index abf8146e..be082135 100644 --- a/core/requirements/core/REQ_process-execute-success-sync-one-default-content.adoc +++ b/core/requirements/core/REQ_process-execute-success-sync-one-default-content.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/process-execute-sync-one-default-content [.component,class=conditions] -- . The <> is synchronous, -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. . No content negotiation has been specified using either HTTP headers or other methods. -- diff --git a/core/requirements/core/REQ_process-execute-success-sync-one.adoc b/core/requirements/core/REQ_process-execute-success-sync-one.adoc index b2a4f926..30efd818 100644 --- a/core/requirements/core/REQ_process-execute-success-sync-one.adoc +++ b/core/requirements/core/REQ_process-execute-success-sync-one.adoc @@ -7,7 +7,7 @@ identifier:: /req/core/process-execute-sync-one [.component,class=conditions] -- . The <> is synchronous, -. The number of requested (whether <> or <>) outputs in the <> is 1. +. The number of requested (whether <> or <>) outputs in the <> is 1. -- [.component,class=part] diff --git a/core/requirements/local-filtering/REQ_local-filtering.adoc b/core/requirements/local-filtering/REQ_local-filtering.adoc index bb80c721..4e95127e 100644 --- a/core/requirements/local-filtering/REQ_local-filtering.adoc +++ b/core/requirements/local-filtering/REQ_local-filtering.adoc @@ -6,12 +6,12 @@ identifier:: /req/local-filtering [.component,class=description] -- -To support the local filtering of data accessed from a <> before providing the data as <>: +To support the local filtering of data accessed from a <> before providing the data as <>: -- [.component,class=part] -- -The server SHALL support local filtering of input data, retrieved from a <>, based on the filtering parameters: +The server SHALL support local filtering of input data, retrieved from a <>, based on the filtering parameters: * filter, filterCrs, filterLang * bbox, bboxCrs diff --git a/core/requirements/ogc-process-description/REQ_data-access-apis.adoc b/core/requirements/ogc-process-description/REQ_data-access-apis.adoc index 1937ef9c..50044f41 100644 --- a/core/requirements/ogc-process-description/REQ_data-access-apis.adoc +++ b/core/requirements/ogc-process-description/REQ_data-access-apis.adoc @@ -6,7 +6,7 @@ identifier:: /req/ogc-process-description/data-access-apis [.component,class=part] -- -The list of possible <> that can be used to retrieve process input or output values from an OGC collection shall be indicated by the `dataAccessApi` parameter in the <>. +The list of possible <> that can be used to retrieve process input or output values from an OGC collection shall be indicated by the `dataAccessApi` parameter in the <>. -- [.component,class=part] diff --git a/core/requirements/remote-collections/REQ_remote-collections_access.adoc b/core/requirements/remote-collections/REQ_remote-collections_access.adoc index 38ebfa46..1221ec49 100644 --- a/core/requirements/remote-collections/REQ_remote-collections_access.adoc +++ b/core/requirements/remote-collections/REQ_remote-collections_access.adoc @@ -6,17 +6,17 @@ identifier:: /req/remote-collections/access [.component,class=description] -- -For referencing a <> as a source of <>: +For referencing a <> as a source of <>: -- [.component,class=part] -- -The server SHALL support accessing <> using at least one supported <>. +The server SHALL support accessing <> using at least one supported <>. -- [.component,class=part] -- -The server SHALL, in the <> and for each relevant input, indicate which <> can be used to retrieved input values for that input from the <>. +The server SHALL, in the <> and for each relevant input, indicate which <> can be used to retrieved input values for that input from the <>. -- ==== diff --git a/core/requirements/remote-collections/REQ_remote-collections_referencing.adoc b/core/requirements/remote-collections/REQ_remote-collections_referencing.adoc index b802e0d7..71bb97e4 100644 --- a/core/requirements/remote-collections/REQ_remote-collections_referencing.adoc +++ b/core/requirements/remote-collections/REQ_remote-collections_referencing.adoc @@ -6,7 +6,7 @@ identifier:: /req/remote-collections/referencing .component,class=description] -- -For referencing a <> as a source of <>: +For referencing a <> as a source of <>: -- [.component,class=part] @@ -16,12 +16,12 @@ The server SHALL support inputs in an <> [.component,class=part] -- -The value of the `collection` parameter SHALL be a URI identifying a <> from which <> are retrieved. +The value of the `collection` parameter SHALL be a URI identifying a <> from which <> are retrieved. -- [.component,class=part] -- -The URI path SHALL not extend past the collection element in order to allow the server to decide, based on the expected input value type from the <> and other factors, which supported <> should be employed to retrieved input values from the <>. +The URI path SHALL not extend past the collection element in order to allow the server to decide, based on the expected input value type from the <> and other factors, which supported <> should be employed to retrieved input values from the <>. -- ==== diff --git a/core/sections/clause_2_conformance.adoc b/core/sections/clause_2_conformance.adoc index 695cd9e5..118112d8 100644 --- a/core/sections/clause_2_conformance.adoc +++ b/core/sections/clause_2_conformance.adoc @@ -41,13 +41,13 @@ The _Core_ does not mandate the use of any specific process description language This class defines an information model, encoded in JSON, which may be used to specify the interface of a process including the inputs that the process expects and the outputs that the process will generate. -Besides the standard input types one might expect for a process (e.g. integer, string, double, etc.) this Standard defines the following conformance class: +Besides the standard input types one might expect for a process (e.g. integer, string, double, etc.) this Standard defines the following conformance class: -* <> +* <> that allows OGC API collections to be specified as process inputs. The <> class only supports collections that are local to the current deployment to be specified as process inputs. The following conformance class: -* <> +* <> extends the collection input requirements to support specifying remote collections as process inputs. @@ -61,7 +61,7 @@ In addition to supporting collections as process inputs, the following conforman * <> -defines requirements that allow process execution to be triggered by requesting output data using an standard <>. In this way, process execution becomes opaque, hidden behind a standard OGC data access API (e.g. features, coverages, etc.). +defines requirements that allow process execution to be triggered by requesting output data using an standard <>. In this way, process execution becomes opaque, hidden behind a standard OGC data access API (e.g. features, coverages, etc.). In the <> executing a process requires sending a JSON-encoded execution request to the server using the HTTP POST method. To support embedding process execution requests into other documents this Standard defines the: @@ -77,7 +77,7 @@ conformance class. Using the `profile` query parameter JSON-encoded responses c Three additional conformance classes are specified that extend the basic functionality defined in the _Core_ requirements class: -* <> for requesting a list of jobs with optional filtering capabilities, +* <> for requesting a list of jobs with optional filtering capabilities, * <> for cancelling active jobs or deleting completed jobs, and diff --git a/core/sections/clause_4_terms_and_definitions.adoc b/core/sections/clause_4_terms_and_definitions.adoc index 79118c3e..fc5025bb 100644 --- a/core/sections/clause_4_terms_and_definitions.adoc +++ b/core/sections/clause_4_terms_and_definitions.adoc @@ -1,61 +1,69 @@ - +[[sc_terms]] == Terms, definitions and abbreviated terms +[[sc_terms_definitions]] === Terms and definitions -[[def-collection]] +[[def_collection]] ==== collection; OGC API collection (in the context of OGC APIs) A set of spatiotemporal data that may be available through one or more access mechanisms defined by https://www.ogc.org/standards[OGC API standards]. (https://docs.ogc.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial Data]) -[[def-collection-description]] +[[def_collection-description]] ==== collection description document -A resource accessible at the OGC API path `/collections/{collectionId}` that provides metadata about a <>. +A resource accessible at the OGC API path `/collections/{collectionId}` that provides metadata about a <>. +[[def_dataset]] ==== dataset A collection of data, published or curated by a single agent, and available for access or download in one or more representations. (https://www.w3.org/TR/vocab-dcat-2/[Data Catalog Vocabulary (DCAT) - Version 2]) +[[def_distribution]] ==== distribution A specific representation of a dataset. A dataset might be available in multiple distributions that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). (https://www.w3.org/TR/vocab-dcat-2/[Data Catalog Vocabulary (DCAT) - Version 2]) EXAMPLE: a downloadable file, an RSS feed or an API. +[[def_job]] ==== job The (processing) job is a server-side object created by a processing service for a particular process execution. A job may be latent in the case of synchronous execution or explicit in the case of asynchronous execution. Since the client has only oblique access to a processing job, a Job ID is used to monitor and control a job. +[[def_JSON]] ==== JSON JavaScript Object Notation is a lightweight text-based, data-interchange format. +[[def_link]] ==== link The term "link" is commonly used as substitute for URL or URI. In this Standard, "link" refers to an element described by the schema for a link as shown at <>. This is a JSON element containing properties such as "rel" (relation) and "href". The value of the "href" property is an URI. +[[def_link-header]] ==== link header HTTP Link header, as defined in <>. -[[def-local-collection]] +[[def_local-collection]] ==== local collection -A <> that is local to the <> <>. +A <> that is local to the <> <>. -[[def-data-access-mechanism]] +[[def_data-access-mechanism]] ==== OGC API data access mechanism -(in the context of OGC APIs) A mechanism defined by an OGC API Standard to access spatiotemporal data from a <>/ +(in the context of OGC APIs) A mechanism defined by an OGC API Standard to access spatiotemporal data from a <>/ EXAMPLE: https://docs.ogc.org/is/20-057/20-057.html[_OGC API - Tiles - Part 1: Core_], https://docs.ogc.org/DRAFTS/19-087.html[_OGC API - Coverages - Part 1: Core_], https://docs.ogc.org/DRAFTS/21-038r1.html[_OGC API - Discrete Global Grid Systems - Part 1: Core_], https://docs.ogc.org/is/17-069r4/17-069r4.html[_OGC API - Features - Part 1: Core_], https://docs.ogc.org/is/19-086r6/19-086r6.html[_OGC API - Environmental Data Retrieval Standard_], https://docs.ogc.org/is/20-058/20-058.html[_OGC API - Maps - Part 1: Core_] -[[def-deployment]] +[[def_deployment]] ==== OGC API deployment An implementation of an https://www.ogc.org/standards/[OGC API Standard] that is accessible to users and other system(s) typically through the Web. +[[def_process]] ==== process A process _p_ is a function that for each input returns a corresponding output @@ -69,52 +77,57 @@ where stem:[X] denotes the domain of arguments stem:[x] and stem:[Y] denotes the The term "process" is one of the most used terms both in the information and geosciences domain. If not stated otherwise, this Standard uses the term process as an umbrella term for any algorithm, calculation or model that either generates new data or transforms some input data into output data as defined in section 4.1 of the OGC WPS 2.0 standard. +[[def_process-description]] ==== process description -A specific documented account of steps, roles, and rules involved in a computing process, often described using standard like the https://swagger.io/specification/[OpenAPI Standard]. +A specific documented account of steps, roles, and rules involved in a computing <>, often described using standard like the https://swagger.io/specification/[OpenAPI Standard]. +[[def_process_exection]] ==== process execution -The execution of a process is an action that calculates the outputs of a given process for a given set of data inputs. - +The execution of a <> is an action that calculates the outputs of a given process for a given set of data inputs. +[[def_process-input]] ==== process input -Process inputs are the arguments of a process and refer to data provided to a process. Each process input is an identifiable item. - +Process inputs are the arguments of a process and refer to data provided to a <>. Each process input is an identifiable item. +[[def_process-offering]] ==== process offering -A process offering is an identifiable process that may be executed on a particular service instance. A process offering contains a process description as well as service-specific information about the supported execution protocols (e.g. synchronous and asynchronous execution). +A process offering is an identifiable <> that may be executed on a particular service instance. A process offering contains a process description as well as service-specific information about the supported execution protocols (e.g. synchronous and asynchronous execution). +[[def_process-output]] ==== process output -Process outputs are the results of a process and refer to data returned by a process. Each process output is an identifiable item. +Process outputs are the selectable outputs of a <> and refer to data results returned by the execution of that process. Each process output is an identifiable item. -[[explicit-process-output]] +[[def_explicit-process-output]] ==== process output (explicitly requested) A process output that is defined in the <> and is explicitly specified using its identifier `{outputID}` in the "outputs" section of an <>. -[[implicit-process-output]] +[[def_implicit-process-output]] ==== process output (implicitly requested) A process output that is defined in the <> and is generated as a result of an <> where the "outputs" parameter has been omitted. Omitting the "outputs" parameters of an <> is equivalent to explicitly requesting all of the outputs defined in the <> -[[def-remote-collections]] +[[def_remote-collections]] ==== remote collections -A <> that is available from an external OGC API deployment different from the deployment whose process is being executed. +A <> that is available from an external OGC API deployment different from the deployment whose process is being executed. +[[def_REST]] ==== REST The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST focuses on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application. An API that conforms to the REST architectural principles/constraints is called a *RESTful API*. (Source: https://docs.ogc.org/is/18-088/18-088.html#_rest[OGC 18-088]) -[[value-source-server]] +[[def_value-source-server]] ==== Value source server -A server that implements one or more <> for accessing data from an <>. The server acts as a source of values that are passed to a process being executed by an implementation of this Standard. +A server that implements one or more <> for accessing data from an <>. The server acts as a source of values that are passed to a process being executed by an implementation of this Standard. +[[sc_terms_abbreviations]] === Abbreviated Terms API:: Application Programming Interface diff --git a/core/sections/clause_7_core.adoc b/core/sections/clause_7_core.adoc index 34334875..001eb58a 100644 --- a/core/sections/clause_7_core.adoc +++ b/core/sections/clause_7_core.adoc @@ -1020,7 +1020,7 @@ The way a server responds to <> is determi The following table maps the possible responses based on the combinations of these execute parameters. The column headers denote: . *Negotiated execute mode*: see <> -. *Requested # outputs*: The number of requested (whether <> or <>) outputs in the <> +. *Requested # outputs*: The number of requested (whether <> or <>) outputs in the <> . *Return preference*: The negotiated <> . *Response HTTP code*: The https://datatracker.ietf.org/doc/html/rfc2616#section-6.1.1[HTTP status code] that the server should generate in this context. . *Response headers*: Any required https://datatracker.ietf.org/doc/html/rfc2616#section-14[HTTP headers] that the server must include in this context. @@ -1103,7 +1103,7 @@ The above table shows all possible combinations of execute parameters that are s [[implicit-explicit-outputs]] [NOTE] ==== -A process output may be requested <> or <> in an <> . +A process output may be requested <> or <> in an <> . ==== [[sync_note_4]] @@ -1424,7 +1424,7 @@ NOTE: The size of the value may be determined without actually transmitting the include::../requirements/core/REQ_job-result-op-0th.adoc[] -In other words, regardless of the defined cardinality of an output, the first result (i.e. at index value 0) is always accessible. If, however, the cardinality of the output is 1 (i.e. `maxOccurs=1`) then attempting to retrieve an output value using any index value other than _0_ will result in an HTTP 404 exception. Also, if the cardinality of the output is greater than one (i.e. `maxOccurs>1`) then other non-zero index values may be used to retrieve output values. However, out-of-bounds index values will results in an HTTP 404 exception (see requirement: <>). +In other words, regardless of the defined cardinality of an output, the first result (i.e. at index value 0) is always accessible. If, however, the cardinality of the output is 1 (i.e. `maxOccurs=1`) then attempting to retrieve an output value using any index value other than _0_ will result in an HTTP 404 exception. Also, if the cardinality of the output is greater than one (i.e. `maxOccurs>1`) then other non-zero index values may be used to retrieve output values. However, out-of-bounds index values will results in an HTTP 404 exception (see requirement: <>). ==== Response @@ -1432,7 +1432,7 @@ In other words, regardless of the defined cardinality of an output, the first re The way a server responds when retrieving job results depends on: -* The number of outputs requested (whether <> or <>) in an <>. +* The number of outputs requested (whether <> or <>) in an <>. * The negotiated content type for the response (via the https://www.rfc-editor.org/rfc/rfc2616#section-14.1[HTTP Accept] header) or lack thereof, * Any negotiated client preferences (via the HTTP Prefer header). * Whether an output is single-valued (i.e. `maxOccurs=1`) or multi-valued (i.e. `maxOccurs>1`). @@ -1441,7 +1441,7 @@ The following table maps the possible responses based on the combinations of par The column headers in the following table denote: -. *Requested # outputs*: The number of outputs requested (whether <> or <>) in the <>. +. *Requested # outputs*: The number of outputs requested (whether <> or <>) in the <>. . *Output cardinality*: The maximum number of values that can be generated for this output. . *Access path*: The API endpoint from which the result(s) can be retrieved. . *Return preference*: The negotiated <>. diff --git a/core/sections/clause_8_collections.adoc b/core/sections/clause_8_collections.adoc index c655360d..faf87603 100644 --- a/core/sections/clause_8_collections.adoc +++ b/core/sections/clause_8_collections.adoc @@ -5,15 +5,15 @@ ==== Overview -The _Collection Input_ Requirements Class supports specifying as an input to a process an <> via using one or more <>. Specifically, the processing server acts as a client and fetches values from the <> using one of the available <> and then feeds the fetched values as input values to the process being executed. The server from which input values are retrieved is referred to as the <>. +The _Collection Input_ Requirements Class supports specifying as an input to a process an <> via using one or more <>. Specifically, the processing server acts as a client and fetches values from the <> using one of the available <> and then feeds the fetched values as input values to the process being executed. The server from which input values are retrieved is referred to as the <>. -Unless an implementation also conforms to the <> conformance class, only <> that are locally accessible in the current <> are supported. +Unless an implementation also conforms to the <> conformance class, only <> that are locally accessible in the current <> are supported. -Unless an implementation also conforms to the <> conformance class, filtering of values retrieved from an <> is performed by the <>. +Unless an implementation also conforms to the <> conformance class, filtering of values retrieved from an <> is performed by the <>. include::../requirements/requirements_class_collection-input.adoc[] -The following requirements describe how an <> references an <> and how an implementation requests data from that collection to use as input to a process. +The following requirements describe how an <> references an <> and how an implementation requests data from that collection to use as input to a process. ==== Referencing a collection @@ -23,7 +23,7 @@ include::../requirements/collection-input/REQ_collection-input_referencing.adoc[ ===== Overview -The following requirements describe how to access data from an <> and the ability of an implementation to modify the accessed data by first applying filters, selecting a subset of fields or deriving new fields before providing the data as input to a process. +The following requirements describe how to access data from an <> and the ability of an implementation to modify the accessed data by first applying filters, selecting a subset of fields or deriving new fields before providing the data as input to a process. include::../requirements/collection-input/REQ_collection-input_access.adoc[] @@ -32,7 +32,7 @@ include::../requirements/collection-input/REQ_collection-input_access.adoc[] include::../requirements/collection-input/REQ_collection-input_filtering.adoc[] -NOTE: The server may also do some intelligent remapping of parameters. For example, if a `bbox` parameter is specified in the execute request, but the <> only supports the `geometry` parameter, the implementation may convert the bounding box to a 4-point polygon and map the specified `bbox` parameter to the `geometry` parameter supported by the <>. +NOTE: The server may also do some intelligent remapping of parameters. For example, if a `bbox` parameter is specified in the execute request, but the <> only supports the `geometry` parameter, the implementation may convert the bounding box to a 4-point polygon and map the specified `bbox` parameter to the `geometry` parameter supported by the <>. **Parameter filter** @@ -150,7 +150,7 @@ The _Remote Collections_ Requirements Class allows to reference a remote OGC API include::../requirements/requirements_class_remote-collections.adoc[] -The following requirements describe how an <> references a <> as a source of input values to a process. +The following requirements describe how an <> references a <> as a source of input values to a process. ==== Referencing a remote collection @@ -177,17 +177,17 @@ See: <> ==== Overview -The _Collection Output_ Requirements Class specifies how the execution of a process can be triggered as the result of requesting output data using an <>. +The _Collection Output_ Requirements Class specifies how the execution of a process can be triggered as the result of requesting output data using an <>. This provides an alternative to the synchronous and asynchronous execution mechanisms defined in this Standard for which spatial, temporal and other filtering parameters would need to be hardcoded in the <>. When lengthy batch processing is not desirable, completely new <> each with different spatial, temporal and other filtering parameters and returning a partial output would need to be continuously re-submitted. -This conformance class supports submitting an <> once and then accessing the output using <> in a manner that is completely agnostic of process execution. +This conformance class supports submitting an <> once and then accessing the output using <> in a manner that is completely agnostic of process execution. Compared to separate <>, this mechanism makes it easier for implementations to optimize for scenarios where small partial outputs are streamed from the same pre-established processing pipeline. Parsing the <>, validating inputs, and handshakes with remote components only needs to be performed once. An implementation could also preempt future requests based on past requests, offsetting the latency of a complex processing pipeline. include::../requirements/requirements_class_collection-output.adoc[] -The following requirements describe an execution mechanism that triggers on-demand processing for particular spatial, temporal and other filtering parameters and results in one or more references to a <> that provides links to request output data using standard <>. +The following requirements describe an execution mechanism that triggers on-demand processing for particular spatial, temporal and other filtering parameters and results in one or more references to a <> that provides links to request output data using standard <>. ==== Parameter `response` @@ -203,7 +203,7 @@ include::../requirements/collection-output/REQ_collection-output_response-respon include::../requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc[] -This Standard does not impose any particular approach to materializing output <> resulting from a process execution request. +This Standard does not impose any particular approach to materializing output <> resulting from a process execution request. include::../recommendations/collection-output/PER_collection-output_static.adoc[] @@ -218,9 +218,9 @@ include::../recommendations/collection-output/PER_collection-output_expiry.adoc[ ==== Overview -As described in <>, implementation of this Standard that support <> rely on the <> to perform any input data filtering specified in an execution request. +As described in <>, implementation of this Standard that support <> rely on the <> to perform any input data filtering specified in an execution request. -Servers that implement this Requirements Class, support local filtering in those instances where the <> does not support the input data filtering requested in the execution request. +Servers that implement this Requirements Class, support local filtering in those instances where the <> does not support the input data filtering requested in the execution request. include::../requirements/requirements_class_local-filtering.adoc[] diff --git a/core/sections/clause_9_process-description.adoc b/core/sections/clause_9_process-description.adoc index 1df6981d..99a1f802 100644 --- a/core/sections/clause_9_process-description.adoc +++ b/core/sections/clause_9_process-description.adoc @@ -101,7 +101,7 @@ NOTE: This schema can also be obtained from https://raw.githubusercontent.com/op [[sc_data_classes]] ==== Data classes -One common input type that a process might accept is a https://docs.ogc.org/is/17-069r4/17-069r4.html#_collection_[feature collection] indicating that the process will operate over the items of the collection. This implies that the process will have certain expectations about the structure of the collection with regard to which properties the collection contains, their types, etc. To properly handle any arbitrary input collection, a process would need to inspect the structure of the collection to ensure that all the expected properties with the expected schemas and semantics are present. To alleviate the server from having to perform such a tedious, and perhaps computationally expensive, validation step this Standard introduces the concept of the _Data Class_ via the `dataClasses` parameter. +One common input type that a process might accept is a https://docs.ogc.org/is/17-069r4/17-069r4.html#_collection_[feature collection] indicating that the process will operate over the items of the collection. This implies that the process will have certain expectations about the structure of the collection with regard to which properties the collection contains, their types, etc. To properly handle any arbitrary input collection, a process would need to inspect the structure of the collection to ensure that all the expected properties with the expected schemas and semantics are present. To alleviate the server from having to perform such a tedious, and perhaps computationally expensive, validation step this Standard introduces the concept of the _Data Class_ via the `dataClasses` parameter. include::../requirements/ogc-process-description/REQ_data-classes.adoc[] @@ -127,7 +127,7 @@ This clause started by introducing the concept of the _Data Class_ in relation t [[sc_data_access_APIs]] ==== Data access APIs -If a server supports <> and/or <>, the `dataAccessAPIs` parameters in the process description allows the server to indicate, on a per-input/output basis, which <> are supported for providing input values to the process or retrieving output values from the process. +If a server supports <> and/or <>, the `dataAccessAPIs` parameters in the process description allows the server to indicate, on a per-input/output basis, which <> are supported for providing input values to the process or retrieving output values from the process. include::../requirements/ogc-process-description/REQ_data-access-apis.adoc[] @@ -165,7 +165,7 @@ The following JSON Schema fragment illustrates how to define an input that allow include::../recommendations/ogc-process-description/REC_format-key.adoc[] -Processes that perform geospatial processing can be expected to have geometric and feature input types. In JSON, geometries, features, and feature collections are commonly encoded using https://datatracker.ietf.org/doc/html/rfc7946[GeoJSON]. Rather the requiring processes descriptions to embed or reference the full schemas for https://datatracker.ietf.org/doc/html/rfc7946[GeoJSON] geometries, features or feature collections, this Standard defines a common set of convenience tokens that can be used instead. +Processes that perform geospatial processing can be expected to have geometric and feature input types. In JSON, geometries, features, and feature collections are commonly encoded using https://datatracker.ietf.org/doc/html/rfc7946[GeoJSON]. Rather the requiring processes descriptions to embed or reference the full schemas for https://datatracker.ietf.org/doc/html/rfc7946[GeoJSON] geometries, features or feature collections, this Standard defines a common set of convenience tokens that can be used instead. The <> defines a https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7[set of values] for the `format` key. This Standard extends this list by defining the following additional key values for use specifically in OGC process descriptions. diff --git a/extensions/deploy_replace_undeploy/standard/sections/clause_4_terms_and_definitions.adoc b/extensions/deploy_replace_undeploy/standard/sections/clause_4_terms_and_definitions.adoc index 7807e494..26e24868 100644 --- a/extensions/deploy_replace_undeploy/standard/sections/clause_4_terms_and_definitions.adoc +++ b/extensions/deploy_replace_undeploy/standard/sections/clause_4_terms_and_definitions.adoc @@ -1,24 +1,30 @@ - +[[sc_terms]] == Terms, definitions and abbreviated terms +[[sc_terms_definitions]] === Terms and definitions +[[def_execution-unit]] ==== Execution unit A component containing a process that an implementation of the Processes API Part 1 can run. +[[def_deploy]] ==== Deploy Deploy refers to installing a desired execution unit onto a Processes API server so that client applications can interact with it as a process using the Processes API Part 1 Standard. +[[def_replace]] ==== Replace Replace refers to upgrading a deployed process from a Processes API implementation. +[[def_undeploy]] ==== Undeploy Undeploy refers to removing a deployed process from a Processes API implementation so that it does not appear as an available process. +[[sc_terms_abbreviations]] === Abbreviated Terms CWL:: Common Workflow Language diff --git a/extensions/job_management/standard/sections/clause_4_terms_and_definitions.adoc b/extensions/job_management/standard/sections/clause_4_terms_and_definitions.adoc index b81b8bf2..2911977a 100644 --- a/extensions/job_management/standard/sections/clause_4_terms_and_definitions.adoc +++ b/extensions/job_management/standard/sections/clause_4_terms_and_definitions.adoc @@ -1,10 +1,12 @@ - +[[sc_terms]] == Terms, definitions and abbreviated terms +[[sc_terms_definitions]] === Terms and definitions See <>, Clause 4.1. +[[sc_terms_abbreviations]] === Abbreviated Terms -See <>, Clause 4.2. \ No newline at end of file +See <>, Clause 4.2. diff --git a/extensions/workflows/21-009.adoc b/extensions/workflows/21-009.adoc index a4078e85..4485d667 100644 --- a/extensions/workflows/21-009.adoc +++ b/extensions/workflows/21-009.adoc @@ -5,16 +5,17 @@ :status: swg-draft :committee: technical :draft: 1.0 -:external-id: http://www.opengis.net/doc/is/ogcapi-processes-3/0.0 +:external-id: https://www.opengis.net/doc/is/ogcapi-processes-3/0.0 :docnumber: 21-009 :received-date: 2029-03-30 :issued-date: 2029-03-30 :published-date: 2029-03-30 :fullname: Jérôme Jacovella-St-Louis :fullname_2: Panagiotis (Peter) A. Vretanos +:fullname_3: Francis Charette-Migneault :docsubtype: implementation :keywords: ogcdoc, OGC document, API, openapi, html, ogcapi -:submitting-organizations: Ecere Corporation; CubeWerx Inc.; GeoLabs; University of Calgary; Pangaea Innovations Pty. Ltd.; Natural Resources Canada; EOX IT Services GmbH; Universitat Autònoma de Barcelona (CREAF); Technologies Luqia, Centre de Recherche Informatique de Montréal (CRIM); 52°North Spatial Information Research GmbH; European Space Agency (ESA); US Army Geospatial Center (AGC); Hexagon; Haute École d'Ingénierie et de Gestion du Canton de Vaud (HEIG-VD); Laboratoire des Sciences et Techniques de l'information de la Communication et de la Connaissance / Centre national de la recherche scientifique (Lab-STICC CNRS) +:submitting-organizations: Ecere Corporation; CubeWerx Inc.; Technologies Luqia, Centre de Recherche Informatique de Montréal (CRIM); GeoLabs; University of Calgary; Pangaea Innovations Pty. Ltd.; Natural Resources Canada; EOX IT Services GmbH; Universitat Autònoma de Barcelona (CREAF); 52°North Spatial Information Research GmbH; European Space Agency (ESA); US Army Geospatial Center (AGC); Hexagon; Haute École d'Ingénierie et de Gestion du Canton de Vaud (HEIG-VD); Laboratoire des Sciences et Techniques de l'information de la Communication et de la Connaissance / Centre national de la recherche scientifique (Lab-STICC CNRS) :docfile: document.adoc :mn-document-class: ogc :mn-output-extensions: xml,html,doc,pdf @@ -44,14 +45,10 @@ include::sections/clause_6_overview.adoc[] include::sections/clause_7_nested_processes.adoc[] -include::sections/clause_8_collection_input.adoc[] - include::sections/clause_9_input_output_fields_modifiers.adoc[] include::sections/clause_10_deployable_workflow.adoc[] -include::sections/clause_11_collection_output.adoc[] - include::sections/clause_12_cwl_workflows.adoc[] include::sections/clause_13_openeo_workflows.adoc[] diff --git a/extensions/workflows/recommendations/collection-output/PER_collection-output_expiry.adoc b/extensions/workflows/recommendations/collection-output/PER_collection-output_expiry.adoc deleted file mode 100644 index 53f67ebc..00000000 --- a/extensions/workflows/recommendations/collection-output/PER_collection-output_expiry.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[permission] -==== -[%metadata] -identifier:: /per/collection-output/expiry -description:: Collection output resources are ephemeral in nature: -part:: An Implementation MAY return a _410 Gone_ HTTP status code for resources associated with a previous _Collection Output_ response (i.e., a landing page, a collection, or any resources linked from either) if a significant period of time has elapsed since both the original request and any further associated data access request from the client. -part:: An Implementation MAY redirect a client re-posting an identical or equivalent execution request for _Collection Output_ (e.g., after having received a 410 gone status) to the same location as a previous execution (expired and reinstated, or still valid), or to a new location. -==== diff --git a/extensions/workflows/requirements/collection-input/REQ_collection-input_collection-access.adoc b/extensions/workflows/requirements/collection-input/REQ_collection-input_collection-access.adoc deleted file mode 100644 index 5ddd88a8..00000000 --- a/extensions/workflows/requirements/collection-input/REQ_collection-input_collection-access.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-input/collection-access -description:: For executing workflow definitions referencing a collection as an input to a process: -part:: The Implementation SHALL support accessing local collections (as defined by _OGC API - Common - Part 2: Geospatial data_) accessible using at least one OGC API data access mechanisms (e.g., _OGC API - Tiles, Coverages, DGGS, Features, EDR, Maps_) as an input to a process. -==== - -NOTE: For local collections, the specification is agnostic to how data flows from the collection to the process. diff --git a/extensions/workflows/requirements/collection-input/REQ_collection-input_referenced-collection.adoc b/extensions/workflows/requirements/collection-input/REQ_collection-input_referenced-collection.adoc deleted file mode 100644 index ef58b491..00000000 --- a/extensions/workflows/requirements/collection-input/REQ_collection-input_referenced-collection.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-input/referenced-collection -description:: For referencing a collection as an input to a process: -part:: The Implementation SHALL support execution requests containing a `"collection"` key and a corresponding URI or Relative-URI value identifying an OGC API collection as an input to a process. -part:: The Implementation SHALL interpret Relative-URIs as relative to the parent process within which the containing collection object is nested. -==== diff --git a/extensions/workflows/requirements/collection-output/REQ_collection-output_collection-response.adoc b/extensions/workflows/requirements/collection-output/REQ_collection-output_collection-response.adoc deleted file mode 100644 index 5e3f97f6..00000000 --- a/extensions/workflows/requirements/collection-output/REQ_collection-output_collection-response.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-output/collection-response -description:: For initiating the execution of a workflow and retrieving its output as an OGC API collection: -part:: For requests generating or selecting a single output, the Implementation SHALL return a 303 _See Other_ HTTP status code together with a _Location:_ response header redirecting to a collection description document as defined in _OGC API - Common - Part 2: Geospatial data_ as a response to a request specifying a `response=collection` query parameter. -part:: For requests generating multiple outputs which do not select a particular output, the Implementation SHALL return a 400 status error as a response to a request specifying a `response=collection` query parameter. -part:: The collection description towards which the client is redirected SHALL link to at least one OGC API data access mechanism such as _OGC API - Tiles, DGGS, Coverages, Features, EDR, Maps_... -==== diff --git a/extensions/workflows/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc b/extensions/workflows/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc deleted file mode 100644 index 119a09ec..00000000 --- a/extensions/workflows/requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-output/data-access-mechanisms -description:: For triggering processing and returning resulting output data as a response to data access requests: -part:: The Implementation SHALL support at least one OGC API data access mechanisms (e.g., _OGC API - Tiles, Coverages, DGGS, Features, EDR, Maps_) corresponding to the links returned from a a `response=collection` or `response=landingPage` request. -part:: The Implementation SHALL trigger the processing required to respond to the request with considerations for the area, time and/or resolution of interest associated with the request. -==== diff --git a/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page-response.adoc b/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page-response.adoc deleted file mode 100644 index aeb67510..00000000 --- a/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page-response.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-output/landing-page-response -description:: For initiating the execution of a workflow and retrieving its output as an OGC API dataset landing page: -part:: The Implementation SHALL return a 303 _See Other_ HTTP status code together with a _Location:_ response header redirecting to an OGC API dataset landing page as defined in _OGC API - Common - Part 1: Core_ as a response to a request specifying a `response=landingPage` query parameter. -part:: The landing page towards which the client is redirected SHALL contain at link to a list of available collections at `../collections` as defined in _OGC API - Processes - Part 2: Geospatial data_. -part:: The collections linked from the landing page towards which the client is redirected SHALL link to at least one OGC API data access mechanism such as _OGC API - Tiles, DGGS, Coverages, Features, EDR, Maps_... -==== diff --git a/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page.adoc b/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page.adoc deleted file mode 100644 index 90b214f6..00000000 --- a/extensions/workflows/requirements/collection-output/REQ_collection-output_landing-page.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-output/landing-page -description:: For initiating the execution of a workflow and retrieving its output as an OGC API dataset landing page: -part:: The Implementation SHALL return an OGC API dataset landing page as defined in _OGC API - Common - Part 1: Core_ as a response to a request specifying a `response=landingPage` query parameter. -part:: The returned landing page SHALL contain at link to a list of available collections at `../collections` as defined in _OGC API - Processes - Part 2: Geospatial data_. -part:: The returned landing page and the linked collections SHALL link to at least one OGC API data access mechanism such as _OGC API - Tiles, DGGS, Coverages, Features, EDR, Maps_... -==== diff --git a/extensions/workflows/requirements/collection-output/REQ_collection-output_response-query-parameter.adoc b/extensions/workflows/requirements/collection-output/REQ_collection-output_response-query-parameter.adoc deleted file mode 100644 index 7d239174..00000000 --- a/extensions/workflows/requirements/collection-output/REQ_collection-output_response-query-parameter.adoc +++ /dev/null @@ -1,7 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/collection-output/response-query-parameter -description:: For initiating the execution of a workflow and retrieving its output as an OGC API collection: -part:: The Implementation SHALL support the `response` query parameter with `collection` and `landingPage` as possible values. -==== diff --git a/extensions/workflows/requirements/deployable-workflows/REQ_deployable-workflows_deploying-workflow.adoc b/extensions/workflows/requirements/deployable-workflows/REQ_deployable-workflows_deploying-workflow.adoc index e1f68bce..b293611f 100644 --- a/extensions/workflows/requirements/deployable-workflows/REQ_deployable-workflows_deploying-workflow.adoc +++ b/extensions/workflows/requirements/deployable-workflows/REQ_deployable-workflows_deploying-workflow.adoc @@ -3,6 +3,6 @@ [%metadata] identifier:: /req/deployable-workflows/deploying-workflow description:: For deploying workflow definitions defined as an execution request: -part:: The Implementation SHALL support deploying a workflow definition as a process using the POST method mechanism described in _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ with a payload consisting of an _OGC API - Processes - Part 1: Core_ execution request (`Content-Type: application/json`, unless a specific media type execution requests is allocated), with support for any any extensions defined in this specification for which conformance is declared. -part:: If the _OGC Application Package_ conformance class is supported, the Implementation SHALL also support deploying a workflow definition as a process using the POST method mechanism described in _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ with the `executionUnit` of the OGC Application Package payload (`Content-Tyep: application/ogcapppkg+json`) consisting of an _OGC API - Processes - Part 1: Core_ execution request, with support for any any extensions defined in this specification for which conformance is declared. +part:: The Implementation SHALL support deploying a workflow definition as a process using the POST method mechanism described in <> with a payload consisting of an _OGC API - Processes - Part 1: Core_ execution request (`Content-Type: application/json`, unless a specific media type execution requests is allocated), with support for any any extensions defined in this specification for which conformance is declared. +part:: If the _OGC Application Package_ conformance class is supported, the Implementation SHALL also support deploying a workflow definition as a process using the POST method mechanism described in <> with the `executionUnit` of the OGC Application Package payload (`Content-Tyep: application/ogcapppkg+json`) consisting of an _OGC API - Processes - Part 1: Core_ execution request, with support for any any extensions defined in this specification for which conformance is declared. ==== diff --git a/extensions/workflows/requirements/remote-collections/REQ_remote-collections_collection-access.adoc b/extensions/workflows/requirements/remote-collections/REQ_remote-collections_collection-access.adoc deleted file mode 100644 index 56320af1..00000000 --- a/extensions/workflows/requirements/remote-collections/REQ_remote-collections_collection-access.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/remote-collections/collection-access -description:: For executing workflow definitions referencing a collection as an input to a process: -part:: The Implementation SHALL support accessing a remote OGC API collection using one or more OGC API data access mechanisms (e.g., _OGC API - Tiles, Coverages, DGGS, Features, EDR, Maps_...) as an input to a process. -==== - -TODO: Separate conformance classes may need to be defined for each specification to clarify for which processing services can act as a client to supporting collection access to avoid clients defining invalid workflows. diff --git a/extensions/workflows/requirements/remote-collections/REQ_remote-collections_referenced-collection.adoc b/extensions/workflows/requirements/remote-collections/REQ_remote-collections_referenced-collection.adoc deleted file mode 100644 index e142260f..00000000 --- a/extensions/workflows/requirements/remote-collections/REQ_remote-collections_referenced-collection.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[requirement] -==== -[%metadata] -identifier:: /req/remote-collections/referenced-collection -description:: For referencing a remote collection as an input to a process: -part:: The Implementation SHALL support execution requests containing a `"collection"` key and a corresponding URI or Relative-URI value identifying an authorized OGC API collection as an input to a process. -part:: If the Implementation conforms to the _Nested Process_ conformance class, it SHALL also support execution requests containing a `"process"` key and a corresponding URI or Relative-URI value identifying an authorized remote process supporting the _Collection Output_ conformance class as an input to another process. -part:: The Implementation SHALL interpret Relative-URIs as relative to the parent process within which the containing collection or process object is nested. -==== diff --git a/extensions/workflows/requirements/requirements_class_collection-input.adoc b/extensions/workflows/requirements/requirements_class_collection-input.adoc deleted file mode 100644 index 2ab258d6..00000000 --- a/extensions/workflows/requirements/requirements_class_collection-input.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[[rc_collection-input]] -[requirements_class] -==== -[%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input -subject:: Collection Input -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers (optional) -==== diff --git a/extensions/workflows/requirements/requirements_class_collection-output.adoc b/extensions/workflows/requirements/requirements_class_collection-output.adoc deleted file mode 100644 index d6f1c2af..00000000 --- a/extensions/workflows/requirements/requirements_class_collection-output.adoc +++ /dev/null @@ -1,23 +0,0 @@ -[[rc_collection-output]] -[requirements_class] -==== -[%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-output -subject:: Collection Output -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core -inherit:: http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections -inherit:: http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/geodata-tilesets (optional) -inherit:: http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core (optional) -inherit:: http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/core (optional) -inherit:: http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-scaling (optional) -inherit:: http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-subset (optional) -inherit:: http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-rangesubset (optional) -inherit:: http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/data-retrieval (optional) -inherit:: http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/zone-query (optional) -inherit:: http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/core (optional) -inherit:: http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/collections (optional) -inherit:: http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/core (optional) -inherit:: http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/spatial-subset (optional) -inherit:: http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/datetime (optional) -inherit:: http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/scaling (optional) -==== diff --git a/extensions/workflows/requirements/requirements_class_cwl-workflows.adoc b/extensions/workflows/requirements/requirements_class_cwl-workflows.adoc index 70e3c496..47c89817 100644 --- a/extensions/workflows/requirements/requirements_class_cwl-workflows.adoc +++ b/extensions/workflows/requirements/requirements_class_cwl-workflows.adoc @@ -2,8 +2,8 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/cwl-workflows +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/cwl-workflows subject:: Common Workflow Language Definitions -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core -inherit:: Common Workflow Language <> +inherit:: <> +inherit:: <> ==== diff --git a/extensions/workflows/requirements/requirements_class_deployable-workflows.adoc b/extensions/workflows/requirements/requirements_class_deployable-workflows.adoc index 0cb6d1a1..7813052d 100644 --- a/extensions/workflows/requirements/requirements_class_deployable-workflows.adoc +++ b/extensions/workflows/requirements/requirements_class_deployable-workflows.adoc @@ -2,14 +2,14 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/deployable-workflows +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/deployable-workflows subject:: Deployable Workflows -inherit:: http://www.opengis.net/spec/ogcapi-processes-2/0.0/req/deploy-replace-undeploy -inherit:: http://www.opengis.net/spec/ogcapi-processes-2/0.0/req/ogcapppkg (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-processes (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers (optional) +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> (optional) ==== diff --git a/extensions/workflows/requirements/requirements_class_input-fields-modifiers.adoc b/extensions/workflows/requirements/requirements_class_input-fields-modifiers.adoc index 85928f9b..6537a998 100644 --- a/extensions/workflows/requirements/requirements_class_input-fields-modifiers.adoc +++ b/extensions/workflows/requirements/requirements_class_input-fields-modifiers.adoc @@ -2,8 +2,8 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers subject:: Input Fields Modifiers -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core -inherit:: http://www.opengis.net/spec/ogcapi-features-3/0.0/req/features-filter (optional) +inherit:: <> +inherit:: <> (optional) ==== diff --git a/extensions/workflows/requirements/requirements_class_nested-processes.adoc b/extensions/workflows/requirements/requirements_class_nested-processes.adoc index 26484f87..973942b7 100644 --- a/extensions/workflows/requirements/requirements_class_nested-processes.adoc +++ b/extensions/workflows/requirements/requirements_class_nested-processes.adoc @@ -2,11 +2,11 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes subject:: Nested Processes -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input (optional) -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections (optional) +inherit:: <> +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> (optional) +inherit:: <> (optional) ==== diff --git a/extensions/workflows/requirements/requirements_class_openeo-workflows.adoc b/extensions/workflows/requirements/requirements_class_openeo-workflows.adoc index 99c8102e..beb0a9db 100644 --- a/extensions/workflows/requirements/requirements_class_openeo-workflows.adoc +++ b/extensions/workflows/requirements/requirements_class_openeo-workflows.adoc @@ -2,8 +2,8 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/openeo-workflows +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/openeo-workflows subject:: OpenEO Process Graphs Workflows -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core +inherit:: <> inherit:: OpenEO Process Graphs <> ==== diff --git a/extensions/workflows/requirements/requirements_class_output-fields-modifiers.adoc b/extensions/workflows/requirements/requirements_class_output-fields-modifiers.adoc index 0d963175..fca7e7df 100644 --- a/extensions/workflows/requirements/requirements_class_output-fields-modifiers.adoc +++ b/extensions/workflows/requirements/requirements_class_output-fields-modifiers.adoc @@ -2,7 +2,7 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers subject:: Output Fields Modifiers -inherit:: http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core +inherit:: <> ==== diff --git a/extensions/workflows/requirements/requirements_class_remote-collections.adoc b/extensions/workflows/requirements/requirements_class_remote-collections.adoc deleted file mode 100644 index 20619ece..00000000 --- a/extensions/workflows/requirements/requirements_class_remote-collections.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[[rc_remote-collections]] -[requirements_class] -==== -[%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections -subject:: Remote Collections -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-process (optional) -==== diff --git a/extensions/workflows/requirements/requirements_class_remote-core-processes.adoc b/extensions/workflows/requirements/requirements_class_remote-core-processes.adoc index cebe153b..4b8130b8 100644 --- a/extensions/workflows/requirements/requirements_class_remote-core-processes.adoc +++ b/extensions/workflows/requirements/requirements_class_remote-core-processes.adoc @@ -2,7 +2,7 @@ [requirements_class] ==== [%metadata] -identifier:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-core-processes +identifier:: https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-core-processes subject:: Remote Core Processes -inherit:: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes +inherit:: <> ==== diff --git a/extensions/workflows/sections/annex-b-coastal-erosion.adoc b/extensions/workflows/sections/annex-b-coastal-erosion.adoc index ebc4615c..b4ec290f 100644 --- a/extensions/workflows/sections/annex-b-coastal-erosion.adoc +++ b/extensions/workflows/sections/annex-b-coastal-erosion.adoc @@ -2,10 +2,14 @@ == Coastal Erosion Susceptibility Example Workflow This annex presents a sample workflow predicting the susceptibility of coastal erosion from four data sources. -This workflow (purely intended as a demonstrative example, not to be scientificaly accurate in any way), was assembled in collaboration with Perry Peterson and Marta Padilla Ruiz from the University of Calgary +This workflow (purely intended as a demonstrative example, not to be scientifically accurate in any way), +was assembled in collaboration with Perry Peterson and Marta Padilla Ruiz from the University of Calgary in the context of the OGC Federated Marine SDI Phase 3 Innovation Program initiative. -It demonstrates the use of the _Nested Processes_, _Collection Input_, _Input fields modifiers_ and _Output fields modifiers_ conformance classes. +It demonstrates the use of the <>, +<> and <> +from this standard, combined to the +<> conformance class from <>. The expressions used to derive field values (`"properties"`) are written using the CQL2 language extended with a ternary conditional operator as found in the C programming language and its derivatives, as well as with the ability to return not only boolean values, but also numeric values. @@ -18,7 +22,7 @@ depending on whether the _Slope_ and _Aspect_ processes generating the data, or [#img-coastal-erosion-workflow] image::figures/coastal-erosion-workflow.png[Coastal Erosion Example Workflow] -.Coastal Erosion Example Workflow Exectution Request +.Coastal Erosion Example Workflow Execution Request [source,json] ---- { diff --git a/extensions/workflows/sections/annex-bibliography.adoc b/extensions/workflows/sections/annex-bibliography.adoc index 87954134..a614ae84 100644 --- a/extensions/workflows/sections/annex-bibliography.adoc +++ b/extensions/workflows/sections/annex-bibliography.adoc @@ -13,7 +13,7 @@ Springer LNCS is widely used in technical and computer science journals and othe [n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published) -[n] Web: Author Surname, A.: Title, http://Website-Url +[n] Web: Author Surname, A.: Title, https://Website-Url * [[[OGC2015,OGCTB12]]], _OGC: OGC Testbed 12 Annex B: Architecture_ (2015). diff --git a/extensions/workflows/sections/annex-history.adoc b/extensions/workflows/sections/annex-history.adoc index e4f7ba20..e2d9730a 100644 --- a/extensions/workflows/sections/annex-history.adoc +++ b/extensions/workflows/sections/annex-history.adoc @@ -7,4 +7,5 @@ |Date |Release |Editor | Primary clauses modified |Description |2020-10-19 |0.1 |J. St-Louis |all |initial draft |2022-10-19 |0.2 |J. St-Louis |all |reorganized into multiple conformance classes, using metanorma template, with more detailed descriptions and requirements +|2026-07-18 |0.3 |Francis Charette-Migneault |all |removed collection requirement classes now in core, update references to other standard references, apply https and define terms |=== diff --git a/extensions/workflows/sections/clause_0_front_material.adoc b/extensions/workflows/sections/clause_0_front_material.adoc index 1b927b09..ab7c88fe 100644 --- a/extensions/workflows/sections/clause_0_front_material.adoc +++ b/extensions/workflows/sections/clause_0_front_material.adoc @@ -41,7 +41,7 @@ through OGC API data delivery specifications such as _OGC API - Tiles_, _DGGS_, Conformance classes defined in this specification enable clients to integrate discovered data and processes as a workflow in an ad-hoc manner (without first requiring to deploy the workflow as a process), then drive the execution on-demand for a particular area, time and resolution of interest using a "pull" mechanism (pulling the final required output from the client, as opposed to a batch execution starting from source inputs of the first processing step). -The workflows defined with this specification can also be deployed as processes using the _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ extension. +The workflows defined with this specification can also be deployed as processes using the <> extension. == Submitters @@ -52,6 +52,7 @@ All questions regarding this submission should be directed to the editors or the | *Name* | *Affiliation* | Jérôme Jacovella-St-Louis (editor) | Ecere Corporation | Panagiotis (Peter) A. Vretanos (editor) | CubeWerx Inc. +| Francis Charette-Migneault (editor) | Technologies Luqia, Centre de Recherche Informatique de Montréal (CRIM) | Gérald Fenoy | GeoLabs | Perry Peterson | University of Calgary | Marta Padilla Ruiz | University of Calgary @@ -59,7 +60,6 @@ All questions regarding this submission should be directed to the editors or the | Ryan Ahola | Natural Resources Canada | Stephan Meißl | EOX IT Services GmbH | Joan Masó Pau | Universitat Autònoma de Barcelona (CREAF) -| Francis Charette-Migneault | Technologies Luqia, Centre de Recherche Informatique de Montréal (CRIM) | Benjamin Proß | 52°North Spatial Information Research GmbH | Claudio Iacopino | European Space Agency (ESA) | Jeff Harrison | US Army Geospatial Center (AGC) diff --git a/extensions/workflows/sections/clause_11_collection_output.adoc b/extensions/workflows/sections/clause_11_collection_output.adoc deleted file mode 100644 index 0c0f0e88..00000000 --- a/extensions/workflows/sections/clause_11_collection_output.adoc +++ /dev/null @@ -1,63 +0,0 @@ -[[section_collection_output]] -== Collection Output Conformance Class - -=== Requirement Class _Collection Output_ - -The _Collection Output_ conformance class specifies how clients can trigger the -execution of a process or workflow for a specific area, time and resolution of interest -as a result of requesting output data using OGC API data access mechanisms, such as -_OGC API - Tiles_, _DGGS_, _Coverages_, _Features_, _EDR_, or _Maps_. - -This provides an alternative to the synchronous and asynchronous execution mechanisms -defined in _OGC API - Processes - Part 1: Core_ for which area, time and resolution of interest -are hardcoded in the execution request. With _Core_, when lengthy batch processing is not desirable, -completely new execution requests returning a partial output must continuously be re-submitted. - -This conformance class allows to submit an execution request once and then access the output -using mechanisms widely supported by clients in a manner completely agnostic of process execution. - -Compared to separate execution requests, this mechanism makes it easier for implementations to optimize -for scenarios where clients will stream small partial outputs from the same pre-established processing -pipeline. Parsing the execution request, validating inputs, and handshakes with remote components of a workflow -only need to be performed once. An implementation could also preempt future requests based on past requests, -offsetting the latency of a complex distributed workflow. - -A collection document for the result generated from a workflow MAY provide a link to the source definition of that -workflow (link relation type: `http://www.opengis.net/def/rel/ogc/1.0/workflow`). - -A service MAY also implement the capability to deploy a workflow as a persistent collection e.g., by supporting a `POST` -method for the `/collections` end-point accepting a JSON workflow definition (execution request) as payload. - -include::../requirements/requirements_class_collection-output.adoc[] - -The following requirements describe an execution mechanism where a client is redirected (using a `303` _See Other_ HTTP -status code and a `Location:` header) -to an OGC API landing page or collection description document, -which provides links to request output data using standard OGC API data access mechanisms, triggering on-demand processing -for a particular area, time and resolution of interest. - -==== `response` query parameter - -include::../requirements/collection-output/REQ_collection-output_response-query-parameter.adoc[] - -==== Collection Response - -A request for a collection response is only valid for an execution request generating or selecting a single output -which can be retrieved using an OGC API data access mechanism. - -include::../requirements/collection-output/REQ_collection-output_collection-response.adoc[] - -==== Landing Page Response - -A request for a landing page response is valid for an execution request generating one or more outputs -which can be retrieved using an OGC API data access mechanism. - -include::../requirements/collection-output/REQ_collection-output_landing-page-response.adoc[] - -==== Collection Output expiry - -include::../recommendations/collection-output/PER_collection-output_expiry.adoc[] - -==== Data Access Mechanisms - -include::../requirements/collection-output/REQ_collection-output_data-access-mechanisms.adoc[] diff --git a/extensions/workflows/sections/clause_12_cwl_workflows.adoc b/extensions/workflows/sections/clause_12_cwl_workflows.adoc index 2f675a55..732dd087 100644 --- a/extensions/workflows/sections/clause_12_cwl_workflows.adoc +++ b/extensions/workflows/sections/clause_12_cwl_workflows.adoc @@ -5,10 +5,10 @@ The _Common Workflow Language Definitions_ conformance class specifies the use of the https://www.commonwl.org/v1.2/Workflow.html[Common Workflow Language (CWL) Workflow Description] as an alternative to an extended -_OGC API - Processes - Part 1: Core_ execution request to define an ad-hoc workflow +<> execution request to define an ad-hoc workflow (a workflow that is not first required to be deployed as a process before being executed). -The capability to deploy a CWL workflow as a process using _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ +The capability to deploy a CWL workflow as a process using <> is already covered by a conformance class of Part 2. *TODO*: Verify that a CWL conformance class already exists or is planned for _Part 2_. diff --git a/extensions/workflows/sections/clause_13_openeo_workflows.adoc b/extensions/workflows/sections/clause_13_openeo_workflows.adoc index 68202a1c..e8dc1031 100644 --- a/extensions/workflows/sections/clause_13_openeo_workflows.adoc +++ b/extensions/workflows/sections/clause_13_openeo_workflows.adoc @@ -8,7 +8,7 @@ https://openeo.org/documentation/1.0/developers/api/reference.html#section/Proce _OGC API - Processes - Part 1: Core_ execution request, to be executed in an ad-hoc manner (a workflow that is not first required to be deployed as a process before being executed). -The capability to deploy an OpenEO workflow definition as a process using _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ +The capability to deploy an OpenEO workflow definition as a process using <> is already covered by a conformance class of Part 2. *TODO*: Verify that an OpenEO conformance class already exists or is planned for _Part 2_. diff --git a/extensions/workflows/sections/clause_14_media_types.adoc b/extensions/workflows/sections/clause_14_media_types.adoc index c3b52da3..319f69d0 100644 --- a/extensions/workflows/sections/clause_14_media_types.adoc +++ b/extensions/workflows/sections/clause_14_media_types.adoc @@ -4,13 +4,15 @@ The following follow media types are referenced by this specification. * `application/json`: As with _OGC API - Processes - Part 1: Core_, used for the `Content-Type` of execution requests posted (`POST`) to `/processes/{processID}/execution`, - as well as to deploy workflow definitions using _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ by posting (`POST`) to `/processes`. + as well as to deploy workflow definitions using <> by posting (`POST`) to `/processes`. ** A new media type (`application/ogcmoaw+json` -- Modular OGC API Workflow JSON, `application/ogcexec+json`, `application/ogcexecreq+json`?) could be registered with IANA to specifically reference _OGC API - Processes_ execution requests. -* `application/ogcapppkg+json`: For deploying workflows for which an execution request is embedded in the executionUnit of an OGC Application Package as defined - in the relevant class of _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_. +* `application/ogcapppkg+json`: For deploying workflows for which an execution request is embedded in the executionUnit of an _OGC Application Package_ as defined + in the relevant class of <>. * `application/cwl+json`: Common Workflow Language JSON workflow definition, for ad-hoc execution of CWL. +* `application/cwl+yaml`: Common Workflow Language YAML workflow definition, for ad-hoc execution of CWL. + In addition, media types referenced by other OGC specifications normatively referenced by this specification are also relevant. diff --git a/extensions/workflows/sections/clause_1_scope.adoc b/extensions/workflows/sections/clause_1_scope.adoc index 645e468a..f23f3757 100644 --- a/extensions/workflows/sections/clause_1_scope.adoc +++ b/extensions/workflows/sections/clause_1_scope.adoc @@ -4,4 +4,4 @@ This document specifies an extension to _OGC API - Processes - Part 1: Core_ tha ad-hoc workflows, chain nested processes, refer to both local and external processes and collections of data accessible via OGC API standards as inputs to a process, and trigger execution of processes through OGC API data delivery specifications such as _OGC API - Tiles_, _DGGS_, _Coverages_, _Features_, _EDR_ and _Maps_. This extension also defines the behavior of an implementation that supports the ability to deploy a workflow defined using the mechanisms it describes -through the _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_ extension. +through the <> extension. diff --git a/extensions/workflows/sections/clause_2_conformance.adoc b/extensions/workflows/sections/clause_2_conformance.adoc index 6f863f5c..01546234 100644 --- a/extensions/workflows/sections/clause_2_conformance.adoc +++ b/extensions/workflows/sections/clause_2_conformance.adoc @@ -7,63 +7,48 @@ The requirements classes are: === Requirements classes extending _Part 1: Core_ execution requests -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes) -The _Nested Processes_ conformance class extends the execution request of _OGC API - Processes - Part 1: Core_ with the ability to specify another process as an input. +The _Nested Processes_ conformance class extends the execution request of <> +with the ability to specify another process as an input. A `"process"` key is used to define such an input. -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-core-processes) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-core-processes) -The _Remote Core Processes_ conformance class extends the capability defined in the _Nested Processes_ conformance class to the execution of remote processes using the _Core_ conformance class of -_OGC API - Processes - Core: Part 1_ in addition to local processes. -Remote processes supporting the _Collection Output_ conformance class can also be executed with support for the _Remote Collections_ as an alternative to this conformance class. +The _Remote Core Processes_ conformance class extends the capability defined in the <> conformance class +to the execution of remote processes using the _Core_, _Collection Output_ and _Remote Collections_ conformance classes +of <> in addition to local processes. -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers) -The _Collection Input_ conformance class extends the capability defined in _OGC API - Processes - Part 1: Core_ with the ability to reference an OGC API collection as input. -A `"collection"` key is used to define such an input. - -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections) - -The _Remote Collections_ conformance class extends the capability defined in the _Collection Input_ conformance class to remote collections in addition to local collections. -If _Nested Processes_ are also supported, this also extends to remote processes supporting the _Collection Output_ conformance classes, specified using the `"process"` key. - -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers) - -The _Input Fields Modifiers_ conformance class extends the execution request of _OGC API - Processes - Part 1: Core_ with the ability to filter or sort data used as an input +The _Input Fields Modifiers_ conformance class extends the execution request of <> with the ability to filter or sort data used as an input to a process according to field values, as well as to select specific fields from the data or derive new fields from existing ones, using an expression language such as the OGC Common Query Language 2.0 (CQL2). Those modifiers are defined by the `"filter"`, `"properties"` and `"sortBy"` keys. -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers) -The _Output Fields Modifiers_ conformance class extends the execution request of _OGC API - Processes - Part 1: Core_ with the ability to filter or sort data returned as an output +The _Output Fields Modifiers_ conformance class extends the execution request of <> with the ability to filter or sort data returned as an output from a process according to field values, as well as to select specific fields from the data or derive new fields from existing ones, using an expression language such as the OGC Common Query Language 2.0 (CQL2). Those modifiers are defined by the `"filter"`, `"properties"` and `"sortBy"` keys. -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/deployable-workflows) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/deployable-workflows) -The _Deployable Workflows_ conformance class extends the execution request of _OGC API - Processes - Part 1: Core_ with the ability to define parameterized inputs and select outputs in the context of deploying -the workflow as a new process using _OGC API - Processes - Part 2: Deploy, Replace, Undeploy_. +The _Deployable Workflows_ conformance class extends the execution request of <> +with the ability to define parameterized inputs and select outputs in the context of deploying +the workflow as a new process using <>. An `"$input"` key is used to define an external input to the deployed process, and an `"$output"` key is used to select an output from the deployed process. The extended JSON execution request defining the workflow can either be the direct payload of deployment `POST` request, -or the execution unit of an _OGC Application Package_, if the implementation supports the associated _Part 2_ conformance class. - -=== Requirements class specifying a new on-demand, client-driven execution mechanism - -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-output) - -The _Collection Output_ conformance class specifies a new execution mechanism allowing to trigger the execution of the process of workflow for a specific area, time and resolution of interest as a direct result of requests for output data -using OGC API data access mechanisms such as those defined by _OGC API - Tiles_, _DGGS_, _Coverages_, _Features_, _EDR_ or _Maps_, in a manner completely agnostic to process execution. -With this execution mechanism, selected by a new query parameter, the implementation's initial response is either a collection description document (`response=collection`), or an OGC API landing page (`response=landingPage`). +or the execution unit of an >, +if the implementation supports the associated _Part 2_ conformance class. === Requirements classes specifying alternative ad-hoc workflow definitions -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/cwl-workflows) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/cwl-workflows) -The _Common Workflow Language Definitions_ conformance class specifies the ability to execute Common Workflow Language (CWL) workflows in an ad-hoc manner +The _Common Workflow Language Definitions_ conformance class specifies the ability to execute <> workflows in an ad-hoc manner i.e., without first requiring to deploy the workflow as a process (see also the relevant _Part 2_ conformance class to deploy CWL workflow as a process). -*<>* (http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/openeo-workflows) +*<>* (https://www.opengis.net/spec/ogcapi-processes-3/0.0/req/openeo-workflows) The _OpenEO Process Graphs Definitions_ conformance class specifies the ability to execute workflows defined using OpenEO Process Graphs in an ad-hoc manner i.e., without first requiring to deploy the workflow as a process (see also the relevant _Part 2_ conformance class to deploy OpenEO process graphs as a process). @@ -88,14 +73,12 @@ The framework, concepts, and methodology for testing, and the criteria to be ach [cols="30,70",options="header"] |=== | Conformance class | URI -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/nested-processes -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/remote-core-processes -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/collection-input -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/remote-collections -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/input-fields-modifiers -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/output-fields-modifiers -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/deployable-workflows -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/collection-output -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/cwl-workflows -|<> |http://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/openeo-workflows +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/nested-processes +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/remote-core-processes +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/remote-collections +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/input-fields-modifiers +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/output-fields-modifiers +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/deployable-workflows +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/cwl-workflows +|<> |https://www.opengis.net/spec/ogcapi-processes-3/0.0/conf/openeo-workflows |=== diff --git a/extensions/workflows/sections/clause_3_references.adoc b/extensions/workflows/sections/clause_3_references.adoc index 3875b64f..52368caa 100644 --- a/extensions/workflows/sections/clause_3_references.adoc +++ b/extensions/workflows/sections/clause_3_references.adoc @@ -9,7 +9,9 @@ For undated references, the latest edition of the normative document referred to References are to follow the Springer LNCS style, with the exception that optional information may be appended to references: DOIs are added after the date and web resource references may include an access date at the end of the reference in parentheses. See examples from Springer and OGC below. //// -* [[[OGC18-062r2,OGC 18-062r2]]], OGC API - Processes - Part 1: Core +* [[[OAProc-1,_OGC API - Processes - Part 1: Core_]]] Pross, B., Vretanos, P.: OGC 18-062, *OGC API - Processes - Part 1: Core* (v2.0) + +* [[[OAProc-2,_OGC API - Processes - Part 2: Deploy, Replace, Undeploy_]]] Panagiotis (Peter) A. Vretanos, OGC API - Processes - Part 2: Deploy, Replace, Undeploy (Draft). OGC 20-044, Open Geospatial Consortium, https://github.com/opengeospatial/ogcapi-processes/tree/master/extensions/deploy_replace_undeploy/standard[https://github.com/opengeospatial/ogcapi-processes/tree/master/extensions/deploy_replace_undeploy/standard] * [[[OGC20-057,OGC 20-057]]], OGC API - Tiles - Part 1: Core (2022) @@ -17,19 +19,17 @@ References are to follow the Springer LNCS style, with the exception that option * [[[OGC19-086r5,OGC 19-086r5]]], OGC API - Environmental Data Retrieval - Part 1: Core (2022) -* [[[OGC20-044,OGC 20-044]]] Panagiotis (Peter) A. Vretanos: OGC API - Processes - Part 2: Deploy, Replace, Undeploy (Draft). OGC 20-044, Open Geospatial Consortium, https://github.com/opengeospatial/ogcapi-processes/tree/master/extensions/deploy_replace_undeploy/standard[https://github.com/opengeospatial/ogcapi-processes/tree/master/extensions/deploy_replace_undeploy/standard] - -* [[[OGC19-072,OGC 19-072]]] Charles Heazel: OGC API - Common - Part 1: Core (Draft). OGC 19-072, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/19-072.html[http://docs.ogc.org/DRAFTS/19-072.html] +* [[[OGC19-072,OGC 19-072]]] Charles Heazel: OGC API - Common - Part 1: Core (Draft). OGC 19-072, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/19-072.html[https://docs.ogc.org/DRAFTS/19-072.html] -* [[[OGC20-024,OGC 20-024]]] Charles Heazel: OGC API - Common - Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html[http://docs.ogc.org/DRAFTS/20-024.html] +* [[[OGC20-024,OGC 20-024]]] Charles Heazel: OGC API - Common - Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/20-024.html[https://docs.ogc.org/DRAFTS/20-024.html] -* [[[OGC20-065,OGC 21-065]]] Panagiotis (Peter) A. Vretanos: OGC Common Query Language (CQL2) (Draft). OGC 21-065, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/21-065.html[http://docs.ogc.org/DRAFTS/21-065.html] +* [[[OGC20-065,OGC 21-065]]] Panagiotis (Peter) A. Vretanos: OGC Common Query Language (CQL2) (Draft). OGC 21-065, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/21-065.html[https://docs.ogc.org/DRAFTS/21-065.html] -* [[[OGC19-079r1,OGC 19-079r1]]] Panagiotis (Peter) A. Vretano, Clemens Portele: OGC API - Features - Part 3: Filtering (Draft). OGC 19-079r1, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/19-079r1.html[http://docs.ogc.org/DRAFTS/19-079r1.html] +* [[[OAFeat-3,_OGC API - Features - Part 3: Filtering_]]] Panagiotis (Peter) A. Vretano, Clemens Portele: OGC API - Features - Part 3: Filtering (Draft). OGC 19-079r3, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/19-079r3.html[https://docs.ogc.org/DRAFTS/19-079r3.html] -* [[[OGC19-087,OGC 19-087]]], Charles Heazel, Jérôme Jacovella-St-Louis: OGC API - Coverages - Part 1: Core (Draft). OGC 19-087, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/19-087.html[http://docs.ogc.org/DRAFTS/19-087.html] +* [[[OGC19-087,OGC 19-087]]], Charles Heazel, Jérôme Jacovella-St-Louis: OGC API - Coverages - Part 1: Core (Draft). OGC 19-087, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/19-087.html[https://docs.ogc.org/DRAFTS/19-087.html] -// * [[[OGC20-058,OGC 20-058]]], Joan Masó, Jérôme Jacovella-St-Louis: OGC API - Maps - Part 1: Core (Draft). OGC 19-058, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-058.html[http://docs.ogc.org/DRAFTS/20-058.html] -* [[[OGC20-058-fixme,OGC 20-058-fixme]]], Joan Masó, Jérôme Jacovella-St-Louis: OGC API - Maps - Part 1: Core (Draft). OGC 19-058, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-058.html[http://docs.ogc.org/DRAFTS/20-058.html] +// * [[[OGC20-058,OGC 20-058]]], Joan Masó, Jérôme Jacovella-St-Louis: OGC API - Maps - Part 1: Core (Draft). OGC 19-058, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/20-058.html[https://docs.ogc.org/DRAFTS/20-058.html] +* [[[OGC20-058-fixme,OGC 20-058-fixme]]], Joan Masó, Jérôme Jacovella-St-Louis: OGC API - Maps - Part 1: Core (Draft). OGC 19-058, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/20-058.html[https://docs.ogc.org/DRAFTS/20-058.html] * [[[OGC21-038,OGC 21-038]]], Matthew B.J. Purss, Jérôme Jacovella-St-Louis: OGC API - Discrete Global Grid Systems - Part 1: Core (Draft). OGC 21-038, Open Geospatial Consortium, https://opengeospatial.github.io/ogcna-auto-review/21-038.html[https://opengeospatial.github.io/ogcna-auto-review/21-038.html] diff --git a/extensions/workflows/sections/clause_4_terms_and_definitions.adoc b/extensions/workflows/sections/clause_4_terms_and_definitions.adoc index 919b4fc1..929c383a 100644 --- a/extensions/workflows/sections/clause_4_terms_and_definitions.adoc +++ b/extensions/workflows/sections/clause_4_terms_and_definitions.adoc @@ -1,4 +1,5 @@ -== Terms and definitions +[[sc_terms]] +== Terms, definitions and abbreviated terms //// // Something equivalent to the following seems to be automatically added by metanorma... @@ -9,14 +10,36 @@ In particular, the word "`shall`" (not "`must`") is the verb form used to indica For the purposes of this document, the following additional terms and definitions apply. //// -=== example term +[[sc_terms_definitions]] +=== Terms and definitions -term used for exemplary purposes +[[def_collection]] +==== collection; OGC API collection -[.source] -<> +(in the context of OGC APIs) A set of spatiotemporal data that may be available through one or more access mechanisms defined by https://www.ogc.org/standards[OGC API standards]. (https://docs.ogc.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial Data]) -NOTE: An example note. +[[def_field-modifiers]] +==== field modifiers -[example] -Here's an example of an example term. +Parameters provided as fields in the relevant execution context, which modifies the obtained data according to applied operations. + +[[def_remote-collection]] +==== remote collection + +A <> that is available from an external OGC API deployment different from the deployment whose process is being executed. + +[[def_remote-process]] +==== remote process + +A process that is available from an external OGC API deployment different from the deployment whose process is being executed. + +[[sc_terms_abbreviations]] +=== Abbreviated Terms + +API:: Application Programming Interface +CWL:: Common Workflow Language +HTTP:: Hypertext Transfer Protocol +JSON:: JavaScript Object Notation +URI:: Uniform Resource Identifier +URL:: Uniform Resource Locator +YAML:: YAML Ain't Markup Language diff --git a/extensions/workflows/sections/clause_5_conventions.adoc b/extensions/workflows/sections/clause_5_conventions.adoc index 37acd306..6054a42e 100644 --- a/extensions/workflows/sections/clause_5_conventions.adoc +++ b/extensions/workflows/sections/clause_5_conventions.adoc @@ -5,6 +5,6 @@ This sections provides details and examples for any conventions used in the docu === Identifiers The normative provisions in this standard are denoted by the URI -`http://www.opengis.net/spec/ogcapi-processes-3/0.0` +`https://www.opengis.net/spec/ogcapi-processes-3/0.0` All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base. diff --git a/extensions/workflows/sections/clause_7_nested_processes.adoc b/extensions/workflows/sections/clause_7_nested_processes.adoc index 5d6239ba..0fd5790f 100644 --- a/extensions/workflows/sections/clause_7_nested_processes.adoc +++ b/extensions/workflows/sections/clause_7_nested_processes.adoc @@ -24,10 +24,11 @@ include::../requirements/nested-processes/REQ_nested-processes_referenced-proces include::../requirements/nested-processes/REQ_nested-processes_process-execution.adoc[] +[[section_remote-core-process]] === Requirement Class _Remote Core Processes_ -The _Remote Core Processes_ conformance class allows to reference and execute a remote OGC API process -using the _Core_ conformance class of _OGC API - Processes - Part 1: Core_ in addition to any local process. +The _Remote Core Processes_ conformance class allows to reference and execute an OGC API <> +using the _Core_ conformance class of <> in addition to any local process. include::../requirements/requirements_class_remote-core-processes.adoc[] diff --git a/extensions/workflows/sections/clause_8_collection_input.adoc b/extensions/workflows/sections/clause_8_collection_input.adoc deleted file mode 100644 index 2bab5851..00000000 --- a/extensions/workflows/sections/clause_8_collection_input.adoc +++ /dev/null @@ -1,43 +0,0 @@ -[[section_collection_input]] -== Collection Input and Remote Collections Conformance Classes - -=== Requirement Class _Collection Input_ - -The _Collection Input_ conformance class allows to specify an OGC API collection available using -one or more OGC API data access mechanism specification as an input to a process. Unless an implementation -also conforms to the _Remote Collections_ conformance class, only local collections are supported. - -include::../requirements/requirements_class_collection-input.adoc[] - -The following requirements describe how an execution request references an OGC API collection -and how an implementation requests data from that collection to use as an input to a process. - -==== Referencing a collection - -include::../requirements/collection-input/REQ_collection-input_referenced-collection.adoc[] - -==== Accessing data from a collection - -include::../requirements/collection-input/REQ_collection-input_collection-access.adoc[] - -=== Requirement Class _Remote Collections_ - -The _Remote Collections_ conformance class allows to reference a remote OGC API collection -in addition to any local collections. - -If the _Nested Processes_ conformance class is also supported, but _Remote Processes_ is not, -an implementation still provides the ability to substitute a collection by remote nested processes -supporting the _Collection Output_ conformance class as input to a process. - -include::../requirements/requirements_class_remote-collections.adoc[] - -The following requirements describe how an execution request references a remote OGC API collection -and how an implementation requests data from that collection to use as an input to a process. - -==== Referencing a remote collection - -include::../requirements/remote-collections/REQ_remote-collections_referenced-collection.adoc[] - -==== Accessing data from a remote collection - -include::../requirements/remote-collections/REQ_remote-collections_collection-access.adoc[] diff --git a/extensions/workflows/sections/clause_9_input_output_fields_modifiers.adoc b/extensions/workflows/sections/clause_9_input_output_fields_modifiers.adoc index e2f4e51c..91e0c57d 100644 --- a/extensions/workflows/sections/clause_9_input_output_fields_modifiers.adoc +++ b/extensions/workflows/sections/clause_9_input_output_fields_modifiers.adoc @@ -4,14 +4,22 @@ === Requirement Class _Input Fields Modifiers_ The _Input Fields Modifiers_ conformance class specifies how execution requests can modify -an input (including those specified using the _Collection Input_, _Remote Collections_, _Nested Processes_ and _Remote Processes_ conformance classes) +an input (including those specified using the _Nested Processes_ and _Remote Processes_ conformance classes, +and extending <> conformance classes _Collection Input_, _Remote Collections_) by filtering its data according to its fields (properties), selecting a subset of the data fields or deriving new fields from existing ones (e.g., by performing arithmetic), and/or sorting the data according to the value of fields. An expression language such as the OGC Common Query Language 2 (CQL2) can be used for this purpose. -http://docs.ogc.org/DRAFTS/21-065.html#_scope[There are plans] to extend CQL2 beyond +https://docs.ogc.org/DRAFTS/21-065.html#_scope[There are plans] to extend CQL2 beyond boolean predicates to expressions that resolve to other types of values (e.g., numbers or geometry). +NOTE: _Input Fields Modifiers_ has a strong overlap with corresponding requirements of +<> requirement class from <>. +However, this conformance class also extends the capability to other kind of inputs (i.e., not only `"collection"`). +For the case of `"collection"` inputs, where corresponding parametrization fields are defined, they can be considered +equivalent and compatible with this requirement. In some cases (i.e., `"properties"` and `"sortBy"`), this requirement +class provides additional capabilities further extending the _Collection Input_. + include::../requirements/requirements_class_input-fields-modifiers.adoc[] The following requirements describe the ability of an implementation to modify the @@ -20,15 +28,16 @@ selecting a subset of the fields or deriving new fields (`"properties"`) or sorting the data (`"sortBy"`), before providing the data as input to the process. In an execution request, these additional keys are specified at the same level as the `"collection"` defined in the _Collection Input_ conformance class, or the -`"process"` defined in the _Nested Process_ conformance class. +`"process"` defined in the <> conformance class. For an input generated by a nested process, this capability is equivalent to the -_Output Fields Modifiers_ conformance class from the perspective of that nested process. -For a remote process (as defined in _Remote Processes_ conformance class) that supports _Output Fields Modifiers_, or +<> conformance class from the perspective of that nested process. +For a remote process (as defined in <> conformance class) +that supports <> , or for a collection (or a process supporting _Collection Output_) with a data access mechanism providing the required functionality, it is preferable to let the remote process or collection access handle the modification to lower bandwidth and processing requirements. -For an input from a _remote collection_, a data access mechanism for the collection may readily support some or all of these parameters (e.g., _OGC API - Features - Part 3: Filtering_). +For an input from a <>, a data access mechanism for the collection may readily support some or all of these parameters (e.g., _OGC API - Features - Part 3: Filtering_). In this case, it is preferable for the Implementation to query the data with the relevant parameters. This ability to pass on these modifiers to remote data and processing sources allows to easily bring a certain category of algorithms close to the data through simple standard expressions. @@ -54,11 +63,17 @@ the data output from a process by filtering its data according to its fields (pr deriving new fields from existing ones (e.g., by performing arithmetic), and/or sorting the data according to the value of fields. An expression language such as the OGC Common Query Language 2 (CQL2) can be used for this purpose. -http://docs.ogc.org/DRAFTS/21-065.html#_scope[There are plans] to extend CQL2 beyond +https://docs.ogc.org/DRAFTS/21-065.html#_scope[There are plans] to extend CQL2 beyond boolean predicates to expressions that resolve to other types of values (e.g., numbers or geometry). -This capability is available whether using the _Collection Output_ conformance class, -or the synchronous or asynchronous execution capabilities of _OGC API - Processes - Part 1: Core_. +This capability is available whether using the +<> requirement class from <>, +or the synchronous or asynchronous execution capabilities of <>. + +NOTE: Contrary to <> where <> are partially covered by +<> and this standard (_Part 3:_), the _Output Fields Modifiers_ are entirely defined by this standard. +However, they are still complementary to the <> +if a `response=collection` is requested, and can also be employed by themselves onto the single output produced by a process execution. include::../requirements/requirements_class_output-fields-modifiers.adoc[] @@ -67,13 +82,13 @@ data output from a process by applying a filter (`"filter"`), selecting a subset of the fields or deriving new fields (`"properties"`) or sorting the data (`"sortBy"`), before returning the data as an output of a process. In an execution request, these additional keys are specified at the same level as the -`"process"` defined in the _Nested Process_ conformance class, or at the top-level of an execution request -as defined in _OGC API - Processes - Part 1: Core_. +`"process"` defined in the <> conformance class, or at the top-level of an execution request +as defined in <>. When a nested process is used as an input to another process, this capability is equivalent to the _Input Fields Modifiers_ conformance class from the perspective of the parent process receiving the output of the nested process. -For a remote process (as defined in _Remote Processes_ conformance class) that supports _Output Fields Modifiers_, or -supports _Collection Output_ with a data access mechanism providing the required functionality, +For a <> that supports _Output Fields Modifiers_, or +supports _Collection Output_ from <> with a data access mechanism providing the required functionality, it is preferable to let the remote process handle the modification to lower bandwidth and processing requirements. The extent to which an implementation support these capabilities depends on its