opengeospatial · fmigneault · Jul 18, 2026 · Aug 3, 2026
diff --git a/core/abstract_tests/collection-input/ATS_collection-input_access.adoc b/core/abstract_tests/collection-input/ATS_collection-input_access.adoc
@@ -4,14 +4,14 @@
 [%metadata]
 identifier:: /conf/collection-input/collection-access
 target:: /req/collection-input/collection-access
-test-purpose:: Verify that the server supports the <<def-data-access-mechanism, OGC data access API(s)>> that is advertises for collection input.
+test-purpose:: Verify that the server supports the <<def_data-access-mechanism, OGC data access API(s)>> that is advertises for collection input.
 test-method::
 +
 --
 1. Obtain a process description for one or more processes offered by the server as per test <<ats_core_process-description-op,/conf/core/process-description-op>>.
 
 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. For each of the identified inputs verify that the server supports the specified <<def-data-access-mechanism, OGC data access API(s)>> 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 <<def_data-access-mechanism, OGC data access API(s)>> 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
@@ -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 <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
 4. In the specification of the collection input, specify one or more filtering elements as defined in <<collection-value-schema,"collectionValue.yaml">>.
 

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
@@ -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 <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
-4. In the specification of the collection input, specify the `passThroughParameters` element, as defined in <<collection-value-schema,"collectionValue.yaml">>, and include query parameters specific to the selected <<def-data-access-mechanism,data access API>>.
+4. In the specification of the collection input, specify the `passThroughParameters` element, as defined in <<collection-value-schema,"collectionValue.yaml">>, and include query parameters specific to the selected <<def_data-access-mechanism,data access API>>.
 
 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
@@ -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 <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
 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 <<collection-value-schema,"collectionValue.yaml">>.
 

diff --git 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 <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that includes the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that includes the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
-4. Use the `collection` parameter in the <<execute-request-body,execute request>>, as defined in <<collection-value-schema,"collectionValue.yaml">>, to reference local collection from which input values are retrieved using one of the supported <<def-data-access-mechanism,data access APIs>>.
+4. Use the `collection` parameter in the <<execute-request-body,execute request>>, as defined in <<collection-value-schema,"collectionValue.yaml">>, to reference local collection from which input values are retrieved using one of the supported <<def_data-access-mechanism,data access APIs>>.
 
 5. Verify that the execute request completes successfully.
 --

diff --git a/...tract_tests/collection-output/ATS_collection-output_data-access-mechanisms.adoc b/...tract_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 <<def-collection-description,description document>> for an output collection includes data access links using at least one supported <<def-data-access-mechanism,OGC API data access mechanisms>>.
+test-purpose:: Verify that the <<def_collection-description,description document>> for an output collection includes data access links using at least one supported <<def_data-access-mechanism,OGC API data access mechanisms>>.
 test-method::
 +
 --
-1. Retrieve the <<def-collection-description,description document>> for an output collection.
+1. Retrieve the <<def_collection-description,description document>> for an output collection.
 
-2. Verify that the <<def-collection-description,description document>> includes at least one data access link using a supported <<def-data-access-mechanism,OGC API data access mechanisms>> (e.g. features, coverages);
+2. Verify that the <<def_collection-description,description document>> includes at least one data access link using a supported <<def_data-access-mechanism,OGC API data access mechanisms>> (e.g. features, coverages);
 --
 ====
diff --git a/...tract_tests/collection-output/ATS_collection-output_response-response-many.adoc b/...tract_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 <<schema_results,results.yaml>> document containing references to <<def-collection-description,collection description documents>>.
+test-purpose:: Validate that the response for multiple explicitly or implicitly requested outputs is a <<schema_results,results.yaml>> document containing references to <<def_collection-description,collection description documents>>.
 test-method::
 +
 --
@@ -20,6 +20,6 @@ test-method::
 
 6. Verify that the body of the response conforms to the <<schema_results,results.yaml>> schema.
 
-7. Verify that that value of each collection output is a link to a <<def-collection-description,collection description document>>.
+7. Verify that that value of each collection output is a link to a <<def_collection-description,collection description document>>.
 --
 ====
diff --git a/...stract_tests/collection-output/ATS_collection-output_response-response-one.adoc b/...stract_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 <<def-collection-description,collection description document>>.
+test-purpose:: Validate that the collection output for a single explicitly or implicitly requested output is a reference to a <<def_collection-description,collection description document>>.
 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 <<def-collection-description,collection description document>>
+5. Verify that the response includes a https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2[`Location`] response header redirecting to a <<def_collection-description,collection description document>>
 --
 ====
diff --git 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 <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that include the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_collection-input_collection-access,/conf/collection-input/collection-access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
-4. For each execute request, inspect the <<value-source-server,value source server(s)>> and identify query capabilities that are not supported by those remote servers (e.g. CQL2 filtering).  
+4. For each execute request, inspect the <<def_value-source-server,value source server(s)>> 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 <<collection-value-schema,"collectionValue.yaml">> 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
@@ -4,14 +4,14 @@
 [%metadata]
 identifier:: /conf/remote-collections/access
 target:: /req/remote-collections/access
-test-purpose:: Verify that the server supports the <<def-data-access-mechanism, OGC data access APIs>> that it advertises for accessing input data from remote collections.
+test-purpose:: Verify that the server supports the <<def_data-access-mechanism, OGC data access APIs>> that it advertises for accessing input data from remote collections.
 test-method::
 +
 --
 1. Obtain a process description for one or more processes offered by the server as per test <<ats_core_process-description-op,/conf/core/process-description-op>>.
 
 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. For each of the identified inputs verify that the server supports the the specified <<def-data-access-mechanism, OGC data access API(s)>> 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 <<def_data-access-mechanism, OGC data access API(s)>> 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
@@ -4,15 +4,15 @@
 [%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 <<def-data-access-mechanism,data access API>>.
+test-purpose:: Verify that the server correctly processes input data retrieved from remote collections using a supported <<def_data-access-mechanism,data access API>>.
 test-method::
 +
 --
 1. Obtain a process description for one or more processes offered by a server as per test <<ats_core_process-description-op,/conf/core/process-description-op>>.
 
 2. Inspect the description of the inputs of each process and identify those inputs that support collection inputs (e.g. see test <<ats_ogc-process-description_data-access-apis,/conf/ogc-process-description/data-access-apis>>).
 
-3. Compose <<execute-request-body,execute requests>> that includes the identified inputs and using a supported <<def-data-access-mechanism,data access API>> (see test: <<ats_remote-collections_access,/conf/remote-collections/access>> to identify supported <<def-data-access-mechanism,data access APIs>>).
+3. Compose <<execute-request-body,execute requests>> that includes the identified inputs and using a supported <<def_data-access-mechanism,data access API>> (see test: <<ats_remote-collections_access,/conf/remote-collections/access>> to identify supported <<def_data-access-mechanism,data access APIs>>).
 
 4. Use the `collection` parameter in the <<execute-request-body,execute request>>, as defined in <<collection-value-schema,"collectionValue.yaml">>, 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
@@ -4,5 +4,5 @@
 [%metadata]
 identifier:: /per/collection-output/dynamic
 
-The server MAY arrange for the <<def-collection,output collection>> to be a "virtual" collection with processing being triggered at run-time each time the data of the collection is accessed using an <<def-data-access-mechanism,OGC API data access mechanisms>> and taking into account any spatial, temporal and other filters specified on that data access request.
+The server MAY arrange for the <<def_collection,output collection>> to be a "virtual" collection with processing being triggered at run-time each time the data of the collection is accessed using an <<def_data-access-mechanism,OGC API data access mechanisms>> and taking into account any spatial, temporal and other filters specified on that data access request.
 ====
diff --git a/...ommendations/collection-output/PER_collection-output_response-response-one.adoc b/...ommendations/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 <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>> requested outputs is 1.
+. The number of <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>> requested outputs is 1.
 . The server implements the <<profile-parameter,Profile query parameter>> requirements class.
 . The execution request also includes the <<profile-parameter,`profiles`>> query parameter.
 . The value of the <<profile-parameter,`profiles`>> 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
@@ -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 <<def-collection,output collection>>.
+The server MAY perform all the requested processing up front resulting in a fully materialized and static <<def_collection,output collection>>.
 ====
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
@@ -7,7 +7,7 @@ identifier:: /per/core/job-results-async-many-other-formats
 [.component,class=conditions]
 --
 . The <<sc_execution_mode,negotiated execution mode>> is asynchronous.
-. The number of requested (whether <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 2 or more.
+. The number of requested (whether <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 2 or more.
 --
 
 [.component,class=part]

diff --git a/...ndations/core/PER_job-results-success-async-one-multi-valued-other-formats.adoc b/...ndations/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 <<sc_execution_mode,negotiated execution mode>> is asynchronous.
-. The number of requested (whether <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
+. The number of requested (whether <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
 . In the <<sc_process_description,process description>> 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
@@ -7,12 +7,12 @@ identifier:: /per/core/process-execute-sync-one-result
 [.component,class=conditions]
 --
 . The <<sc_execution_mode,negotiated execution mode>> is synchronous,
-. The number of requested (whether <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
+. The number of requested (whether <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
 --
 
 [.component,class=part]
 --
-In the case where a single output is requested (whether <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>>), <<profile-parameter,content negotiation by profile>> MAY be used to request that the response conform to the <<schema_results,results.yaml>>  schema.
+In the case where a single output is requested (whether <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>>), <<profile-parameter,content negotiation by profile>> MAY be used to request that the response conform to the <<schema_results,results.yaml>>  schema.
 --
 
 [.component,class=part]

diff --git a/...ns/core/REC_job-results-success-async-one-multi-valued-json-prefer-minimal.adoc b/...ns/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 <<sc_execution_mode,negotiated execution mode>> is asynchronous.
-. The number of requested (whether <<implicit-process-output,implicitly>> or <<explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
+. The number of requested (whether <<def_implicit-process-output,implicitly>> or <<def_explicit-process-output,explicitly>>) outputs in the <<execute-request-body,execute request>> is 1.
 . In the <<sc_process_description,process description>> the output is defined as having `maxOccurs>1`.
 . The negotiated https://datatracker.ietf.org/doc/html/rfc7240#section-4.2[return preference] is `minimal`.
 --