More tweaks based on CR's review comments.

core/requirements/kvp-execute/REQ_bbox-crs-input-value.adoc

@@ -5,7 +5,7 @@
 identifier:: /req/kvp-execute/bbox-crs-input-value
 [.component,class=conditions]
 --
-. The server supports CRSs other than WGS84.
+. The server supports CRSs other than http://www.opengis.net/def/crs/OGC/1.3/CRS84 or http://www.opengis.net/def/crs/OGC/0/CRS84h.
 . The process input value is specified in-line in an execute request.
 . The process defines an input parameter named `{bbox-input-name}`.
 --

core/sections/clause_10_encodings.adoc

@@ -1,10 +1,6 @@
 
 == Requirements classes for encodings
 
-////
-for now, normative statements are often included inline. This will be re-factored later.
-////
-
 === Overview
 
 This clause specifies two pre-defined requirements classes for request and response message encodings to be used by implementations the Processes API. The two classes are:
@@ -18,12 +14,12 @@ The <<sc_requirements_class_json,HTML>> requirements class defines the requireme
 
 NOTE: The encoding of Processes API request and response messages is distinct from the values that are generated when executing a process.  Process output values can be of any type and are not bound by the requirements of the classes defined in this clause.
 
-NOTE: Any server that supports multiple encodings (JSON or HTML defined in this Standard or other encodings not specified in this Standard) will have to support a mechanism to mint encoding-specific URIs for resources in order to express links, for example, to alternate representations of the same resource. This document does not mandate any approach as to how this is supported by the server.
+[NOTE]
+====
+Any server that supports multiple response encodings (JSON or HTML defined in this Standard or other encodings not specified in this Standard) will have to support a mechanism to mint encoding-specific URIs for resources in order to express links, for example, to alternate representations of the same resource. This document does not mandate any approach as to how this is supported by the server.
 
 As clients simply need to dereference the URI of the link, the implementation detail and the mechanism as to how the encoding is included in the URI of the link are not important. Developers interested in the approach of a particular implementation, for example, to manipulate ("hack") URIs in the browser address bar, can study the API definition.
 
-[NOTE]
-====
 Two common approaches are:
 
 * An additional path for each encoding of each resource (this can be expressed,

core/sections/clause_11_oas.adoc

@@ -17,7 +17,7 @@ include::../requirements/oas30/REQ_oas-impl.adoc[]
 
 include::../requirements/oas30/REQ_completeness.adoc[]
 
-NOTE: Implementations of the Processes API may also include capabilities that are not specified in this Standard such as access-control (see <<security,Security>>), support for web cache validation, handling of CORS or the use of HTTP redirection.  These additional capabilities make use of HTTP status codes that are beyond the regular set of code such as `200` for successful GET requests and `400`, `404` or `500` for error situations (see <<http_status_codes>>).  These additional codes would not necessarily be specified in a OpenAPI document and so clients must be prepared to receive responses not documents in the OpenAPI definition.  For example, additional error codes may be generated in the transport layer which is outside the server. 
+NOTE: Implementations of the Processes API may also include capabilities that are not specified in this Standard such as access-control (see <<security,Security>>), support for web cache validation, handling of CORS or the use of HTTP redirection.  These additional capabilities make use of HTTP status codes that are beyond the regular set of code such as `200` for successful GET requests and `400`, `404` or `500` for error situations (see <<http_status_codes>>).  These additional codes would not necessarily be specified in a OpenAPI document and so clients must be prepared to receive responses not documented in the OpenAPI definition.  For example, additional error codes may be generated in the transport layer which is outside the server. 
 
 [[exceptions]]
 === Exceptions

core/sections/clause_12_job_list.adoc

@@ -3,7 +3,7 @@
 
 === Overview
 
-This requirement class specifies how to retrieve a job list from the API.
+This class specifies the requirements of a request that retrieves a list of jobs from the Processes API.
 
 include::../requirements/requirements_class_job-list.adoc[]
 

core/sections/clause_15_kvp-execute.adoc

@@ -52,7 +52,7 @@ NOTE: Add more examples!
 
 === Execute a process
 
-This section describes the requirements for invoking a process with an execute request encoded as a URL with query parameters.
+This section describes the requirements for an operation that invokes a process with an execute request encoded as a URL with query parameters.
 
 ==== Operation
 

core/sections/clause_2_conformance.adoc

@@ -12,15 +12,13 @@ The main requirements class is:
 
 The _Core_ specifies requirements that all Web APIs have to implement.
 
-Two requirements classes depend on the _Core_ and specify representations for the resources specified in the _Core_:
+The _Core_ does not mandate a specific encoding or format for the representation of resources defined in this Standard.  Rather, two requirements classes depend on the _Core_ and specify representations for the resources specified in the _Corea_ in commonly used encodings for data on the Web:
 
 * <<rc_json,JSON>>, and
 
 * <<rc_html,HTML>>.
 
-The JSON encoding is mandatory.
-
-The _Core_ does not mandate any encoding or format for the formal definition of the Processes API. OpenAPI 3.0 specification is one option for defining the Processes API. As such a requirements class has been specified for OpenAPI 3.0, which depends on the requirements class _Core_:
+Furthermore, the _Core_ does not mandate any encoding or format for the formal definition of the Processes API. OpenAPI 3.0 specification is one option for defining the Processes API. As such a requirements class has been specified for OpenAPI 3.0, which depends on the requirements class _Core_:
 
 * <<rc_oas30,OpenAPI Specification 3.0>>.
 
@@ -35,9 +33,7 @@ See also the note regarding <<req_core_landingpage-success,/req/core/landingpage
 
 An implementation of the _Core_ is intended to be a minimal useful API for the execution of processes in the geospatial domain. The Core is designed to map the operations of a Web Processing Service 2.0 instance.
 
-The _Core_ does not mandate the use of any specific process description to
-specify the interface of a process. Instead this Standard defines and
-recommends the use of the following conformance class:
+The _Core_ does not mandate the use of any specific process description language to specify the interface of a process. Instead this Standard defines and recommends the use of the following conformance class:
 
 * <<rc_ogc-process-description,OGC Process Description>>
 

core/sections/clause_5_conventions.adoc

@@ -12,6 +12,13 @@ http://www.opengis.net/spec/ogcapi-processes-1/1.0
 
 All requirements, permission, recommendations, and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
 
+=== APIs
+
+This Standard is primarily concerned with defining the components of a Processes API.  That is an API that enables the execution of computing processes, the retrieval of metadata describing their purpose and functionality and the retrieval of the results of the process execution.  The reader, however, should be cogniscant of the fact that an implementation of the Processes API as defined in this Standard may be embeded as part of a broader API.  For example, a single server may implement the https://docs.ogc.org/is/17-069r4/17-069r4.html#_references[Features] and Processes APIs and so common elements (such as the landing page) will contain components of both standards.  When the term "API" is encountered in this Standard, the term is in most cases referring only to the components of a Processes API even though an implementation of the Processes API may be part of a broader API implementation.
+
+=== Schemas
+
+Schemas defined in this Standard are defined using the https://json-schema.org/specification[JSON Schema] standard and are encoded using https://yaml.org/spec/1.2.2/[YAML] which is a human-friendly data serialization language.
 
 === Link relations
 
@@ -25,7 +32,9 @@ The following https://www.iana.org/assignments/link-relations/link-relations.xht
 
 * **service-desc**: Identifies service description for the context that is primarily intended for consumption by machines.
 
-** In this Standard, https://swagger.io/specification/v3/[OpenAPI 3.0] is used to provide a formal, machine readable, description of the service but other API definition representations can also be used.
+** API definitions are considered service descriptions.
+
+** In this Standard, https://swagger.io/specification/v3/[OpenAPI 3.0] is used to provide a formal, machine readable, definition of the service but other API definition representations can also be used.
 
 * **service-doc**: Identifies service documentation for the context that is primarily intended for human consumption.
 
@@ -51,10 +60,6 @@ In addition, the following link relation types are used for which no applicable
 
 Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by an implementation of the Processes API.
 
-=== Schemas
-
-Schemas defined in this Standard are defined using the https://json-schema.org/specification[JSON Schema] standard and are encoded using https://yaml.org/spec/1.2.2/[YAML] which is a human-friendly data serialization language.
-
 === Use of HTTPS
 
 For simplicity, this Standard only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS. This is simply a shorthand notation for "HTTP or HTTPS". In fact, most servers are expected to use <<rfc2818,HTTPS>>, not <<rfc2616,HTTP>>.
@@ -64,7 +69,3 @@ OGC Web API Standards do not prohibit the use of any valid HTTP option. However,
 === HTTP URIs
 
 This Standard does not restrict the lexical space of URIs used in an implementation of the Processes API beyond the requirements of the <<rfc2616,HTTP>> and <<rfc3986,URI Syntax>> IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these must be percent-encoded. See Clause 2 of <<rfc3986,RFC 3986 (URI Syntax)>> for details.
-
-=== APIs
-
-This Standard is primarily concerned with defining the components of a Processes API.  That is an API that enables the execution of computing processes, the retrieval of metadata describing their purpose and functionality and the retrieval of the results of the process execution.  The reader, however, should be cogniscant of the fact that an implementation of the Processes API as defined in this Standard may be embeded as part of a broader API.  For example, a server may implement the https://docs.ogc.org/is/17-069r4/17-069r4.html#_references[Features] and Processes APIs and so common elements (such as the landing page) will contain components of both the https://docs.ogc.org/is/17-069r4/17-069r4.html#_references[Features API] and the Processes API defined in this Standard.  When the term "API" is encountered in this Standard, the term is referring only to the components of a Processes API even though the Processes API may be part of a broader API.

core/sections/clause_7_core.adoc

@@ -18,13 +18,9 @@ Each implementation of the OGC API - Processes Standard has a single `LandingPag
 
 Note that additional requirements classes may introduce additional links for inclusion in the landing page.
 
-The `APIDefinition` describes the capabilities of the server that can be used by
-clients to connect to the server or by development tools to support the
-implementation of servers and clients. Accessing the `APIDefinition` using
-HTTP GET returns a description of the an API that includes the Processes API defined in this Standard by may include the description of a broader containing API.
+The `APIDefinition` describes the capabilities of the server that can be used by clients to connect to the server or by development tools to support the implementation of servers and clients. Accessing the `APIDefinition` using HTTP GET returns a description of the an API that includes the Processes API defined in this Standard but may include the description of additional components that are part of a broader containing API.
 
-Accessing `Conformance` using HTTP GET returns a list of URIs of
-conformance classes implemented by the server.
+Accessing `Conformance` using HTTP GET returns a list of URIs of conformance classes implemented by the server.
 
 The list of processes contains a summary of each process offered by the OGC API - Processes implementation, including the link to a more detailed description of the process.
 
@@ -58,11 +54,7 @@ The OGC API - Processes Standard utilizes elements of the OGC API-Common Standar
 [[sc_landing_page]]
 === Retrieve the API landing page
 
-The following section defines the requirements to retrieve an API landing page that includes Processes API endpoint but may also include endpoints of a broader, containing, API.  
-
-In this Standard the term "API" is meant to indicate those elements a
-
-however, we will limit discussion to those endpoints defined in the Processes Standard but the reader should be cogniscent of the fact that the implemented API may be a broaded API that also contains Processes API components.
+The following section defines the requirements to retrieve an API landing page that contains links to Processes API resources but may also contain links to resources that are part of a broader, containing, API.  
 
 ==== Operation
 
@@ -152,7 +144,7 @@ the Accept header of the HTTP request.
 
 The API definition document describes the API. In other words, there is no need to include the `/api` operation in the API definition itself.
 
-The idea is that any implementation of OGC API - Processes can be used by developers that are familiar with the API definition language(s) supported by the server. For example, if an OpenAPI definition is used, it should be possible to create a working client using the OpenAPI definition. 
+The idea is that any implementation of OGC API - Processes can be used by developers that are familiar with the API definition language(s) supported by the server. For example, if an OpenAPI definition is used, it should be possible to create the skeleton of a working client using the OpenAPI definition alone.
 
 ==== Error situations
 
@@ -297,7 +289,7 @@ An implementation of the Processes API could use opaque links that are managed b
 
 Another implementation approach is to use an implementation-specific parameter that specifies the index within the result set from which the server begins presenting results in the response, like `offset` or the `startIndex` parameter that was used in <<WFS20,WFS 2.0>>.
 
-An implementation of the Processes API will return no `next` link, if all selected results have been returned, and the server knows for certain that there are not further results to be presented.  However, in some cases, the server may not be aware that it has already returned all selected results. For example, if the request states `limit=10` and the query to the backend returns exactly 10 results.  The server may not know if there are more results or not (in most cases there will be more results), unless the total number of results is also computed, which may be too costly. The server will then prudently add the next link, and if there are no more results, dereferencing the next link will return an empty results list and no next link. This behavior is consistent with the statements above.
+An implementation of the Processes API will return no `next` link, if all selected results have been returned, and the server knows for certain that there are no further results to be presented.  However, in some cases, the server may not be aware that it has already returned all selected results. For example, if the request states `limit=10` and the query to the backend returns exactly 10 results.  The server may not know if there are more results or not (in most cases there will be more results), unless the total number of results is also computed, which may be too costly. The server will then prudently add the `next` link, and if there are no more results, dereferencing the next link will return an empty results list and no `next` link. This behavior is consistent with the statements above.
 
 Clients should not assume that paging is safe against changes to the dataset being accesses while a client iterates through `next` links. If a server provides opaque links these could be safe and maintain the state during the original request. Using a parameter for the start index, however, will not be safe.
 
@@ -312,7 +304,9 @@ include::../recommendations/core/REC_link-header.adoc[]
 [[sc_process_list]]
 === Retrieve a process list
 
-The following section defines the requirements to retrieve the available processes offered by an implmentation of the Processes API.  It should be noted that the number of processes offered via the API may be very different than the number of processes offer by a back-end system upon which the Processes API is implemented.
+The following section defines the requirements to retrieve the available processes offered by an implmentation of the Processes API.
+
+It should be noted that the number of processes exposed via the Processes API may be very different than the number of processes offer by a back-end system upon which the Processes API is implemented.
 
 ==== Operation