opengeospatial · pvretano · Mar 4, 2024 · Feb 19, 2024 · Feb 19, 2024 · Mar 4, 2024
diff --git a/core/abstract_tests/ATS_class_dismiss.adoc b/core/abstract_tests/ATS_class_dismiss.adoc
@@ -14,7 +14,7 @@ include::dismiss/ATS_job-dismiss-op.adoc[]
 
 include::dismiss/ATS_job-dismiss-success.adoc[]
 
-NOTE: The response to dismissing a job can be presented in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate against that schema. All supported formats should be exercised.
+NOTE: The response to dismissing a job can be presented in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate against that schema. All supported formats should be exercised.
 
 [[job-dismiss-schema]]
 .Schema and Tests for Dismissing a Job

diff --git a/core/abstract_tests/ATS_class_job-list.adoc b/core/abstract_tests/ATS_class_job-list.adoc
@@ -55,7 +55,7 @@ include::job-list/ATS_limit-response.adoc[]
 include::job-list/ATS_links.adoc[]
 
 
-NOTE: A job list may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
+NOTE: A job list may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
 
 [[job-list-schema]]
 .Schema and Tests for Job List Content

diff --git a/core/abstract_tests/callback/ATS_process-execute-callback.adoc b/core/abstract_tests/callback/ATS_process-execute-callback.adoc
@@ -9,7 +9,7 @@ test-purpose:: Validate the passing of a subscriber-URL in an execute request.
 test-method::
 +
 --
-1. Configure a URL endpoint to accept message body from the server.
+1. Configure a URL endpoint to accept a message body from the server.
 
 2. Create an asynchronous execute request that includes the optional `subscriber` key (see https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/execute.yaml[execute.yaml].
 

diff --git a/core/abstract_tests/core/ATS_api-definition-op.adoc b/core/abstract_tests/core/ATS_api-definition-op.adoc
@@ -11,7 +11,7 @@ test-method::
 --
 1. Construct a path for the API Definition document that ends with `/api`.
 
-2. Issue a HTTP GET request on that path
+2. Issue a HTTP GET request on that path.
 
 3. Validate the contents of the returned document using test <<ats_core_api-definition-success,/conf/core/api-definition-success>>.
 --

diff --git a/core/abstract_tests/core/ATS_api-definition-success.adoc b/core/abstract_tests/core/ATS_api-definition-success.adoc
@@ -9,7 +9,7 @@ test-purpose:: Validate that the API Definition complies with the required struc
 test-method::
 +
 --
-1. Validate that a document was returned with a status code 200
+1. Validate that a document was returned with a status code 200.
 
 2. Validate the API Definition document against an appropriate schema document.
 --

diff --git a/core/abstract_tests/core/ATS_conformance-op.adoc b/core/abstract_tests/core/ATS_conformance-op.adoc
@@ -11,7 +11,7 @@ test-method::
 --
 1. Construct a path for each "rel=http://www.opengis.net/def/rel/ogc/1.0/conformance" link on the landing page as well as for the {root}/conformance path.
 
-2. Issue an HTTP GET request on each path
+2. Issue an HTTP GET request on each path.
 
 3. Validate the contents of the returned document using test <<ats_core_conformance-success,/conf/core/conformance-success>>.
 --

diff --git a/core/abstract_tests/core/ATS_conformance-success.adoc b/core/abstract_tests/core/ATS_conformance-success.adoc
@@ -11,9 +11,9 @@ test-method::
 --
 1. Validate that a document was returned with an HTTP status code of 200.
 
-2. Validate the response document against OpenAPI 3.0 schema link: http://schemas.opengis.net/ogcapi/processes/part1/1.0/openapi/schemas/confClasses.yaml[confClasses.yaml]
+2. Validate the response document against OpenAPI 3.0 schema link: http://schemas.opengis.net/ogcapi/processes/part1/1.0/openapi/schemas/confClasses.yaml[confClasses.yaml].
 
-3. Validate that the document includes the conformance class "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core"
+3. Validate that the document includes the conformance class "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core".
 
 4. Validate that the document list all OGC API conformance classes that the API implements.
 --

diff --git a/core/abstract_tests/core/ATS_job-exception-no-such-job.adoc b/core/abstract_tests/core/ATS_job-exception-no-such-job.adoc
@@ -19,7 +19,7 @@ test-method::
 --
 ====
 
-NOTE: An exception response caused by the use of an invalid job identifier may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the response. All supported formats should be exercised.
+NOTE: An exception response caused by using an invalid job identifier may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the response. All supported formats should be exercised.
 
 [[job-exception-no-such-job]]
 .Schema and Tests for the Job Result for Non-existent Job

diff --git a/core/abstract_tests/core/ATS_job-results-exception-no-such-job.adoc b/core/abstract_tests/core/ATS_job-results-exception-no-such-job.adoc
@@ -19,7 +19,7 @@ test-method::
 --
 ====
 
-NOTE: The job results page for a job may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for a non-existent job against that schema.  All supported formats should be exercised.
+NOTE: The job results page for a job may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for a non-existent job against that schema.  All supported formats should be exercised.
 
 [[job-results-exception-no-such-job]]
 .Schema and Tests for the Job Result for Non-existent Job

diff --git a/core/abstract_tests/core/ATS_job-results-exception-results-not-ready.adoc b/core/abstract_tests/core/ATS_job-results-exception-results-not-ready.adoc
@@ -9,7 +9,7 @@ test-purpose:: Validate that the job results retrieved for an incomplete job com
 test-method::
 +
 --
-1. Create a job as per <<ats_core_process-execute-op,/req/core/process-execute-op>> and note the {jobID} assigned to the job; ensure that the job is long-running.
+1. Create a job as per <<ats_core_process-execute-op,/req/core/process-execute-op>> and note the {jobID} assigned to the job. Ensure that the job is long-running.
 
 2. Issue an HTTP GET request to the URL '/jobs/{jobID}/results' before the job completes execution.
 
@@ -21,7 +21,7 @@ test-method::
 --
 ====
 
-NOTE: The job results page for a job may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for an incomplete job against that schema.  All supported formats should be exercised.
+NOTE: The job results page for a job may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for an incomplete job against that schema.  All supported formats should be exercised.
 
 [[job-results-exception-results-not-ready]]
 .Schema and Tests for the Job Result for an Incomplete Job

diff --git a/core/abstract_tests/core/ATS_job-results-failed.adoc b/core/abstract_tests/core/ATS_job-results-failed.adoc
@@ -9,9 +9,9 @@ test-purpose:: Validate that the job results for a failed job complies with the
 test-method::
 +
 --
-1. Create a job as per <<ats_core_process-execute-op,/req/core/process-execute-op>> but arrange a priori that the job will fail; note the {jobID} assigned to the job.
+1. Create a job as per <<ats_core_process-execute-op,/req/core/process-execute-op>> but arrange a priori that the job will fail. Note the {jobID} assigned to the job.
 
-2. Ensure that the failed job will not result in an HTTP error code of 404.
+2. Ensure that the failed job will not result in an HTTP 404 error code.
 
 3. Issue an HTTP GET request to the URL '/jobs/{jobID}/results'.
 
@@ -23,7 +23,7 @@ test-method::
 --
 ====
 
-NOTE: The job results page for a job may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for a failed job against that schema.  All supported formats should be exercised.
+NOTE: The job results page for a job may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the job results for a failed job against that schema.  All supported formats should be exercised.
 
 [[job-results-failed-schema]]
 .Schema and Tests for the Job Result for a Failed Job

diff --git a/core/abstract_tests/core/ATS_job-success.adoc b/core/abstract_tests/core/ATS_job-success.adoc
@@ -15,7 +15,7 @@ test-method::
 --
 ====
 
-NOTE: The status info page for a job may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the status info against that schema. All supported formats should be exercised.
+NOTE: The status info page for a job may be retrieved in a one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the status info against that schema. All supported formats should be exercised.
 
 [[job-status-info-schema]]
 .Schema and Tests for the Job Status Info

diff --git a/core/abstract_tests/core/ATS_landingpage-success.adoc b/core/abstract_tests/core/ATS_landingpage-success.adoc
@@ -26,7 +26,7 @@ test-method::
 
 ====
 
-NOTE: The landing page may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the landing page against that schema. All supported formats should be exercised.
+NOTE: The landing page may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the landing page against that schema. All supported formats should be exercised.
 
 [[landing-page-schema]]
 .Schema and Tests for Landing Pages

diff --git a/core/abstract_tests/core/ATS_process-description-success.adoc b/core/abstract_tests/core/ATS_process-description-success.adoc
@@ -15,7 +15,7 @@ test-method::
 --
 ====
 
-NOTE: The interface of a process may be describing using a number of different models or process description languages. The following table identifies the applicable schema document for each process description model described in this standard.
+NOTE: The interface of a process may be described using one of a number of different models or process description languages. The following table identifies the applicable schema document for each process description model described in this standard.
 
 [[process-description-model]]
 .Schema and Tests for Process Description Models

diff --git a/core/abstract_tests/core/ATS_process-exception-no-such-process.adoc b/core/abstract_tests/core/ATS_process-exception-no-such-process.adoc
@@ -19,7 +19,7 @@ test-method::
 --
 ====
 
-NOTE: An exception response caused by the use of an invalid process identifier may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the response. All supported formats should be exercised.
+NOTE: An exception response caused by using an invalid process identifier may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the response. All supported formats should be exercised.
 
 [[no-such-process]]
 .Schema and Tests for Non-existent Process

diff --git a/core/abstract_tests/core/ATS_process-execute-input-array.adoc b/core/abstract_tests/core/ATS_process-execute-input-array.adoc
@@ -11,7 +11,7 @@ test-method::
 --
 1. Get a description of each process offered by the server using test <<ats_core_process-description,/conf/core/process-description>>.
 
-2. Inspect the description of each process and identify the list of processes that have inputs with a maximum cardinality greater that one.
+2. Inspect the description of each process and identify the list of processes that have inputs with a maximum cardinality greater than one.
 
 3. For each identified process construct an execute request according to test <<ats_core_process-execute-request,/conf/core/process-execute-request>> taking care to encode the inputs with maximum cardinality > 1 according to the requirement <<req_core_process-execute-input-array,/req/core/process-execute-input-array>>.
 

diff --git a/core/abstract_tests/core/ATS_process-execute-input-inline-bbox.adoc b/core/abstract_tests/core/ATS_process-execute-input-inline-bbox.adoc
@@ -15,6 +15,6 @@ test-method::
 
 3. For each identified process construct an execute request according to test <<ats_core_process-execute-request,/conf/core/process-execute-request>> taking care to encode values for the identified bounding box inputs in-line in the execute request.
 
-4. Verify that each process execute successfulle according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) based on the combination of execute parameters.
+4. Verify that each process executes successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) based on the combination of execute parameters.
 --
 ====
diff --git a/core/abstract_tests/core/ATS_process-execute-input-inline-binary.adoc b/core/abstract_tests/core/ATS_process-execute-input-inline-binary.adoc
@@ -15,6 +15,6 @@ test-method::
 
 3. For each identified process construct an execute request according to test <<ats_core_process-execute-request,/conf/core/process-execute-request>> taking care to encode binary input values in-line in the execute request according to requirement <<req_core_process-execute-input-inline-binary,/req/core/process-execute-input-inline-binary>>.
 
-4. Verify that each process execute successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) base on the combination of execute parameters.
+4. Verify that each process executes successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) base on the combination of execute parameters.
 --
 ====
diff --git a/core/abstract_tests/core/ATS_process-execute-input-inline-mixed.adoc b/core/abstract_tests/core/ATS_process-execute-input-inline-mixed.adoc
@@ -15,6 +15,6 @@ test-method::
 
 3. For each identified process construct an execute request according to test <<ats_core_process-execute-request,/conf/core/process-execute-request>> taking care to encode the identified mix-content inputs in-line in the execute request according to requirement <<req_core_process-execute-input-inline-mixed,/req/core/process-execute-input-inline-mixed>>.
 
-4. Verify that each process execute successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) base on the combination of execute parameters.
+4. Verify that each process executes successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) base on the combination of execute parameters.
 --
 ====
diff --git a/core/abstract_tests/core/ATS_process-execute-input-inline-object.adoc b/core/abstract_tests/core/ATS_process-execute-input-inline-object.adoc
@@ -15,6 +15,6 @@ test-method::
 
 3. For each identified process construct an execute request according to test <<ats_core_process-execute-request,/conf/core/process-execute-request>> taking care to encode the identified object inputs in-line in the execute request according to requirement <<req_core_process-execute-input-inline-object,/req/core/process-execute-input-inline-object>>.
 
-4. Verify that each process execute successfulle according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) based on the combination of execute parameters.
+4. Verify that each process executes successfully according to the relevant requirement (one of: <<ats_core_process-execute-success-async,/req/core/process-execute-success-async>>, <<ats_core_process-execute-sync-many-json,/req/core/process-execute-sync-many-json>>, <<ats_core_process-execute-sync-one,/req/core/process-execute-sync-one>>, <<ats_core_process-execute-sync-one-default-content,/req/core/process-execute-sync-one-default-content>>) based on the combination of execute parameters.
 --
 ====
diff --git a/core/abstract_tests/core/ATS_process-list-limit-def.adoc b/core/abstract_tests/core/ATS_process-list-limit-def.adoc
@@ -13,4 +13,4 @@ Verify that the `limit` query parameter complies with its definition in requirem
 --
 ====
 
-NOTE: The API can define different values for "minimum", "maximum" and "default".
+NOTE: An implementation of the Processes API can define different values for "minimum", "maximum" and "default".
diff --git a/core/abstract_tests/core/ATS_process-list-success.adoc b/core/abstract_tests/core/ATS_process-list-success.adoc
@@ -15,7 +15,7 @@ test-method::
 --
 ====
 
-NOTE: The process list may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
+NOTE: The process list may be retrieved in one of two formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
 
 [[process-list-schema]]
 .Schema and Tests for Lists content

diff --git a/core/abstract_tests/html/ATS_content.adoc b/core/abstract_tests/html/ATS_content.adoc
@@ -9,7 +9,7 @@ test-purpose:: Verify the content of an HTML document given an input document an
 test-method::
 +
 --
-. Validate that the document is an <<w3c-html5>> document
+. Validate that the document is an <<w3c-html5>> document.
 
 . Manually inspect the document and verify that the HTML body contains:
 

diff --git a/core/abstract_tests/html/ATS_definition.adoc b/core/abstract_tests/html/ATS_definition.adoc
@@ -9,6 +9,6 @@ test-purpose:: Verify support for HTML
 test-method::
 +
 --
-Verify that every `200` response of every operation of the API where HTML was requested is of media type `text/html`.
+Verify that every `200` response for every operation of the Processes API implementation for which HTML was requested is of media type `text/html`.
 --
 ====
diff --git a/core/abstract_tests/job-list/ATS_limit-def.adoc b/core/abstract_tests/job-list/ATS_limit-def.adoc
@@ -13,4 +13,4 @@ Verify that the `limit` query parameter complies with its definition in requirem
 --
 ====
 
-NOTE: The API can define different values for "minimum", "maximum" and "default".
+NOTE: An implementation of the Processes API can define different values for "minimum", "maximum" and "default".
diff --git a/core/abstract_tests/ogc-process-description/ATS_output-mixed-type.adoc b/core/abstract_tests/ogc-process-description/ATS_output-mixed-type.adoc
@@ -11,7 +11,7 @@ test-method::
 --
 1. Retrieve a description of each process according to test <<ats_core_process-description,/conf/core/process-description>>.
 
-2. For each process identify if the process has one or more output of mixed type denoted by the use of the `oneOf` JSON Schema keyword.
+2. For each process identify if the process has one or more output of mixed type denoted by using the `oneOf` JSON Schema keyword.
 
 3. For each sub-schema or each identified output, verify that the definition validates according to the JSON Schema: https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/schema.yaml[schema.yaml].
 --

diff --git a/core/recommendations/core/PER_api-definition-uri.adoc b/core/recommendations/core/PER_api-definition-uri.adoc
@@ -4,6 +4,5 @@
 [%metadata]
 label:: /per/core/api-definition-uri
 
-The API definition is metadata about the API and strictly not part of the API
-itself, but it MAY be hosted as a sub-resource to the base path of the API, for example, at path `/api`. There is no need to include the path of the API definition in the API definition itself.
-====
+The API definition is metadata about the capabilities provided by an API implementation instance and strictly speaking is not part of the API itself, but the definition MAY be hosted as a sub-resource to the base path of the API, for example, at path `/api`. There is no need to include the path of the API definition in the API definition itself.
+====