opengeospatial · bpross-52n · Jan 20, 2025 · Jan 20, 2025 · Jan 20, 2025 · Jan 20, 2025
diff --git a/core/recommendations/core/REC_access-control-expose-headers.adoc b/core/recommendations/core/REC_access-control-expose-headers.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/access-control-expose-headers
+label:: /rec/core/access-control-expose-headers
 
 If the server is intended to be accessed from the browser and if Cross-origin resource sharing is supported, the `Access-Control-Expose-Headers` header SHOULD be used and the header SHOULD contain the value `location` to enable the browser to access the `location` header of the response.
 ====
diff --git a/core/recommendations/core/REC_api-definition-oas.adoc b/core/recommendations/core/REC_api-definition-oas.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/api-definition-oas
+label:: /rec/core/api-definition-oas
 
 If the API definition document is defined using the OpenAPI Specification 3.0, the document SHOULD conform to the <<rc_oas30,OpenAPI Specification 3.0 requirements class>>.
 ====
diff --git a/core/recommendations/core/REC_content-length.adoc b/core/recommendations/core/REC_content-length.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/content-length
+label:: /rec/core/content-length
 
 The server SHOULD include the HTTP 1.1 `Content-Length` header in all responses.
 ====
diff --git a/core/recommendations/core/REC_cross-origin.adoc b/core/recommendations/core/REC_cross-origin.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/cross-origin
+label:: /rec/core/cross-origin
 
 If the server is intended to be accessed from the browser, cross-origin requests SHOULD be supported. Note that support can also be added in a proxy layer on top of the server.
 ====
diff --git a/core/recommendations/core/REC_html.adoc b/core/recommendations/core/REC_html.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/html
+label:: /rec/core/html
 
 To support browsing an implementation of OGC API - Processes with a web browser and to enable search engines to crawl and index a process, implementations SHOULD consider to support an HTML encoding.
 ====
diff --git a/core/recommendations/core/REC_http-head.adoc b/core/recommendations/core/REC_http-head.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/http-head
+label:: /rec/core/http-head
 
 The server SHOULD support the HTTP 1.1 method HEAD for all resources that support the method GET.
 ====
diff --git a/core/recommendations/core/REC_job-links.adoc b/core/recommendations/core/REC_job-links.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/job-links
+label:: /rec/core/job-links
 
 [.component,class=part]
 --

diff --git a/...ecommendations/core/REC_job-results-success-async-many-json-prefer-minimal.adoc b/...ecommendations/core/REC_job-results-success-async-many-json-prefer-minimal.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/job-results-async-many-json-prefer-minimal
+label:: /rec/core/job-results-async-many-json-prefer-minimal
 
 [.component,class=conditions]
 --

diff --git a/core/recommendations/core/REC_job-results-success-async-many-json-prefer-none.adoc b/core/recommendations/core/REC_job-results-success-async-many-json-prefer-none.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/job-results-async-many-json-prefer-none
+label:: /rec/core/job-results-async-many-json-prefer-none
 
 [.component,class=conditions]
 --

diff --git a/...dations/core/REC_job-results-success-async-many-json-prefer-representation.adoc b/...dations/core/REC_job-results-success-async-many-json-prefer-representation.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/job-results-async-many-json-prefer-representation
+label:: /rec/core/job-results-async-many-json-prefer-representation
 
 [.component,class=conditions]
 --

diff --git a/core/recommendations/core/REC_job-status.adoc b/core/recommendations/core/REC_job-status.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/job-status
+label:: /rec/core/job-status
 
 [.component,class=part]
 --

diff --git a/core/recommendations/core/REC_link-header.adoc b/core/recommendations/core/REC_link-header.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/link-header
+label:: /rec/core/link-header
 
 [.component,class=part]
 --

diff --git a/core/recommendations/core/REC_ogc-process-description.adoc b/core/recommendations/core/REC_ogc-process-description.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/ogc-process-description
+label:: /rec/core/ogc-process-description
 
 Implementations SHOULD consider supporting the <<ogc_process_description,OGC process description>>.
 ====
diff --git a/core/recommendations/core/REC_problem-details.adoc b/core/recommendations/core/REC_problem-details.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/problem-details
+label:: /rec/core/problem-details
 
 A server SHOULD include a "Problem Details" report in an error response in accordance with https://datatracker.ietf.org/doc/html/rfc7807[RFC 7807].
 ====
diff --git a/core/recommendations/core/REC_process-execute-handle-prefer.adoc b/core/recommendations/core/REC_process-execute-handle-prefer.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-handle-prefer
+label:: /rec/core/process-execute-handle-prefer
 
 A client that accompanies an execute request with the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-2[`Prefer`] header asserting a https://tools.ietf.org/html/rfc7240#section-4.1[`respond-async`] preference and/or a https://tools.ietf.org/html/rfc7240#section-4.3[`wait`] preference SHOULD be prepared to receive either an asynchronous or a synchronous response.
 ====
diff --git a/core/recommendations/core/REC_process-execute-handle-return-preference.adoc b/core/recommendations/core/REC_process-execute-handle-return-preference.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-handle-return-preference
+label:: /rec/core/process-execute-handle-return-preference
 
 A client that accompanies an execute request with the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-2[`Prefer`] header asserting a https://tools.ietf.org/html/rfc7240#section-4.2[`return`] preference SHOULD be prepared to receive output values either:
 

diff --git a/core/recommendations/core/REC_process-execute-honor-prefer.adoc b/core/recommendations/core/REC_process-execute-honor-prefer.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-honor-prefer
+label:: /rec/core/process-execute-honor-prefer
 
 [.component,class=part]
 --

diff --git a/core/recommendations/core/REC_process-execute-honor-return-preference.adoc b/core/recommendations/core/REC_process-execute-honor-return-preference.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-honor-prefer-return
+label:: /rec/core/process-execute-honor-prefer-return
 
 If an execute request *is accompanied* with the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-2[`Prefer`] header asserting a https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[`return`] preference, then the server SHOULD honor that preference.
 

diff --git a/core/recommendations/core/REC_process-execute-mode-auto.adoc b/core/recommendations/core/REC_process-execute-mode-auto.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-mode-auto
+label:: /rec/core/process-execute-mode-auto
 
 A client that requests a process be executed in `auto` mode SHOULD be prepared to receive either an asynchronous or a synchronous response.
 ====
diff --git a/core/recommendations/core/REC_process-execute-preference-applied.adoc b/core/recommendations/core/REC_process-execute-preference-applied.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-preference-applied
+label:: /rec/core/process-execute-preference-applied
 
 If an execute request is accompanied with the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-2[`Prefer`] header then, in the <<sc_execute_response,response>>, servers SHOULD include the HTTP https://datatracker.ietf.org/doc/html/rfc7240#section-3[`Preference-Applied`] response header as an indication as to which https://datatracker.ietf.org/doc/html/rfc7240#section-2['Prefer`] tokens were honored by the server.
 ====
diff --git a/...mmendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc b/...mmendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc
@@ -3,6 +3,8 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-sync-many-json-prefer-minimal
+label:: /rec/core/process-execute-sync-many-json-prefer-minimal
+
 [.component,class=conditions]
 --
 . The <<sc_execution_mode,negotiated execution mode>> is synchronous.

diff --git a/...ecommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc b/...ecommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc
@@ -3,6 +3,8 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-sync-many-json-prefer-none
+label:: /rec/core/process-execute-sync-many-json-prefer-none
+
 [.component,class=conditions]
 --
 . The <<sc_execution_mode,negotiated execution mode>> is synchronous.

diff --git a/...ions/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc b/...ions/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/process-execute-sync-many-json-prefer-representation
+label:: /rec/core/process-execute-sync-many-json-prefer-representation
 
 [.component,class=conditions]
 --

diff --git a/core/recommendations/core/REC_process-list-next-1.adoc b/core/recommendations/core/REC_process-list-next-1.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/next-1
+label:: /rec/core/next-1
 
 If more processes summaries have been selected than returned in the response, a `200`-response SHOULD include a link to the next page (relation: `next`) of process summaries.
 ====
diff --git a/core/recommendations/core/REC_process-list-next-2.adoc b/core/recommendations/core/REC_process-list-next-2.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/next-2
+label:: /rec/core/next-2
 
 Dereferencing a next page link (relation: `next`) SHOULD return additional process summaries from the set of selected process summaries that have not yet been returned.
 ====
diff --git a/core/recommendations/core/REC_process-list-next-3.adoc b/core/recommendations/core/REC_process-list-next-3.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/next-3
+label:: /rec/core/next-3
 
 The number of process summaries in a response to dereferencing a next page link (relation: `next`) SHOULD follow the same rules as for the response to the original query and again include a next page link (relation: `next`), if there are more process summaries in the selection that have not yet been returned.
 ====
diff --git a/core/recommendations/core/REC_test-process.adoc b/core/recommendations/core/REC_test-process.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/core/test-process
+label:: /rec/core/test-process
 
 If a server implementing the OGC API - Processes - Part 1: Core is tested using CITE tests, the server SHOULD offer one of the following options:
 

diff --git a/core/recommendations/job-list/PER_jl-limit-default-minimum-maximum.adoc b/core/recommendations/job-list/PER_jl-limit-default-minimum-maximum.adoc
@@ -3,5 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/job-list/limit-default-minimum-maximum
+label:: /per/job-list/limit-default-minimum-maximum
+
 part:: The values for `minimum`, `maximum` and `default` in requirement `/req/job-list/limit-definition` are only examples and MAY be changed.
-====
+====
diff --git a/core/recommendations/job-list/PER_jl-limit-response.adoc b/core/recommendations/job-list/PER_jl-limit-response.adoc
@@ -3,5 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/job-list/limit-response
+label:: /per/job-list/limit-response
+
 part:: The server MAY return fewer jobs than requested (but not more).
-====
+====
diff --git a/core/recommendations/job-list/PER_prev.adoc b/core/recommendations/job-list/PER_prev.adoc
@@ -3,5 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/job-list/prev
+label:: /per/job-list/prev
+
 part:: A response to dereferencing a next page link (relation: `next`) MAY include a previous page link (relation: `prev`) to the resource that included the next page link (relation: `next`).
 ====
diff --git a/core/recommendations/job-list/REC_access-control-job-list.adoc b/core/recommendations/job-list/REC_access-control-job-list.adoc
@@ -2,6 +2,7 @@
 ====
 [%metadata]
 identifier:: /rec/job-list/access-control-job-list
+label:: /rec/job-list/access-control-job-list
 
 Servers implementing the conformance class 'Job List' SHOULD have an access control in place for the /jobs endpoint to prevent misuse of job-ids.
 ====
diff --git a/core/recommendations/job-list/REC_landing-page.adoc b/core/recommendations/job-list/REC_landing-page.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/job-list/job-list-landing-page
+label:: /rec/job-list/job-list-landing-page
 
 A link to the following resource SHOULD be added to the API landing page:
 

diff --git a/core/recommendations/job-list/REC_next-1.adoc b/core/recommendations/job-list/REC_next-1.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/job-list/next-1
+label:: /rec/job-list/next-1
 
 If more jobs have been selected than returned in the respose, a `200`-response SHOULD include a link to the next page (relation: `next`) of jobs.
 ====

diff --git a/core/recommendations/job-list/REC_next-2.adoc b/core/recommendations/job-list/REC_next-2.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/job-list/next-2
+label:: /rec/job-list/next-2
 
 Dereferencing a next page link (relation: `next`) SHOULD return additional jobs from the set of selected jobs that have not yet been returned.
 ====
diff --git a/core/recommendations/job-list/REC_next-3.adoc b/core/recommendations/job-list/REC_next-3.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/job-list/next-3
+label:: /rec/job-list/next-3
 
 If there are more jobs in the selection that have not yet been returned, the number of jobs in a response to dereferencing a next page link (relation: `next`) SHOULD follow the same rules as for the response to the original query and again include a next page link (relation: `next`).
 ====
diff --git a/core/recommendations/kvp-execute/PER_boolean-input-value.adoc b/core/recommendations/kvp-execute/PER_boolean-input-value.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/kvp-execute/boolean-input-value
+label:: /per/kvp-execute/boolean-input-value
 
 part:: The characteristics of a boolean-valued input parameter MAY include additional https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1[validation keywords] (i.e. https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1.2[`enum`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1.3[`const`]) that apply to any type.
 

diff --git a/core/recommendations/kvp-execute/PER_complex-input-value.adoc b/core/recommendations/kvp-execute/PER_complex-input-value.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/kvp-execute/complex-input-value
+label:: /per/kvp-execute/complex-input-value
 
 part:: The characteristics of a complex-valued input parameter MAY include additional https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8[keywords for string-encoded data] (i.e. https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.3[`contentEncoding`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.5[`contentMediaType`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.6[`contentSchema`]).
 

diff --git a/core/recommendations/kvp-execute/PER_numeric-input-value.adoc b/core/recommendations/kvp-execute/PER_numeric-input-value.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/kvp-execute/numeric-input-value
+label:: /per/kvp-execute/numeric-input-value
 
 part:: The characteristics of a numeric input parameter MAY include additional https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.3[validation keywords] (i.e. https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.2.1[`multipleOf`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.2.2[`maximum`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.2.3[`exclusiveMaximum`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.2.4[`minimum`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.2.5[`exclusiveMinimum`]).
 

diff --git a/core/recommendations/kvp-execute/PER_string-input-value.adoc b/core/recommendations/kvp-execute/PER_string-input-value.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /per/kvp-execute/string-input-value
+label:: /per/kvp-execute/string-input-value
 
 part:: The characteristics of a string-valued input parameter MAY include additional https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.3[validation keywords] (i.e. https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.3.1[`maxLength`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.3.2[`minLength`], https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.3.3[`pattern`]).
 

diff --git a/core/recommendations/ogc-process-description/REC_format-key.adoc b/core/recommendations/ogc-process-description/REC_format-key.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/ogc-process-description/format-key
+label:: /rec/ogc-process-description/format-key
 
 Servers SHOULD use the `format` key in the schema description of a process input or output (key: `schema`) to provide additional semantic context that can aid in the interpretation and validation of process input or output values in an <<sc_execute_process,execute>> request.
 ====
diff --git a/core/recommendations/ogc-process-description/REC_format-short-code.adoc b/core/recommendations/ogc-process-description/REC_format-short-code.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/ogc-process-description/format-short-code
+label:: /rec/ogc-process-description/format-short-code
 
 In addition to the key values listed in <<format-key-values>>, servers SHOULD also accept the short codes.
 ====
diff --git a/core/recommendations/ogc-process-description/REC_format-value-registration.adoc b/core/recommendations/ogc-process-description/REC_format-value-registration.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/ogc-process-description/format-value-registration
+label:: /rec/ogc-process-description/format-value-registration
 
 Servers wishing to extend this list of `format` key values, SHOULD officially register such values with the https://www.ogc.org/ogcna[OGC Naming Authority].
 ====
diff --git a/core/recommendations/ogc-process-description/REC_links.adoc b/core/recommendations/ogc-process-description/REC_links.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /rec/ogc-process-description/process-links
+label:: /rec/ogc-process-description/process-links
 
 [.component,class=part]
 --

diff --git a/core/requirements/callback/REQ_process-execute-callback.adoc b/core/requirements/callback/REQ_process-execute-callback.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /req/callback/job-callback
+label:: /req/callback/job-callback
 
 The server SHALL support callback functions for jobs.
 ====
diff --git a/core/requirements/core/REQ_api-definition-op.adoc b/core/requirements/core/REQ_api-definition-op.adoc
@@ -3,6 +3,8 @@
 ====
 [%metadata]
 identifier:: /req/core/api-definition-op
+label:: /req/core/api-definition-op
+
 The URIs of all API definitions referenced from the landing page
 SHALL support the HTTP GET method.
 ====
diff --git a/core/requirements/core/REQ_api-definition-success.adoc b/core/requirements/core/REQ_api-definition-success.adoc
@@ -3,6 +3,8 @@
 ====
 [%metadata]
 identifier:: /req/core/api-definition-success
+label:: /req/core/api-definition-success
+
 A successful execution of the operation to get the API definition document SHALL be reported as a
 response with a HTTP status code `200`.
 

diff --git a/core/requirements/core/REQ_conformance-op.adoc b/core/requirements/core/REQ_conformance-op.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /req/core/conformance-op
+label:: /req/core/conformance-op
 
 The server SHALL support the HTTP GET operation at the path `/conformance`.
 ====
diff --git a/core/requirements/core/REQ_conformance-success.adoc b/core/requirements/core/REQ_conformance-success.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /req/core/conformance-success
+label:: /req/core/conformance-success
 
 A successful execution of the operation SHALL be reported as a response with a
 HTTP status code `200`.

diff --git a/core/requirements/core/REQ_http.adoc b/core/requirements/core/REQ_http.adoc
@@ -3,6 +3,7 @@
 ====
 [%metadata]
 identifier:: /req/core/http
+label:: /req/core/http
 
 The server SHALL conform to <<rfc2616,HTTP 1.1>>.