I. Abstract

The OGC API — Processes — Part 1: Core Standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application. The standard specifies a processing interface to communicate over a RESTful protocol using JavaScript Object Notation (JSON) encodings. The standard leverages concepts from the OGC Web Processing Service (WPS) 2.0 Interface Standard but does not require implementation of a WPS.

By way of background and context, in many cases geospatial or location data, including data from sensors, must be processed before the information can be effectively used. The WPS Standard provides a standard interface that simplifies the task of making simple or complex computational geospatial processing services accessible via web services. Such services include well-known processes found in Geographic Information Systems (GIS) as well as specialized processes for spatiotemporal modeling and simulation. While the WPS standard was designed with spatial processing in mind, the standard could also be used to readily insert non-spatial processing tasks into a web services environment.

The OGC API — Processes Standard is a newer and more modern way of programming and interacting with resources over the web while allowing better integration into existing software packages. The OGC API — Processes Standard addresses all of the use cases that were addressed by the WPS Standard, while also leveraging the OpenAPI specification and a resource-oriented approach.

The resources that are provided by a server implementing the OGC API — Processes Standard are listed in Table 1 below and include information about the server, the list of available processes (Process list and Process description), jobs (running processes) and results of process executions.

Table 1 — Requirements class ‘Core’ — Overview of resources, applicable HTTP methods and links to the document sections

Resource	Path	HTTP method	Parameter	Document reference
Landing page	`/`	GET	N/A	Clause 7.2
Conformance classes	`/conformance`	GET	N/A	Clause 7.4
Process list	`/processes`	GET	N/A	Clause 7.9
Process description	`/processes/{processID}`	GET	processID (in path)	Clause 7.10
Process execution	`/processes/{processID}/execution`	POST	processID (in path), Execute request (contained in body)	Clause 7.11
Job status info	`/jobs/{jobID}`	GET	jobID (in path)	Clause 7.12
Job results	`/jobs/{jobID}/results`	GET	jobID (in path)	Clause 7.13

In general, the HTTP GET operation is used to provide access to the resources described above. However, in order to execute a process, the HTTP POST method is used to send an execution request to the server.

Additionally, the /jobs endpoint can be used to grant access to a list of jobs.

Table 2 — Requirements class ‘Job list’ — Overview of resources, applicable HTTP methods and links to the document sections

Resource	Path	HTTP method	Parameter	Document reference
Job list	`/jobs`	GET	N/A	Clause 11

In addition to the operations accessible through HTTP GET and POST methods, the DELETE method can be used to cancel a job execution and/or remove traces of the job execution.

Table 3 — Requirements class ‘Dismiss’ — Overview of resources, applicable HTTP methods and links to the document sections

Resource	Path	HTTP method	Parameter	Document reference
Job status info	`/jobs/{jobID}`	DELETE	jobID (in path)	Clause 13

The OGC API — Processes — Part 1: Core Standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application. Examples of computational processes that can be supported by implementations of this specification include raster algebra, geometry buffering, constructive area geometry, routing, imagery analysis and several others.

II. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, OGC API, Geospatial API, processes, Web Processing Service, WPS, JSON, HTML, geoprocessing, API, OpenAPI, HTML

III. Security Considerations

The OGC API — Processes Standard specifies a Web 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 API makes use of different HTTP methods, namely GET, POST and DELETE. (Note that future extensions could introduce additional HTTP methods.)

HTTP methods can be classified as

Safe, meaning that they do not alter the state of (a resource on) the server, and
Idempotent, meaning that can be executed an indefinite number of times and deliver the same result.

Table 4 gives an overview of the classification of HTTP the methods used in this standard:

Table 4 — Classification of HTTP methods

HTTP Method	Safe	Idempotent
GET	yes	yes
POST	no	no
DELETE	no	yes
Source RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

The following resources can be retrieved using the safe HTTP GET operation and can contain sensitive information:

Requirements class “Core”:

Process list
Process description
Job status info
Job results

Requirements class “Job list”

list

The following API operations use unsafe HTTP methods, modify resources and therefore require special attention:

Requirements class “Core”:

Execute, HTTP POST

Requirements class “Dismiss”

Dismiss, HTTP DELETE

III.A. Operations using HTTP GET

Most of the operations defined in this standard are use the safe HTTP GET operation. However, the resources that are returned by these operations contain information that could be used to exploit the API. Table 5 gives an overview of the resources specified in this standard and what kind of information they contain.

Table 5 — Requirements class ‘Core’ — Overview of core operations and returned sensitive information

Resource	Path	HTTP method	Information delivered
Landing page	`/`	GET	General information about the service, links to API endpoints
Conformance classes	`/conformance`	GET	List of conformance classes
Process list	`/processes`	GET	Process identifiers, links to process descriptions
Process description	`/processes/{processID}`	GET	Information about a process, e.g. inputs/outputs
Job status info	`/jobs/{jobID}`	GET	Status info, links to results or exceptions
Job results	`/jobs/{jobID}/results`	GET	Job results

The resources and contained information in more detail:

The landing page contains links to the API endpoints and so leads to all other resources the API offers.
The list of conformance classes could contain information about extensions like “dismiss” that pose additional security issues.
The process list contains process identifiers and links to the respective process descriptions.
The process description contains all necessary information needed to execute a process. This information can be used to send an JSON execute request to the API that will pass initial sanity checks, for example checks for the correct input/output identifiers. If this barrier is taken by an attacker, issues as discussed in section Clause III.B can occur.
The job status info contains not only status information, but for finished processes also links to results / exceptions. The results of a process execution are a valuable resource as well as the exceptions that could contain hints about why the execution has failed.

Table 6 — Requirements class ‘Job List’ — Overview of operations and returned sensitive information

Resource	Path	HTTP method	Information delivered
Job list	`/jobs`	GET	List of job ids and status info, links to results or exceptions

The retrieval of the job list of a process returns the job ids and links to the respective job status.

III.B. Execute operation

The execute operation uses HTTP POST to create new processing jobs (process executions). As discussed above, the HTTP POST method is not safe and it poses the following threats if misused:

The processing can use up considerable server resources, for example computing time, network traffic (when accessing referenced inputs) or storage space for inputs and outputs.
Malicious inputs can be provided. Either inline in the execute request JSON or referenced.

Table 7 — Requirements class ‘Core’ — Overview of the execute operation and returned sensitive information

Resource	Path	HTTP method	Information delivered
Job status info	`/jobs`	POST	Job id, status info, (links to) results or exceptions

The ids that are used for new jobs and that are returned in the status info document should be created in a non-guessable way, for example using UUIDs. This will prevent random attempts to get job status information, results / exceptions or even cancel jobs / delete job artifacts.

Recommendation 1
/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.

III.C. Dismiss operation

The optional dismiss extension uses the HTTP DELETE method and can be used to

Cancel a running job, and
Remove artifacts of a finished job.

Both usages pose security related issues. The cancellation of a running job (if not done on purpose) is wasting the resources that the job has used until it was cancelled. The same goes for the unwanted removal of artifacts of a finished job. If the dismiss extension is implemented, access control for the operation should be considered. The dismiss operation is idempotent, as it is specified by this standard to be called using a specific job identifier. The first dismiss request to that identifier will result in a HTTP 200 (OK) status code. Continued dismiss requests using the same identifier result in a HTTP 410 (Gone) error code, but nothing else is changed on the server. A successful dismiss request returns a status info document containing the job identifier and the status “dismissed”. This status info document has no further security implications.

IV. Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

52°North GmbH
Hexagon
CubeWerx Inc.
Ecere Corporation
Terradue Srl
European Space Agency (ESA)
Spacebel

V. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name	Affiliation
Benjamin Pross (editor)	52°North GmbH
Stan Tillman	Hexagon
Panagiotis (Peter) A. Vretanos (editor)	CubeWerx Inc.
Jérôme Jacovella-St-Louis	Ecere Corporation
Pedro Gonçalves	Terradue Srl
Gérald Fenoy	Gérald Fenoy (Individual Member)
Cristiano Lopes	European Space Agency (ESA)
Christophe Noel	Spacebel

OGC API - Processes - Part 1: Core

1. Scope

This OGC Standard specifies a Web API that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. Typically, these processes combine raster, vector, coverage and/or point cloud data with well-defined algorithms to produce new raster, vector, coverage and/or point cloud information.

2. Conformance

This standard defines seven requirements / conformance classes.

The standardization targets of all conformance classes are “Web APIs.”

The main requirements class is:

Core.

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:

JSON, and
HTML.

The JSON encoding is mandatory.

The Core does not mandate any encoding or format for the formal definition of the API. OpenAPI 3.0 specification is one option for defining the Processing API. As such a requirements class has been specified for OpenAPI 3.0, which depends on the requirements class Core:

OpenAPI Specification 3.0.

An implementation of the Core requirements class may also decide to use other API definition representations in addition to, or instead of, an OpenAPI 3.0 definition. Examples for alternative API definitions: OpenAPI 2.0 (Swagger), future versions of the OpenAPI specification, an OWS Common 2.0 capabilities document or WSDL.

NOTE OpenAPI 3.0 offers an open, powerful and vendor neutral description format. While the use of OpenAPI 3.0 for the formal definition of the API is not mandatory, the requests/responses of the API specified in this standard are defined using OpenAPI 3.0 schemas. See also the note regarding /req/core/landingpage-success

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:

OGC Process Description

This class defines an information model, encoded in JSON, which may be used to specify the interface of a process.

Three additional conformance classes are specified that extend the basic functionality of an API:

Job list, and
Callback, and
Dismiss.

Additional capabilities such as support for transactions, extended job monitoring, etc., may be specified in future parts of the OGC API — Processes series or as vendor-specific extensions.

Conformance with this standard SHALL be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

Table 8 — Conformance class URIs

Conformance class	URI
Core	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core
OGC Process Description	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/ogc-process-description
JSON	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/json
HTML	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/html
OpenAPI Specification 3.0	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/oas30
Job list	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/job-list
Callback	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/callback
Dismiss	http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/dismiss

3. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009). https://portal.ogc.org/files/?artifact_id=34762&version=2

Arliss Whiteside Jim Greenwood : OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact_id=38867

Matthias Mueller: OGC 14-065, OGC® WPS 2.0 Interface Standard. Open Geospatial Consortium (2015). http://docs.opengeospatial.org/is/14-065/14-065r0.html

T. Dierks, C. Allen: IETF RFC 2246, The TLS Protocol Version 1.0. Internet Engineering Task Force, Fremont, CA (1999). https://www.rfc-editor.org/info/rfc2246

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: IETF RFC 2616, Hypertext Transfer Protocol — HTTP/1.1. Internet Engineering Task Force, Fremont, CA (1999). https://www.rfc-editor.org/info/rfc2616

J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart: IETF RFC 2617, HTTP Authentication: Basic and Digest Access Authentication. Internet Engineering Task Force, Fremont, CA (1999). https://www.rfc-editor.org/info/rfc2617

E. Levinson: IETF RFC 2387, The MIME Multipart/Related Content-type. Internet Engineering Task Force, Fremont, CA (1998). https://www.rfc-editor.org/info/rfc2387

E. Rescorla: IETF RFC 2818, HTTP Over TLS. Internet Engineering Task Force, Fremont, CA (2000). https://www.rfc-editor.org/info/rfc2818

T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force, Fremont, CA (2005). https://www.rfc-editor.org/info/rfc3986

A. Phillips, M. Davis: IETF RFC 4646, Tags for Identifying Languages. Internet Engineering Task Force, Fremont, CA (2006). https://www.rfc-editor.org/info/rfc4646

R. Fielding, J. Reschke: IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Internet Engineering Task Force, Fremont, CA (2014). https://www.rfc-editor.org/info/rfc7231

J. Snell: IETF RFC 7240, Prefer Header for HTTP. Internet Engineering Task Force, Fremont, CA (2014). https://www.rfc-editor.org/info/rfc7240

M. Nottingham: IETF RFC 8288, Web Linking. Internet Engineering Task Force, Fremont, CA (2017). https://www.rfc-editor.org/info/rfc8288

T. Bray: IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. Internet Engineering Task Force, Fremont, CA (2017). https://www.rfc-editor.org/info/rfc8259

JSON Schema Validation: A Vocabulary for Structural Validation of JSON. https://json-schema.org/draft/2020-12/json-schema-validation.html

4. Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

4.1. Terms and definitions

4.1.1. process

A process p is a function that for each input returns a corresponding output

$p : X \to Y$

where $X$ denotes the domain of arguments $x$ and $Y$ denotes the co-domain of values y. Within this specification, process arguments are referred to as process inputs and result values are referred to as process outputs. Processes that have no process inputs represent value generators that deliver constant or random process outputs.

The term process is one of the most used terms both in the information and geosciences domain. If not stated otherwise, this specification 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 WPS 2.0 standard.

4.1.2. 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.

4.1.3. JSON

JavaScript Object Notation is a lightweight data-interchange format. JSON is easy for humans to read and write and it is easy for machines to parse and generate.

4.1.4. 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 link.yaml. This is a JSON element containing properties like “rel” (relation) and “href”. The value of the “href” property is an URI.

4.1.5. Link header

HTTP Link header, as defined in RFC 8288 (Web Linking).

4.1.6. process description

A process description is an information model that specifies the interface of a process. A process description is used for a machine-readable description of the process itself but also provides some basic information about the process inputs and outputs.

4.1.7. 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.

4.1.8. 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.

4.1.9. 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).

4.1.10. 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.

4.1.11. 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: OGC 18-088)

4.2. Abbreviated terms

API: Application Programming Interface
CITE: Compliance Interoperability & Testing Evaluation
CRS: Coordinate Reference System
GML: Geography Markup Language
HTTP: Hypertext Transfer Protocol
ISO: International Organization for Standardization
JSON: JavaScript Object Notation
KVP: Key-Value Pair
MIME: Multipurpose Internet Mail Extensions
OGC: Open Geospatial Consortium
REST: Representational State Transfer
URI: Uniform Resource Identifier
URL: Uniform Resource Locator
WPS: Web Processing Service
XML: Extensible Markup Language

5. Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1. Identifiers

The normative provisions in this specification are denoted by the URI

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.

5.2. Link relations

To express relationships between resources, RFC 8288 (Web Linking) is used.

The following registered link relation types are used in this document.

alternate: Refers to a substitute for the link’s context.
license: Refers to a license associated with the link’s context.
service-desc: Identifies service description for the context that is primarily intended for consumption by machines.
- API definitions are considered service descriptions.
service-doc: Identifies service documentation for the context that is primarily intended for human consumption.
self: Conveys an identifier for the link’s context.
status: Identifies a resource that represents the context’s status.
up: Refers to a parent document in a hierarchy of documents.

In addition the following link relation types are used for which no applicable registered link relation type could be identified.

http://www.opengis.net/def/rel/ogc/1.0/conformance: Refers to a resource that identifies the specifications that the link’s context conforms to.
http://www.opengis.net/def/rel/ogc/1.0/exceptions: The target URI points to exceptions of a failed process.
http://www.opengis.net/def/rel/ogc/1.0/execute: The target URI points to the execution endpoint of the server.
http://www.opengis.net/def/rel/ogc/1.0/job-list: The target URI points to the list of jobs.
http://www.opengis.net/def/rel/ogc/1.0/processes: The target URI points to the list of processes the API offers.
http://www.opengis.net/def/rel/ogc/1.0/results: The target URI points to the results of a job.

Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by the API.

5.3. Use of HTTPS

For simplicity, this document 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 HTTPS, not HTTP.

OGC Web API standards do not prohibit the use of any valid HTTP option. However, implementers should be aware that optional capabilities which are not in common use could be an impediment to interoperability.

5.4. HTTP URIs

This document does not restrict the lexical space of URIs used in the API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of RFC 3986 (URI Syntax) for details.

6. Overview

The OGC API — Processes Standard builds on the WPS 2.0 Standard and is modularized. This means that there is a separation between

Core requirements, that specify basic capabilities and can easily be mapped to existing OGC Web Processing Services;
More advanced functionality, that is not specified in WPS 2.0.

6.1. Encodings

JSON is the encoding for requests and responses. The inputs and outputs of a process can be any format. The formats are defined at the time of job creation and are fixed for the specific job.

Support for HTML is recommended as HTML is the core language of the World Wide Web. A server that supports HTML will support browsing with a web browser and will enable search engines to crawl and index the processes.

7. Requirements Class “Core”

The following section describes the core requirements class.

7.1. Overview

Requirements class 1
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core
Obligation	requirement
Target type	Web API
Dependency	API — Common Core
Dependency	RFC 2616 (HTTP/1.1)
Dependency	RFC 2818 (HTTP over TLS)
Dependency	RFC 8288 (Web Linking)

A server that implements the OGC API — Processes Standard provides access to processes.

Each implementation of the OGC API — Processes Standard has a single LandingPage (path /) that provides links to

The APIDefinition (no fixed path),
The Conformance statements (path /conformance),
The processes metadata (path /processes).

Note that additional requirements classes may introduce additional links for 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 API.

Accessing Conformance using HTTP GET returns a list of URIs of requirements 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.

The process description contains information about inputs and outputs and a link to the execution-endpoint for the process.

A HTTP POST request to the execution-endpoint creates a new job. The inputs and outputs need to be passed in a JSON execute-request.

The URL for accessing status information is delivered in the HTTP header location.

After a process is finished (status = success/failed), the results/exceptions can be retrieved.

Figure 1 — Resources in the Core requirements class

The OGC API — Processes Standard utilizes elements of <draft> the OGC API-Common standard. Table 9 Identifies the API-Common Requirements Classes which are applicable to each section of this standard.

Table 9 — Mapping API — Processes Sections to API-Common Requirements Classes

API — Processes Section	API-Common Requirements Class
API Landing Page	http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core
API Definition	http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core
Declaration of Conformance Classes	http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core
OpenAPI 3.0	http://www.opengis.net/spec/ogcapi-common-1/1.0/req/oas30
HTML	http://www.opengis.net/spec/ogcapi-common-1/1.0/req/html

7.2. Retrieve the API landing page

The following section defines the requirements to retrieve an API landing page.

7.2.1. Operation

Requirement 1
/req/core/landingpage-op
The server SHALL support the HTTP GET operation at the path `/`.

7.2.2. Response

Requirement 2
/req/core/landingpage-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code `200`. The content of that response SHALL be based upon the OpenAPI 3.0 schema landingPage.yaml and include at least links to the following resources: the API definition (relation type ‘service-desc’ or ‘service-doc’) `/conformance` (relation type ‘http://www.opengis.net/def/rel/ogc/1.0/conformance’) `/processes` (relation type ‘http://www.opengis.net/def/rel/ogc/1.0/processes’)

Requirement 2

/req/core/landingpage-success

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

The content of that response SHALL be based upon the OpenAPI 3.0 schema landingPage.yaml and include at least links to the following resources:

the API definition (relation type ‘service-desc’ or ‘service-doc’)
/conformance (relation type ‘http://www.opengis.net/def/rel/ogc/1.0/conformance’)
/processes (relation type ‘http://www.opengis.net/def/rel/ogc/1.0/processes’)

NOTE 1 The term “…based upon the OpenAPI 3.0 schema…” used in the requirements of this specification means that OpenAPI 3.0 is used to define:

all the required properties of the respective request/response schema,
and any optional properties of the respective request/response schema.

It also means that unless explicitly excluded these schemas are extensible with additional properties not defined in the schema using the additionalProperties mechanism defined in the OpenAPI 3.0 specification.

type: object
required:
  - links
properties:
  title:
    type: string
    example: Example processing server
  description:
    type: string
    example: Example server implementing the OGC API - Processes 1.0 Standard
  links:
    type: array
    items:
      $ref: "link.yaml"

Figure 2 — Schema for the landing page

NOTE 2 This schema can also be obtained from landingPage.yaml.

type: object
required:
  - href
properties:
  href:
    type: string
  rel:
    type: string
    example: service
  type:
    type: string
    example: application/json
  hreflang:
    type: string
    example: en
  title:
    type: string

Figure 3 — Schema for a link

NOTE 3 This schema can also be obtained from link.yaml.

Example — Landing page response document

{
	"links": [{
		"href": "http://processing.example.org/oapi-p?f=application/json",
		"rel": "self",
		"type": "application/json",
		"title": "This document"
	},{
		"href": "http://processing.example.org/oapi-p?f=text/html",
		"rel": "alternate",
		"type": "text/html",
		"title": "This document as HTML"
	},
	{
		"href": "http://processing.example.org/oapi-p/api?f=application/json",
		"rel": "service-desc",
		"type": "application/json",
		"title": "API definition for this endpoint as JSON"
	},
	{
		"href": "http://processing.example.org/oapi-p/api?f=text/html",
		"rel": "service-desc",
		"type": "text/html",
		"title": "API definition for this endpoint as HTML"
	},
	{
		"href": "http://processing.example.org/oapi-p/conformance",
		"rel": "http://www.opengis.net/def/rel/ogc/1.0/conformance",
		"type": "application/json",
		"title": "OGC API - Processes conformance classes implemented by this server"
	},
	{
		"href": "http://processing.example.org/oapi-p/processes",
		"rel": "http://www.opengis.net/def/rel/ogc/1.0/processes",
		"type": "application/json",
		"title": "Metadata about the processes"
	},
	{
		"href": "http://processing.example.org/oapi-p/jobs",
		"rel": "http://www.opengis.net/def/rel/ogc/1.0/job-list",
		"title": "The endpoint for job monitoring"
	}]
}

7.2.3. Error situations

See Clause 7.5.1 for general guidance.

7.3. Retrieve an API definition

The following section defines the requirements to retrieve an API definition.

7.3.1. Operation

Every implementation of OGC API — Processes provides an API definition that describes the capabilities of the server. This definition is used by developers to understand the API, by software clients to connect to the server, or by development tools to support the implementation of servers and clients.

Requirement 3
/req/core/api-definition-op The URIs of all API definitions referenced from the landing page SHALL support the HTTP GET method.

Permission 1
/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.

Note that multiple API definition formats can be supported.

7.3.2. Response

Requirement 4
/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`.
The server SHALL return an API definition document.

Recommendation 2
/rec/core/api-definition-oas
If the API definition document uses the OpenAPI Specification 3.0, the document SHOULD conform to the OpenAPI Specification 3.0 requirements class.

If multiple API definition formats are supported by a server, use content negotiation to select the desired representation.

NOTE Two common approaches are:

an additional path for each encoding of each resource (this can be expressed, for example, using format specific suffixes like “.html”);
an additional query parameter (for example, “accept” or “f”) that overrides 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 developer may need to learn a little bit about geospatial data types, etc., but it should not be required to read this standard to access the processes and results via the API.

7.3.3. Error situations

See Clause 7.5.1 for general guidance.

7.4. Declaration of conformance classes

7.4.1. Operation

To support “generic” clients for accessing servers implementing OGC API — Processes in general — and not “just” a specific API / server, the server has to declare the requirements classes it implements and conforms to.

Requirement 5
/req/core/conformance-op
The server SHALL support the HTTP GET operation at the path `/conformance`.

7.4.2. Response

Requirement 6
/req/core/conformance-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code `200`. The content of that response SHALL be based upon the OpenAPI 3.0 schema confClasses.yaml and list all OGC API — Processes conformance classes that the server conforms to.

Requirement 6

/req/core/conformance-success

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

The content of that response SHALL be based upon the OpenAPI 3.0 schema confClasses.yaml and list all OGC API — Processes conformance classes that the server conforms to.

type: object
required:
  - conformsTo
properties:
  conformsTo:
    type: array
    items:
      type: string
      example: "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core"

Figure 4 — Schema for the list of conformance classes

NOTE This schema can also be obtained from confClasses.yaml.

Example — Requirements class response document

This example response in JSON is for a server that supports OpenAPI 3.0 for the API definition and HTML and JSON as encodings.

{
	"conformsTo": [
		"http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core",
		"http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/json",
		"http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/html",
		"http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/oas30"
	]
}

7.4.3. Error situations

See Clause 7.5.1 for general guidance.

7.5. Use of HTTP 1.1

Requirement 7
/req/core/http
The server SHALL conform to HTTP 1.1. If the server supports HTTPS, the server SHALL also conform to HTTP over TLS.

7.5.1. HTTP status codes

Table 10 lists the main HTTP status codes that clients should be prepared to receive.

This includes, for example, support for specific security schemes or URI redirection.

In addition, other error situations may occur in the transport layer outside of the server.

Table 10 — Typical HTTP status codes

Status code	Description
`200`	A successful request.
`201`	The request was successful and one or more new resources have being created.
`204`	The request was successful but did not generate any content.
`400`	The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
`401`	The request requires user authentication. The response includes a `WWW-Authenticate` header field containing a challenge applicable to the requested resource.
`403`	The server understood the request, but is refusing to fulfill it. While status code `401` indicates missing or bad authentication, status code `403` indicates that authentication is not the issue, but the client is not authorized to perform the requested operation on the resource.
`404`	The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
`405`	The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
`406`	The `Accept` header submitted in the request did not support any of the media types supported by the server for the requested resource.
`410`	The target resource is no longer available at the origin server.
`429`	The user has sent too many requests in a given amount of time (“rate limiting”).
`500`	An internal error occurred in the server.
`501`	The server does not support the functionality required to fulfill the request.

More specific guidance is provided for each resource, where applicable.

Permission 2
/per/core/additional-status-codes
Servers MAY support other capabilities of the HTTP protocol and, therefore, MAY return other status codes than those listed in Table 10, too.

When a server encounters an error in the processing of a request, it may wish to include information in addition to the status code in the response. Since Web API interactions are often machine-to-machine, a machine-readable report would be preferred. RFC 7807 addresses this need by providing “Problem Details” response schemas for both JSON and XML.

Recommendation 3
/rec/core/problem-details
A server SHOULD include a “Problem Details” report in an error response in accordance with RFC 7807.

7.6. Support for cross-origin requests

Access to content from a HTML page is by default prohibited for security reasons if the content is located on another host than the webpage (“same-origin policy”). Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. A typical example is a web-application accessing processes and data from multiple servers.

Recommendation 4
/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.

Two common mechanisms to support cross-origin requests are:

Recommendation 5
/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.

Recommendation 6
/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.

7.7. Limit parameter

Several resources defined in this specification (see Retrieve a process list, Retrieve a job list) use the limit parameter to control the number of results that are presented in a response.

The client can request a limit it is interested in.
The server likely has a default value for the limit, and a maximum limit.
If the server has any more results available than it returns (the number it returns is less than or equal to the requested/default/maximum limit) then the server will include a link to the next set of results.

So (using the default/maximum values of 10/1000 from the OpenAPI fragment in requirement /req/core/pl-limit-definition or /req/job-list/limit-definition):

If you ask for 10 results, you will get 0 to 10 (as requested) and if there are more, a next link;
If you don’t specify a limit, you will get 0 to 10 (default) and if there are more, a next link;
If you ask for 5000 results, you might get up to 1000 (server-limited) and if there are more, a next link;
If you follow the next link from the previous response, you might get up to 1000 additional results and if there are more, a next link.

This document make requirements and recommendations about links in general and the next link in particular at the appropriate resource end points.

This document does not mandate any specific implementation approach for the next links.

An implementation could use opaque links that are managed by the server. It is up to the server to determine how long these links can be dereferenced. Clients should be prepared to receive a 404 response.

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 WFS 2.0.

The API will return no next link, if it has returned all selected results, and the server knows that. However, 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 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 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 dataset 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.

This document also makes recommendations about include a prev link at the appropriate resource end points. Providing prev links supports navigating back and forth between pages, but depending on the implementation approach it may be too complex to implement.

7.8. Link headers

Recommendation 7
/rec/core/link-header
A	Links included in payload of responses SHOULD also be included as `Link` headers in the HTTP response according to RFC 8288, Clause 3. This recommendation does not apply, if there are a large number of links included in a response or a link is not known when the HTTP headers of the response are created.

Recommendation 7

/rec/core/link-header

Links included in payload of responses SHOULD also be included as Link headers in the HTTP response according to RFC 8288, Clause 3.

This recommendation does not apply, if there are a large number of links included in a response or a link is not known when the HTTP headers of the response are created.

7.9. Retrieve a process list

The following section defines the requirements to retrieve the available processes offered by the server.

7.9.1. Operation

7.9.1.1. Process list

Requirement 8
/req/core/process-list
The server SHALL support the HTTP GET operation at the path `/processes`.

7.9.1.2. Parameter `limit`

Requirement 9
/req/core/pl-limit-definition
A	The operation SHALL support a parameter `limit` with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: limit in: query required: false schema: type: integer minimum: 1 maximum: 10000 default: 10 style: form explode: false

Requirement 9

/req/core/pl-limit-definition

The operation SHALL support a parameter limit with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: limit
in: query
required: false
schema:
  type: integer
  minimum: 1
  maximum: 10000
  default: 10
style: form
explode: false

Permission 3
/per/core/limit-default-minimum-maximum
A	The values for `minimum`, `maximum` and `default` in requirement `/req/core/limit-definition` are only examples and MAY be changed.

Requirement 10
/req/core/pl-limit-response
A	The response SHALL not contain more process summaries than specified by the optional `limit` parameter.
B	If the API definition specifies a maximum value for `limit` parameter, the response SHALL not contain more process summaries than this maximum value.

Permission 4
/per/core/limit-response
A	The server MAY return fewer process summaries than requested (but not more).

7.9.2. Response

Requirement 11
/req/core/process-list-success
A successful execution of the process operation SHALL be reported as a response with a HTTP status code 200. The content of that response SHALL be based upon the OpenAPI 3.0 schema processList.yaml.

type: object
required:
  - processes
  - links
properties:
  processes:
    type: array
    items:
      $ref: "processSummary.yaml"
  links:
    type: array
    items:
      $ref: "link.yaml"

Figure 5 — Schema for the process list

NOTE 1 This schema can also be obtained from processList.yaml.

allOf:
  - $ref: "descriptionType.yaml"
  - type: object
    required:
      - id
      - version
    properties:
      id:
        type: string
      version:
        type: string
      jobControlOptions:
        type: array
        items:
          $ref: "jobControlOptions.yaml"
      outputTransmission:
        type: array
        items:
          $ref: "transmissionMode.yaml"
      links:
        type: array
        items:
          $ref: "link.yaml"

Figure 6 — Schema for a process summary

NOTE 2 This schema can also be obtained from processSummary.yaml.

(see also: descriptionType.yaml).

type: string
enum:
  - sync-execute
  - async-execute
  - dismiss

Figure 7 — Schema for the job control options

NOTE 3 This schema can also be obtained from jobControlOptions.yaml.

type: string
enum:
  - value
  - reference
default:
  - value

Figure 8 — Schema for the transmission mode

NOTE 4 This schema can also be obtained from transmissionMode.yaml.

The number of process summaries returned depends on the server and the parameter limit.

See the discussion about the limit parameter in the Limit parameter section.

Requirement 12
/req/core/pl-links
A	A `200`-response SHALL include the following links: a link to this response document (relation: `self`), a link to the response document in every other media type supported by the service (relation: `alternate`).

Requirement 12

/req/core/pl-links

A 200-response SHALL include the following links:

a link to this response document (relation: self),
a link to the response document in every other media type supported by the service (relation: alternate).

See the discussion about the next links in the Limit parameter section.

Recommendation 8
/rec/core/next-1
A	A `200`-response SHOULD include a link to the next page (relation: `next`) of process summaries, if more process summaries have been selected than returned in the response.

Recommendation 9
/rec/core/next-2
A	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.

Recommendation 10
/rec/core/next-3
A	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.

See the discussion about the prev link in the Limit parameter section.

Permission 5
/per/core/prev
A	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`).

Example 1 — A HTTP GET request for retrieving the list of offered processes encoded as JSON.

GET /processes HTTP/1.1
Host: processing.example.org

Example 2 — A Process list encoded as JSON.

{
  "processes": [
    {
	"id": "EchoProcess",
	"title": "EchoProcess",
	"version": "1.0.0",
      "jobControlOptions": [
        "async-execute",
        "sync-execute"
      ],
      "outputTransmission": [
        "value",
        "reference"
      ],
      "links": [
        {
          "href": "https://processing.example.org/oapi-p/processes/EchoProcess",
          "type": "application/json",
          "rel": "self",
          "title": "process description"
        }
      ]
    }
  ],
  "links": [
    {
      "href": "https://processing.example.org/oapi-p/processes?f=json",
      "rel": "self",
      "type": "application/json"
    },
    {
      "href": "https://processing.example.org/oapi-p/processes?f=html",
      "rel": "alternate",
      "type": "text/html"
    }
  ]
}

7.9.3. Error situations

See Clause 7.5.1 for general guidance.

7.10. Retrieve a process description

The following section defines the requirements to retrieve metadata about a process.

7.10.1. Operation

Requirement 13
/req/core/process
The server SHALL support the HTTP GET operation at the path `/processes/{processID}`.

7.10.2. Response

Requirement 14
/req/core/process-success
A	A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.
B	The content of the response SHALL be a process description.

The Core does not mandate the use of a specific process description to specify the interface of a process. That said, the Core requirements class makes the following recommendation:

Recommendation 11
/rec/core/ogc-process-description
Implementations SHOULD consider supporting the OGC process description.

7.10.3. Error situations

See Clause 7.5.1 for general guidance.

Requirement 15
/req/core/process-exception/no-such-process
If the operation is executed using an invalid process identifier, the response SHALL be HTTP status code 404. The content of that response SHALL be based upon the OpenAPI 3.0 schema exception.yaml. The `type` of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-process”.

7.11. Execute a process

This section describes the requirements for executing a process.

Depending on the description of the process and the negotiated process execution mode, process execution may result in the creation of a job resource.

7.11.1. Operation

Requirement 16
/req/core/process-execute-op
The server SHALL support the HTTP POST operation at the path `/processes/{processID}/execution`.

7.11.2. Request body

7.11.2.1. Content schema

Requirement 17
/req/core/process-execute-request
The content of a request the request body SHALL be based upon the OpenAPI 3.0 schema execute.yaml.

type: object
properties:
  inputs:
    additionalProperties:
      oneOf:
        - $ref: "inlineOrRefData.yaml"
        - type: array
          items:
            $ref: "inlineOrRefData.yaml"
  outputs:
    additionalProperties:
      $ref: "output.yaml"
  response:
    type: string
    enum:
      - raw
      - document
    default:
      - raw
  subscriber:
    $ref: "subscriber.yaml"

Figure 9 — Schema for execute

NOTE 1 This schema can also be obtained from execute.yaml.

oneOf:
  - $ref: "inputValueNoObject.yaml"
  - $ref: "qualifiedInputValue.yaml"
  - $ref: "link.yaml"

Figure 10 — Schema for an in-line or referenced process input value

NOTE 2 This schema can also be obtained from inlineOrRefData.yaml.

type: object
properties:
  format:
    $ref: "format.yaml"
  transmissionMode:
    $ref: "transmissionMode.yaml"

Figure 11 — Schema for a process output

NOTE 3 This schema can also be obtained from output.yaml.

(see also: format.yaml, transmissionMode.yaml)

7.11.2.2. Process inputs

Overview:

Each process input is a name/value pair that appears in the inputs section of an execute request.

The name of each input is its identifier as specified by the input’s definition in the process description.

Process input values in an execute request can be specified in-line or by reference.

Requirement 18
/req/core/process-execute-inputs
A	The server SHALL support process input values specified in-line in an execute request (i.e. by value).
B	The server SHALL support process input values specified by reference (i.e. using a link).

As shown in inlineOrRefData.yaml, a process input value that is specified in-line in an execute request can be:

a simple literal value,
an array,
a qualified value,
a binary value,
or a bounding box.

Simple literal values:

A simple literal value can be a string, number, integer or Boolean.

oneOf:
  - type: string
  - type: number
  - type: integer
  - type: boolean
  - type: array
  - $ref: "binaryInputValue.yaml"
  - $ref: "bbox.yaml"

Figure 12 — Schema for a simple literal value

NOTE 1 This schema can also be obtained from inputValueNoObject.yaml.

(see also: binaryInputValue.yaml, bbox.yaml)

Example 1 — Simple literal value examples.

A string literal:

"stringInput": "String value"

A date string:

"dateInput": "2021-05-24T20:40:13-05:00"

A number:

"numberInput": 3.14159

An integer:

"integerInput": 10

A Boolean:

"booleanInput": true

Array of values:

Array elements, as per inlineOrRefData.yaml, can be:

simple literals,
embedded arrays,
qualified values,
binary values,
bounding box values,
or references to values using links.

Requirement 19
/req/core/process-execute-input-array
Conditions	The process input is defined in the process description as having a maximum cardinality of greater than one (maxOccurs>1).
A	The server SHALL support process input values encoded as an array.
B	This SHALL be true even if the input consists of a single value.

Example 2 — Array value examples.

An array of simple values:

"arrayOfSimpleValues": [1, 2, 4, 10, 7]

An array with a single simple value:

"arrayOfSimpleValues": ["a"]

An array of arrays of simple values:

"arrayOfArrays": [[1,2,3,4], ["a","b","c","d"]]

An array of objects values:

"arrayOfQualifiedValues": [
  {
    "value": {
      "measurement": 10.3,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  {
    "value": {
      "measurement": 10.5,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  {
    "value": {
      "measurement": 10.9,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },...
],

NOTE 2 In an execute request, as per requirement /req/core/process-execute-input-inline-object, object values must be encoded as qualified values to prevent unintended ambiguity with the built-in value types (i.e. bounding boxes, links or qualified values).

Qualified values:

A qualified value is a value that can be optionally qualified with a format parameter.

Qualified values can be used to encode process input values that, according to their definition in the process description, can be of multiple media types. The format parameter is used to identify the specific media type being provided as the process input.

Qualified values can also be used to encode object-valued process inputs in order to avoid ambiguity with the built-in value schemas defined in this standard (i.e. bbox.yaml, link.yaml or qualifiedInputValue.yaml itself).

The actual value in a qualified value object is specified using the value key. The value of the value key is an instance of inputValue.yaml.

allOf:
  - $ref: "format.yaml"
  - type: object
    required:
      - value
    properties:
      value:
        $ref: "inputValue.yaml"

Figure 13 — Schema for a qualified value

NOTE 3 This schema can also be obtained from qualifiedInputValue.yaml.

type: object
properties:
  mediaType:
    type: string
  encoding:
    type: string
  schema:
    oneOf:
      - type: string
        format: url
      - type: object

Figure 14 — Schema for a format qualifier

NOTE 4 This schema can also be obtained from format.yaml.

oneOf:
  - $ref: "inputValueNoObject.yaml"
  - type: object

Figure 15 — Schema of a process input value

NOTE 5 This schema can also be obtained from inputValue.yaml.

(see also: inputValueNoObject.yaml)

Requirement 20
/req/core/process-execute-input-inline-object
Conditions	The process input value is specified in-line in an execute request. The process input is defined as an object according to its schema from the process description.
A	The server SHALL support process input values encoded as qualified values (qualifiedValue.yaml).
B	The value of the `value` key SHALL be an object instance of inputValue.yaml.

Requirement 21
/req/core/process-execute-input-mixed-type
Conditions	The process input value is specified in-line in an execute request. The schema of the process input from the process description indicates that a value instance can be one of multiple input media types. In JSON Schema this is denoted by the use of the `oneOf` construct.
A	The server SHALL support process input values encoded as qualified values (qualifiedValue.yaml).
B	The value of the `value` key SHALL be an instance of inputValue.yaml.
C	The `format` parameter of the qualified value (qualifiedValue.yaml) SHALL be used to indicate, for this value instance, the specific input type selected from the list of type choices defined by the input value’s schema from the process description.

Example 3 — Qualified value examples.

An example of a complex process input value.

"complexObjectInput": {
  "value": {
    "property1": "value1",
    "property2": "value2",
    "property3": "value3"
  }
}

In this second example, the property, geometryInput has a cardinality of greater than 1 and value instances can be one of a number of enumerated media types. The schema of geometryInput from the OGC process description for the process might be:

"geometryInput": {
  "title": "Geometry input",
  "description": "This is an example of a geometry input.  In this case the geometry can be expressed as a GML of GeoJSON geometry.",
  "minOccurs": 2,
  "maxOccurs": 5,
  "schema": {
    "oneOf": [
      {
        "type": "string",
        "contentMediaType": "application/gml+xml; version=3.2",
        "contentSchema": "http://schemas.opengis.net/gml/3.2.1/geometryBasic2d.xsd"
      },
      {
        "$ref": "http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.json"
      }
    ]
  }
},

and an instance of this process input in an execute request might be:

"geometryInputs": [
  {
    "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
    "mediaType": "application/gml+xml; version=3.2"
  },
  {
    "value": {
      "type": "Polygon",
      "coordinates": [[[ -176.5814819, -44.10896301 ],
                       [ -176.5818024, -44.10964584 ],
                       [ -176.5844116, -44.11236572 ],
                       [ -176.5935974, -44.11021805 ],
                       [ -176.5973511, -44.10743332 ],
                       [ -176.5950928, -44.10562134 ],
                       [ -176.5858459, -44.1043396  ],
                       [ -176.5811157, -44.10667801 ],
                       [ -176.5814819, -44.10896301 ]]]
    },
    "mediaType": "application/geo+json"
  }
]

In this case, the mediaType parameter is used to indicate the specific type of geometry being passed as input in each case; GML Polygon for the first element of the array and GeoJSON Polygon for the second element.

Binary values:

In some cases, for example in order to pass through firewalls, binary input values need to be encoded in-line in an execute request as a string.

type: string
format: byte

Figure 16 — Schema for an in-line binary value

NOTE 6 This schema can also be obtained from binaryInputValue.yaml.

Requirement 22
/req/core/process-execute-input-inline-binary
Conditions	The process input value is specified in-line in an execute request. The process input value is binary.
A	The service SHALL support binary values encoded as base64-encoded strings.

Example 4 — Binary value examples.

This is an example of an image process input whose media type is defined in the process description. The schema definition for this process input might be:

"schema": {
  "type": "string",
  "contentEncoding": "binary",
  "contentMediaType": "application/tiff; application=geotiff"
}

and an example instance value in an execute request might be:

"imageInput": "R0lGODdhNAHCAfcAAAcHDD+Gs4sLDQpDaqGFdaHE54dJPEoECUlGRteKgcdITgokG4hoVkpY\ngNzHwKKkqOLm7RRjlEgpHU9iZ44lHQYqVdmki6doVmhHOMOIeJG20HiDjCcKBglIeadISrso\nJGooFNbN2d2qr8aljyklHwQJQkdvkWaKxIdrb442LidLeGhMTp6LkeP1+Kh3aiUuVAoUHmlu\ngkcwNYdZRmkJDYGcsDFokElVYyk1NsWWhLEPDtmQldrUyoyFhrjo+Nna5d+4tMGstspoXgc4\n...qgu7sSu7qbtCs2u7t6u6rLsrp4u7veu76eO6vyu8w0u8xWu8x4u8yau8shu8y+u8zwu90Su9\n00u91Wu914u92au928u9whsQADs="

NOTE 7 Even though the schema indicates that the input type is binary, when the input value is encoded in-line in an execute request, as per requirement /req/core/process-execute-input-inline-binary, the binary value is encoded as base64-encoded string.

In this second example, the image input can be one of a number of value types denoted in JSON Schema by the use of the oneOf[] construct. An example schema for this a process input might be:

"schema": {
  "oneOf": [
    {
      "type": "string",
      "contentEncoding": "binary",
      "contentMediaType": "application/tiff; application=geotiff"
    },
    {
      "type": "string",
      "contentEncoding": "binary",
      "contentMediaType": "application/jp2"
    }
  ]
}

and a JPEG2000 instance example in an execute request might be:

{
  "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
  "mediaType": "application/jp2"
}

Bounding box values:

A process input value instance can be a bounding box.

type: object
required:
  - bbox
properties:
  bbox:
    type: array
    oneOf:
      - minItems: 4
        maxItems: 4
      - minItems: 6
        maxItems: 6
    items:
      type: number
  crs:
    type: string
    format: uri
    default: "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    enum:
      - "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      - "http://www.opengis.net/def/crs/OGC/0/CRS84h"

Figure 17 — Schema for a bounding box value

NOTE 8 This schema can also be obtained from bbox.yaml.

This schema is meant to be a template for defining bounding box process inputs. If the specified default and enum are suitable for your purposes then you can reference this file directly in your process description.

Input validation

Process inputs in an execute request and the corresponding process input definition in the process description have a validation relationship. That is to say, that the schema of a process input definition from the process description can be used to validate the component of the corresponding process input value in an execute request that is an instance of inputValue.yaml.

Consider a process input named complexObjectInput with the following definition from an OGC process description:

"complexObjectInput": {
  "title": "Complex Object Input Example",
  "description": "This is an example of a complex object input.",
  "schema": {
    "type": "object",
    "required": [
      "property1",
      "property5"
    ],
    "properties": {
      "property1": {
        "type": "string"
      },
      "property2": {
        "type": "string",
        "format": "uri"
      },
      "property3": {
        "type": "number"
      },
      "property4": {
        "type": "string",
        "format": "dateTime"
      },
      "property5": {
        "type": "boolean"
      }
    }
  }
}

and the following instance in an execute request:

"inputs": [
  .
  .
  .
  "complexObjectInput": {
    "value": {
      "property1": "value1",
      "property2": "value2",
      "property3": "value5"
    }
  },
  .
  .
  .
]

The process input value in this execute request is an instance of a qualified value.

For the purposes of validation, the server need only validate the component of the qualified value that is an instance of inputValue.yaml against the schema fragment from the OGC process description. Specifically, the validation target is:

{
  "property1": "value1",
  "property2": "value2",
  "property3": "value5"
}

NOTE 9 This example makes use of an OGC process description. However, any other process description vocabulary may be used and applied, for the purpose of validation, in a similar manner.

Requirement 24
/req/core/process-execute-input-validation
A	For process input values specified in-line in an execute request, the server SHALL validate each component of a process input value that is an instance of inputValue.yaml using the definition of the corresponding input from the process description.
B	For process input values specified by reference in an execute request, the server SHALL resolve the value and then validate it as if the value had been specified in-line in the execute request (i.e. as per requirement A).

7.11.2.3. Execution mode

A process may be executed synchronously or asynchronously.

In which of these two modes a server responds is a function of the job control options specified in the process description and the presence or absence of the HTTP Prefer header (IETF RFC 7240).

Requirement 25
/req/core/process-execute-default-execution-mode
Conditions	The execute request is not accompanied with the HTTP `Prefer` header.
A	The server SHALL respond asynchronously if, according to the job control options in the process description, the process can only be executed asynchronously.
B	The server SHALL respond synchronously if, according to the job control options in the process description, the process can only be executed synchronously.
C	The server SHALL respond synchronously if, according to the job control options in the process description, the process can be executed in either mode.

Requirement 26
/req/core/process-execute-auto-execution-mode
Conditions	The execute request is accompanied with the HTTP `Prefer` header asserting a `respond-async` preference.
A	The server SHALL respond asynchronously if, according to the job control options in the process description, the process can only be executed asynchronously.
B	The server SHALL respond synchronously if, according to the job control options in the process description, the process can only be executed synchronously.
C	The server SHALL respond, at its discretion, either synchronously or asynchronously if, according to the job control options in the process description, the process can be executed in either mode.

Recommendation 12
/rec/core/process-execute-honor-prefer
A	If an execute request is accompanied with the HTTP `Prefer` header asserting a `respond-async` preference, then the server SHOULD honor that preference and response asynchronously if, according to the job control options in the process description, the process can be executed asynchronously.
B	If an execute request is accompanied with the HTTP `Prefer` header asserting a `wait` preference, then the server SHOULD honor that preference in the decision to execute the process asynchronously if, according to the job control options in the process description, the process can be executed asynchronously.

Recommendation 13
/rec/core/process-execute-handle-prefer
A client that accompanies an execute request with the HTTP `Prefer` header asserting a `respond-async` preference and/or a `wait` preference SHOULD be prepared to receive either an asynchronous or a synchronous response.

Recommendation 14
/rec/core/process-execute-preference-applied
If an execute request is accompanied with the HTTP `Prefer` header then, in the response, servers SHOULD include the HTTP `Preference-Applied` response header as an indication as to which ‘Prefer` tokens were honoured by the server.

7.11.2.4. Response type

The response parameter selects the form used to present processing results.

A response value of document indicates that the server should generate a response document (see results.yaml) that contains each of the requested process outputs.
A response value of raw indicates that the server should present the process responses in their native form without the use of a containing document.

The default value, if the parameter is not specified is raw.

7.11.2.5. Process outputs

Overview:

Each process output is a named object that appears in the outputs section of an execute request. The name of each output is its identifier as specified by the output’s definition in the process description.

Default outputs

Requirement 27
/req/core/process-execute-default-outputs
If a process is defined as having one or more outputs and the `outputs` parameter is omitted in an execute request, this SHALL be equivalent to having requested all the defined outputs in the execute request.

Output value transmission mode

Like inputs, output values can be transmitted in-line in a result document or referenced using a link. The transmissionMode parameter in the execute request controls how the server responds.

type: string
enum:
  - value
  - reference
default:
  - value

Figure 18 — Schema for the transmission mode

NOTE This schema can also be obtained from transmissionMode.yaml.

Output value format

A process output can be defined in the process description as being of one or more media types. In cases where a specific output can be presented in one of a number of media types, the format parameter in the execute request can be used to indicate the format that should be used to present the process output value in the server’s response.

7.11.3. Example

Example — An execute request.

{
  "inputs": {
    "stringInput": "Value2",
    "measureInput": {
      "value": {
        "measurement": 10.3,
        "uom": "m",
        "reference": "https://ucum.org/ucum-essence.xml"
      }
    },
    "dateInput": "2021-03-06T07:21:00",
    "doubleInput": 3.14159,
    "arrayInput": [1,2,3,4,5,6],
    "complexObjectInput": {
      "value": {
        "property1": "value1",
        "property2": "value2",
        "property5": true
      }
    },
    "geometryInput": [
      {
        "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
        "mediaType": "application/gml+xml; version=3.2"
      },
      {
        "value": {
          "type": "Polygon",
          "coordinates": [[[ -176.5814819, -44.10896301 ],
                           [ -176.5818024, -44.10964584 ],
                           [ -176.5844116, -44.11236572 ],
                           [ -176.5935974, -44.11021805 ],
                           [ -176.5973511, -44.10743332 ],
                           [ -176.5950928, -44.10562134 ],
                           [ -176.5858459, -44.1043396  ],
                           [ -176.5811157, -44.10667801 ],
                           [ -176.5814819, -44.10896301 ]]]
        }
      }
    ],
    "boundingBoxInput": {
      "bbox": [ 51.9, 7, 52, 7.1 ],
      "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "imagesInput": [
      {
        "href": "https://www.someserver.com/ogcapi/Daraa/collections/Daraa_DTED/styles/Topographic/coverage?...",
        "type": "application/tiff; application=geotiff"
      },
      {
         "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
         "encoding": "base64",
         "mediaType": "application/jp2"
      }
    ],
    "featureCollectionInput": {
      "value": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><FeatureCollection xmlns=\"http://schemas.myserver.com/namespaces/null\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://schemas.myserver.com/namespaces/null https://www.pvretano.com/myserver/ogcapi/daraa/schema?f=GML32&amp;collectionids=TransportationGroundCrv http://www.opengis.net/gml/3.2 http://schemas.opengis.net/schemas/gml/3.2.1/gml.xsd\">...",
      "mediaType": "application/gml+xml; version=3.2"
    }
  },
  "outputs": {
    "stringOutput": {
      "transmissionMode": "value"
    },
    "measureOutput": {
      "transmissionMode": "value"
    },
    "dateOutput": {
      "transmissionMode": "value"
    },
    "doubleOutput": {
      "transmissionMode": "value"
    },
    "arrayOutput": {
      "transmissionMode": "value"
    },
    "complexObjectOutput": {
      "transmissionMode": "value"
    },
    "geometryOutput": {
      "transmissionMode": "value"
    },
    "boundingBoxOutput": {
      "transmissionMode": "value"
    },
    "imageOutput": {
      "format": { "mediaType": "application/tiff; application=geotiff" },
      "transmissionMode": "value"
    },
    "featureCollectionOutput": {
      "transmissionMode": "value"
    }
  },
  "response": "document"
}

7.11.4. Response

The manner in which a server responds to a process execution request is determined by the following parameters:

the negotiated execution mode (synchronous or asynchronous),
the response parameter (document or raw),
the transmissionMode parameter (value or reference)
and the number of outputs requested.

The following table maps the possible responses based on the combinations of these execute parameters.

Table 11 — Table mapping execute responses based on the input parameter values.

negotiated execution mode	response	transmission mode	# out	HTTP code	media type	body content	requirement
sync	raw	value	1	200	[as per output definition from process description]	[output in requested format]	/req/core/process-execute-sync-raw-value-one
		value	*	200	multipart/related	[one output per part]	/req/core/process-execute-sync-raw-value-multi
		reference	1	204	none	[empty with `Link` headers]	/req/core/process-execute-sync-raw-ref
		reference	*	204	none	[empty with `Link` headers]	/req/core/process-execute-sync-raw-ref
		mixed	*	200	multipart/related	[one output per part]	/req/core/process-execute-sync-raw-mixed-multi
	document	value	1	200	application/json	results.yaml	/req/core/process-execute-sync-document
		value	*
		reference	1
		reference	*
async	any	any	any	201	application/json	statusInfo.yaml	/req/core/process-execute-success-async
NOTE The value any in a cell means “for any valid value of the execute parameter represented by that cell”. This table shows all possible combinations of execute parameters that are specified by this standard. Not all of these combinations need to be implemented by a server conforming to this standard. For example, if a server only offers processes that support multiple outputs by value, then the server must support `multipart/related` responses as indicated in Table 11. If, on the other hand, the server only offers processes that support multiple outputs by reference, then the server does not need to support `multipart/related` responses.

additionalProperties:
  $ref: "inlineOrRefData.yaml"

Figure 19 — Schema for a processing results presented as a document

NOTE 1 This schema can also be obtained from results.yaml.

This schema defines a map using the respective output identifier as the key. The value of an output can be returned as an in-line value or by reference.

For a synchronous execution, the following requirements apply:

Requirement 28
/req/core/process-execute-sync-raw-value-one
Conditions	The negotiated execution mode is synchronous, `response=raw`, `transmissionMode=value` The number of requested outputs is 1.
A	The server SHALL respond with an HTTP status code of 200.
B	The media type of the response SHALL be as specified by the output definition from the process description.
C	The content of response SHALL be the requested process output in the requested output format.

Requirement 29
/req/core/process-execute-sync-raw-value-multi
Conditions	The negotiated execution mode is synchronous, `response=raw`, `transmissionMode=value` The number of requested outputs is greater than 1.
A	The server SHALL respond with an HTTP status code of 200.
B	The media type of the response SHALL be `multipart/related`.
C	The content of response shall conform to RFC 2387, The MIME Multipart/Related Content-type.
D	Each requested output shall be encoded into one part of the response.
E	The `Content-ID` header for each part SHALL be the corresponding output identifier.

Requirement 30
/req/core/process-execute-sync-raw-ref
Conditions	The negotiated execution mode is synchronous, `response=raw`, `transmissionMode=reference` The number of requested outputs is 1 or more.
A	The server SHALL respond with an HTTP status code of 204.
B	The response SHALL include one or more `Link` headers that reference each requested output.

Requirement 31
/req/core/process-execute-sync-raw-mixed-multi
Conditions	The negotiated execution mode is synchronous, `response=raw`, Multiple transmission modes (`value`,`reference`) are requested. The number of requested outputs is more than 1.
A	The server SHALL respond with an HTTP status code of 200.
B	The media type of the response SHALL be `multipart/related`.
C	The content of response shall conform to RFC 2387, The MIME Multipart/Related Content-type.
D	Each requested output shall be encoded into one part of the response.
E	The `Content-ID` header for each part SHALL be the corresponding output identifier.
F	For outputs requested by reference, the `Content-Location` header SHALL be included pointing to the output and the body of the part SHALL be empty.
G	For outputs requested by value, the body of the response SHALL contain the output value.

Requirement 32
/req/core/process-execute-sync-document
Conditions	The negotiated execution mode is synchronous, `response=document`, `transmissionMode=value` or `transmissionMode=reference` The number of requested outputs is 1 or more.
A	The server SHALL respond with an HTTP status code of 200.
B	The media type of the response SHALL be `application/json`
C	The content of response SHALL conform to the results.yaml schema.

Recommendation 15
/rec/core/process-execute-sync-document-ref
Conditions	The negotiated execution mode is synchronous, `response=document`, `transmissionMode=reference` The number of outputs requested is 1 or more. The requested output value is a simple scalar value.
A	For a simple scalar values servers SHOULD consider supporting links to `text/plain` files that contain the output values.

This specification does not mandate that servers create a job as a result of executing a process synchronously. However the following permission is given:

For servers that implement this permission and do create a job as a result of synchronous execution of a process, the following requirement applies:

Requirement 33
/req/core/job-results-success-sync
Conditions	The server creates a job when a processes is executed synchronously.
A	A successful execution of the operation SHALL include an HTTP `Link` header with `rel=monitor` pointing to the created job.

The job reference in the header can then be used to re-fetch the results of the original synchronous execution.

In the case of asynchronous execution, the following requirement applies:

Requirement 34
/req/core/process-execute-success-async
Conditions	The negotiated execution mode is asynchronous.
A	A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.
B	The header of the response SHALL return the HTTP `Location` header that contains a link to the newly created job.
C	The content of the response SHALL be based upon the JSON Schema fragment statusInfo.yaml.

7.11.5. Error situations

See Clause 7.5.1 for general guidance.

If the process with the specified identifier does not exist on the server, see requirement /req/core/process-exception/no-such-process.

7.12. Retrieve status information about a job

The following section describes the requirements to retrieve information about the status of a job.

7.12.1. Operation

7.12.2. Response

Requirement 36
/req/core/job-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. The content of that response SHALL be based upon the OpenAPI 3.0 schema statusInfo.yaml.

type: object
required:
   - jobID
   - status
   - type
properties:
   processID:
      type: string
   type:
      type: string
      enum:
        - process
   jobID:
      type: string
   status:
      $ref: "statusCode.yaml"
   message:
      type: string
   created:
      type: string
      format: date-time
   started:
      type: string
      format: date-time
   finished:
      type: string
      format: date-time
   updated:
      type: string
      format: date-time
   progress:
      type: integer
      minimum: 0
      maximum: 100
   links:
      type: array
      items:
         $ref: "link.yaml"

Figure 20 — Schema for status info

NOTE 1 This schema can also be obtained from statusInfo.yaml.

type: string
nullable: false
enum:
  - accepted
  - running
  - successful
  - failed
  - dismissed

Figure 21 — Schema for status codes

NOTE 2 This schema can also be obtained from statusCode.yaml.

The job status information includes several optional date-time fields that represent milestones in the life cycle of a job. The following are recommended for servers that decide to populate some or all of these date-time fields:

Recommendation 16
/rec/core/job-status
A	Servers SHOULD set the value of the `processID` field if it is known.
B	Servers SHOULD set the value of the `created` field when a job has been accepted and queued for execution.
C	Servers SHOULD set the value of the `started` field when a job begins execution and is consuming compute resources.
D	Servers SHOULD set the value of the `finished` field when the execution of a job has completed and the process is no longer consuming compute resources.
E	Whenever the `status` field of the job changes, servers SHOULD revise the value of the `updated` field.

NOTE 3 Once a job has finished execution and is no longer consuming compute resources, the duration of processing can be computed as finished-started. The updated field, however, may still be revised as the system continues processing outputs, storing results, releasing compute resources, etc.

Example 1 — A HTTP GET request for retrieving status information about a job encoded as JSON.

GET /jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f HTTP/1.1
Host: processing.example.org

Example 2 — A job encoded as JSON.

{
  "jobID" : "81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
  "status": "accepted",
  "message": "Process started",
  "progress": 0,
  "created": "2021-05-04T10:13:00+05:00",
  "links": [
    {
      "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
      "rel": "self",
      "type": "application/json",
      "title": "this document"
    }
  ]
}

7.12.3. Error situations

See Clause 7.5.1 for general guidance.

If the process with the specified identifier does not exist on the server, see requirement /req/core/process-exception/no-such-process.

Requirement 37
/req/core/job-exception-no-such-job
If the operation is executed using an invalid job identifier, the response SHALL have HTTP status code 404. The content of that response SHALL be based upon the OpenAPI 3.0 schema exception.yaml. The `type` of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-job”.

7.13. Retrieve job results

The following section describes the requirements to retrieve the results of a job. In case the job execution failed, an exception is returned.

7.13.1. Operation

7.13.2. Response

The manner in which a server responds when retrieving job results depends on the values of the following parameters used in the execute request that created the job:

the negotiated execution mode (synchronous or asynchronous),
the response parameter (document or raw),
the transmissionMode parameter (value or reference)
and the number of output requested.

The following table maps the possible responses based on the combinations of these execute parameters.

Table 12 — Table mapping get results responses based on the input parameter values used on the original execute request.

negotiated execute mode	response	transmission mode	# out	Required	HTTP code	media type	body content	requirement
sync	any	any	any	no	[if the server creates a job on synchronous execute, job results may be re-fetched at any time as per async]
async	raw	value	1	yes	200	[as per output definition from process description]	[output in requested output format]	/req/core/process-execute-sync-raw-value-one
		value	*		200	multipart/related	[one output per part]	/req/core/process-execute-sync-raw-value-multi
		reference	1		204	none	[empty with `Link` headers]	/req/core/process-execute-sync-raw-ref
		reference	*		204	none	[empty with `Link` headers]	/req/core/process-execute-sync-raw-ref
		mixed	*		200	multipart/related	[one output per part]	/req/core/process-execute-sync-raw-mixed-multi
	document	value	1		200	application/json	results.yaml	/req/core/process-execute-sync-document
		value	*
		reference	1
NOTE The value any in a cell means “for any valid value of the execute parameter represented by that cell”.

The following requirements apply when retrieving the results of a job that was created by executing a process synchronously OR was created by execution a process synchronously on a server that creates a job even on synchronous execution:

Example 1 — A HTTP GET request for retrieving the result a job encoded as JSON.

GET /jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f/results HTTP/1.1
Host: processing.example.org

Example 2 — A result encoded as JSON.

{
  "stringOutput": "Value2",
  "measureOutput": {
    "value": {
      "measurement": "10.3",
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  "dateOutput": "2021-03-06T07:21:00",
  "doubleOutput": "3.14159",
  "arrayOutput": [1,2,3,4,5,6],
  "complexObjectOutput": {
    "value": {
      "property1": "value1",
      "property2": "value2",
      "property5": true
    }
  },
  "geometryOutput": [
    {
      "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
      "mediaType": "application/gml+xml; version=3.2"
    },
    {
      "value": {
        "type": "Polygon",
        "coordinates": [[[ -176.5814819,-44.10896301 ],
                         [ -176.5818024,-44.10964584 ],
                         [ -176.5844116,-44.11236572 ],
                         [ -176.5935974,-44.11021805 ],
                         [ -176.5973511,-44.10743332 ],
                         [ -176.5950928,-44.10562134 ],
                         [ -176.5858459,-44.1043396  ],
                         [ -176.5811157,-44.10667801 ],
                         [ -176.5814819,-44.10896301 ]]]
      }
    }
  ],
  "boundingBoxOutput": {
    "bbox": [51.9,7,52,7.1],
    "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
  },
  "imagesOutput": [
    {
      "href": "https://www.someserver.com/ogcapi/Daraa/collections/Daraa_DTED/styles/Topographic/coverage?...",
      "type": "application/tiff; application=geotiff"
    },
    {
      "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
      "encoding": "base64",
      "mediaType": "application/tiff; application=geotiff"
    }
  ],
  "featureCollectionOutput": {
    "value": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><FeatureCollection xmlns=\"http://schemas.myserver.com/namespaces/null\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://schemas.myserver.com/namespaces/null https://www.pvretano.com/myserver/ogcapi/daraa/schema?f=GML32&amp;collectionids=TransportationGroundCrv http://www.opengis.net/gml/3.2 http://schemas.opengis.net/schemas/gml/3.2.1/gml.xsd\">...",
    "mediaType": "application/gml+xml; version=3.2"
  }
}

7.13.3. Error situations

See Clause 7.5.1 for general guidance.

Requirement 44
/req/core/job-results-exception/no-such-job
If the operation is executed using an invalid job identifier, the response SHALL have HTTP status code 404. The content of that response SHALL be based upon the OpenAPI 3.0 schema exception.yaml. The `type` of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-job”.

Requirement 45
/req/core/job-results-exception/results-not-ready
If the operation is executed on a running job with a valid job identifier, the response SHALL have HTTP status code 404. The content of that response SHALL be based upon the OpenAPI 3.0 schema exception.yaml. The `type` of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/result-not-ready”.

Requirement 46
/req/core/job-results-failed
If the operation is executed on a failed job using a valid job identifier, the response SHALL have a HTTP error code that corresponds to the reason of the failure. The content of that response SHALL be based upon the OpenAPI 3.0 schema exception.yaml. The `type` of the exception SHALL correspond to the reason of the failure, e.g. InvalidParameterValue for invalid input data.

8. Requirements Class “OGC Process Description”

The following section describes the OGC Process Description requirements class.

8.1. Overview

Requirements class 2
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/ogc-process-description
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core
Dependency	JSON

The OGC process description is an information model that may be used to specify the interface of a process. This model is an evolution of the process description model originally defined in the OGC WPS 2.0.2 Interface Standard but also includes elements of the OpenAPI Specification. Specifically, this process description languages uses JSON Schema fragments to define the input and output parameters of a process. As such, this process description provides a bridge from legacy implementations to the OGC API Framework.

The process description allows the following information to be specified:

An identifier for the process
Descriptive metadata about the process;
- A title
- A narrative description of the process
- Keywords that can be associated with the process
- References to additional metadata
A description of each process input specified using a JSON Schema fragment.
A description of each process output specified using a JSON Schema fragment.
A job control specification that indicates whether the process can be invoked synchronously, asynchronously, or either.
An output transmission specification that indicates how the results of a process are retrieved; either by value or by reference
A section for additional parameters that are intended for communities of use to extend the process description as required

The following clause defines a JSON-encoding of the OGC process description.

8.2. OGC process description

allOf:
  - $ref: "processSummary.yaml"
  - type: object
    properties:
      inputs:
        additionalProperties:
          $ref: "inputDescription.yaml"
      outputs:
        additionalProperties:
          $ref: "outputDescription.yaml"

Figure 22 — Schema for a process

NOTE 1 This schema can also be obtained from process.yaml

(see also: processSummary.yaml)

The schema imports the elements from the process summary and specifies an object for the definition of process inputs and another object for the definition of process outputs.

Requirement 48
/req/ogc-process-description/inputs-def
A	Each process input definition SHALL be listed in the `inputs` section according to the JSON Schema: inputDescription.yaml.
B	The key of each process input in the `inputs` section of the process definition SHALL be the identifier for that input.

allOf:
  - $ref: "descriptionType.yaml"
  - type: object
    required:
      - schema
    properties:
      minOccurs:
        type: integer
        default: 1
      maxOccurs:
        oneOf:
          - type: integer
            default: 1
          - type: string
            enum:
              - "unbounded"
      schema:
        $ref: "schema.yaml"

Figure 23 — Schema for a process input

NOTE 2 This schema can also be obtained from inputDescription.yaml

(see also: descriptionType.yaml).

Requirement 49
/req/ogc-process-description/input-def
A	The schema of each process input value SHALL be specified using the `schema` parameter.
B	The value of the `schema` parameter SHALL be a JSON fragment that validates according to the JSON Schema: schema.yaml.
C	Servers SHALL use this schema fragment to validate the components of a process input in an execute request that is an instance of inputValue.yaml.

NOTE 3 The schema fragment specified as the value of the schema parameter can be used to validate the corresponding process input value in an execute request.

Requirement 51
/req/ogc-process-description/input-mixed-type
A	An input that can be of mixed type SHALL be defined using the `oneOf` JSON Schema keyword.
B	Each sub-schema SHALL be a JSON fragment that validates according to the JSON Schema: schema.yaml.
C	The first sub-schema in the `oneOf` array SHALL be considered the default format.

The following JSON Schema fragment illustrates how to define an input of mixed type. In this case, the imageInput input can be one of a couple of image media types.

"imageInput": {
  "schema": {
    "oneOf": [
      {
        "type": "string",
        "contentEncoding": "binary",
        "contentMediaType": "application/tiff; application=geotiff"
      },
      {
        "type": "string",
        "contentEncoding": "binary",
        "contentMediaType": "application/jp2"
      }
    ]
  }
}

Figure 24 — Mixed type input example

Recommendation 17
/rec/ogc-process-description/format-key
A	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 execute request.

The JSON Schema specification defines a set of values for the format key. This specification extends this list by defining the following additional key values for use specifically in OGC process descriptions.

Table 13 — Additional values for the JSON schema format key for OGC Process Description

Key value	Short code	Description
http://www.opengis.net/def/format/ogcapi-processes/0/geojson-feature-collection	geojson-feature-collection	Indicates that the object is an instance of a GeoJSON feature collection (featureCollectionGeoJSON.yaml).
http://www.opengis.net/def/format/ogcapi-processes/0/geojson-feature	geojson-feature	Indicates that the object is an instance of a GeoJSON feature (featureGeoJSON.yaml).
http://www.opengis.net/def/format/ogcapi-processes/0/geojson-geometry	geojson-geometry	Indicates that the object is an instance of a GeoJSON geometry (geometryGeoJSON.yaml).
http://www.opengis.net/def/format/ogcapi-processes/0/ogc-bbox	ogc-bbox	Indicates that the object is an instance of an OGC bounding box (bbox.yaml).
NOTE This list of values has been submitted to the OGC Naming Authority for registration in their definition server.

Situations might arise where communities of interest wish to extend this list of values for their own purposes.

The following JSON Schema fragment illustrates the use of the format key to include a semantic hint to a process input that is a geometry.

"geometryInput": {
  "title": "Geometry input",
  "description": "This is an example of a geometry input.  In this case the geometry can be expressed as a GML of GeoJSON geometry.",
  "minOccurs": 2,
  "maxOccurs": 5,
  "schema": {
    "oneOf": [
      {
        "type": "string",
        "contentMediaType": "application/gml+xml; version=3.2",
        "contentSchema": "http://schemas.opengis.net/gml/3.2.1/geometryBasic2d.xsd"
      },
      {
        "allOf": [
          {
            "format": "geojson-geometry"
          },
          {
            "$ref": "http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.yaml"
          }
        ]
      }
    ]
  }
}

Figure 25 — Example of semantic hints using the format key

allOf:
  - $ref: "descriptionType.yaml"
  - type: object
    required:
      - schema
    properties:
      schema:
        $ref: "schema.yaml"

Figure 26 — Schema for a process output

NOTE 4 This schema can also be obtained from outputDescription.yaml

(see also: descriptionType.yaml).

Requirement 52
/req/ogc-process-description/outputs-def
A	Each process output definition SHALL be listed in the `outputs` section according to the JSON Schema: outputDescription.yaml.
B	The key of each process input in the `output` section of the process definition SHALL be the identifier for that output.

Requirement 53
/req/ogc-process-description/output-def
A	The schema of each process output SHALL be specified using the `schema` parameter.
B	The value of the `schema` parameter SHALL be a JSON fragment that validates according to the JSON Schema: schema.yaml.

Requirement 54
/req/ogc-process-description/output-mixed-type
A	An output that can be of mixed type SHALL be defined using the `oneOf` JSON Schema keyword.
B	Each sub-schema SHALL be a JSON fragment that validates according to the JSON Schema: schema.yaml.
C	The first sub-schema in the `oneOf` array SHALL be considered the default format.

Example — Example OGC Process Description.

The following URL is an example of retrieving a process description from the /processes/{processID} endpoint.

https://processing.example.org/processes/EchoProcess

The description of the example EchoProcess process might be:

{
  "id": "EchoProcess",
  "title": "Echo Process",
  "description": "This process accepts and number of input and simple echoes each input as an output.",
  "version": "1.0.0",
  "jobControlOptions": [
    "async-execute",
    "sync-execute"
  ],
  "outputTransmission": [
    "value",
    "reference"
  ],
  "inputs": {
    "stringInput": {
      "title": "String Literal Input Example",
      "description": "This is an example of a STRING literal input.",
      "schema": {
        "type": "string",
        "enum": [
          "Value1",
          "Value2",
          "Value3"
        ]
      }
    },
    "measureInput": {
      "title": "Numerical Value with UOM Example",
      "description": "This is an example of a NUMERIC literal with an associated unit of measure.",
      "schema": {
        "type": "object",
        "required": [
          "value",
          "uom"
        ],
        "properties": {
          "measurement": {
            "type": "number"
          },
          "uom": {
            "type": "string"
          },
          "reference": {
            "type": "string",
            "format": "uri"
          }
        }
      }
    },
    "dateInput": {
      "title": "Date Literal Input Example",
      "description": "This is an example of a DATE literal input.",
      "schema": {
        "type": "string",
        "format": "dateTime"
      }
    },
    "doubleInput": {
      "title": "Bounded Double Literal Input Example",
      "description": "This is an example of a DOUBLE literal input that is bounded between a value greater than 0 and 10.  The default value is 5.",
      "schema": {
        "type": "number",
        "format": "double",
        "minimum": 0,
        "maximum": 10,
        "default": 5,
        "exclusiveMinimum": true
      }
    },
    "arrayInput": {
      "title": "Array Input Example",
      "description": "This is an example of a single process input that is an array of values.  In this case, the input array would be interpreted as a single value and not as individual inputs.",
      "schema": {
        "type": "array",
        "minItems": 2,
        "maxItems": 10,
        "items": {
          "type": "integer"
        }
      }
    },
    "complexObjectInput": {
      "title": "Complex Object Input Example",
      "description": "This is an example of a complex object input.",
      "schema": {
        "type": "object",
        "required": [
          "property1",
          "property5"
        ],
        "properties": {
          "property1": {
            "type": "string"
          },
          "property2": {
            "type": "string",
            "format": "uri"
          },
          "property3": {
            "type": "number"
          },
          "property4": {
            "type": "string",
            "format": "dateTime"
          },
          "property5": {
            "type": "boolean"
          }
        }
      }
    },
    "geometryInput": {
      "title": "Geometry input",
      "description": "This is an example of a geometry input.  In this case the geometry can be expressed as a GML of GeoJSON geometry.",
      "minOccurs": 2,
      "maxOccurs": 5,
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentMediaType": "application/gml+xml; version=3.2",
            "contentSchema": "http://schemas.opengis.net/gml/3.2.1/geometryBasic2d.xsd"
          },
          {
            "allOf": [
              {
                "format": "geojson-geometry"
              },
              {
                "$ref": "http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.yaml"
              }
            ]
          }
        ]
      }
    },
    "boundingBoxInput": {
      "title": "Bounding Box Input Example",
      "description": "This is an example of a BBOX literal input.",
      "schema": {
        "allOf": [
          {
            "format": "ogc-bbox"
          },
          {
            "$ref": "../../openapi/schemas/bbox.yaml"
          }
        ]
      }
    },
    "imagesInput": {
      "title": "Inline Images Value Input",
      "description": "This is an example of an image input.  In this case, the input is an array of up to 150 images that might, for example, be a set of tiles.  The oneOf[] conditional is used to indicate the acceptable image content types; GeoTIFF and JPEG 2000 in this case.  Each input image in the input array can be included inline in the execute request as a base64-encoded string or referenced using the link.yaml schema.  The use of a base64-encoded string is implied by the specification and does not need to be specified in the definition of the input.",
      "minOccurs": 1,
      "maxOccurs": 150,
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "application/tiff; application=geotiff"
          },
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "application/jp2"
          }
        ]
      }
    },
    "featureCollectionInput": {
      "title": "Feature Collection Input Example.",
      "description": "This is an example of an input that is a feature collection that can be encoded in one of three ways: as a GeoJSON feature collection, as a GML feature collection retrieved from a WFS or as a KML document.",
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentMediaType": "application/gml+xml; version=3.2"
          },
          {
            "type": "string",
            "contentSchema": "https://schemas.opengis.net/kml/2.3/ogckml23.xsd",
            "contentMediaType": "application/vnd.google-earth.kml+xml"
          },
          {
            "allOf": [
              {
                "format": "geojson-feature-collection"
              },
              {
                "$ref": "https://geojson.org/schema/FeatureCollection.json"
              }
            ]
          }
        ]
      }
    }
  },
  "outputs": {
    "stringOutput": {
      "schema": {
        "type": "string",
        "enum": [
          "Value1",
          "Value2",
          "Value3"
        ]
      }
    },
    "measureOutput": {
      "schema": {
        "type": "object",
        "required": [
          "value",
          "uom"
        ],
        "properties": {
          "measurement": {
            "type": "number"
          },
          "uom": {
            "type": "string"
          },
          "reference": {
            "type": "string",
            "format": "uri"
          }
        }
      }
    },
    "dateOutput": {
      "schema": {
        "type": "string",
        "format": "dateTime"
      }
    },
    "doubleOutput": {
      "schema": {
        "type": "number",
        "format": "double",
        "minimum": 0,
        "maximum": 10,
        "default": 5,
        "exclusiveMinimum": true
      }
    },
    "arrayOutput": {
      "schema": {
        "type": "array",
        "minItems": 2,
        "maxItems": 10,
        "items": {
          "type": "integer"
        }
      }
    },
    "complexObjectOutput": {
      "schema": {
        "type": "object",
        "required": [
          "property1",
          "property5"
        ],
        "properties": {
          "property1": {
            "type": "string"
          },
          "property2": {
            "type": "string",
            "format": "uri"
          },
          "property3": {
            "type": "number"
          },
          "property4": {
            "type": "string",
            "format": "dateTime"
          },
          "property5": {
            "type": "boolean"
          }
        }
      }
    },
    "geometryOutput": {
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentMediaType": "application/gml+xml",
            "contentSchema": "http://schemas.opengis.net/gml/3.2.1/geometryBasic2d.xsd"
          },
          {
            "allOf": [
              {
                "format": "geojson-geometry"
              },
              {
                "$ref": "http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.yaml"
              }
            ]
          }
        ]
      }
    },
    "boundingBoxOutput": {
      "schema": {
        "allOf": [
           {
             "format": "ogc-bbox"
           },
           {
             "$ref": "../../openapi/schemas/bbox.yaml"
           }
        ]
      }
    },
    "imagesOutput": {
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "application/tiff; application=geotiff"
          },
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "application/jp2"
          }
        ]
      }
    },
    "featureCollectionOutput": {
      "schema": {
        "oneOf": [
          {
            "type": "string",
            "contentMediaType": "application/gml+xml; version=3.2"
          },
          {
            "type": "string",
            "contentMediaType": "application/vnd.google-earth.kml+xml",
            "contentSchema": "https://schemas.opengis.net/kml/2.3/ogckml23.xsd"
          },
          {
            "allOf": [
              {
                "format": "geojson-feature-collection"
              },
              {
                "$ref": "https://geojson.org/schema/FeatureCollection.json"
              }
            ]
          }
        ]
      }
    }
  },
  "links": [
    {
      "href": "https://processing.example.org/oapi-p/processes/EchoProcess/execution",
      "rel": "http://www.opengis.net/def/rel/ogc/1.0/execute",
      "title": "Execute endpoint"
    }
  ]
}

The EchoProcess process simply echoes each process input value it is given.

9. Requirements classes for encodings

9.1. Overview

This clause specifies two pre-defined requirements classes for encodings to be used with the OGC API Processes.

JSON
HTML

The JSON encoding is mandatory.

Note that any server that supports multiple encodings 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 particular approach how this is supported by the server.

As clients simply need to dereference the URI of the link, the implementation details and the mechanism 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, for example, using format specific suffixes like .html);
an additional query parameter (for example, “accept” or “f”) that overrides the Accept header of the HTTP request.

The Core requirements class includes recommendations to support HTML and JSON as encodings, where practical.

9.2. Requirement Class “JSON”

This section defines the requirements class JSON.

Requirements class 3
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/json
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core
Dependency	JSON

Requirement 55

/req/json/definition

200-responses of the server SHALL support the following media type:

application/json

for the following API endpoints:

/
/conformance
/processes
/processes/{processID}
/jobs/{jobID}

and for the following API endpoint:

/processes/{processID}/execution

when the response parameter is set to the value document and/or the negotiated execution mode is asynchronous.

9.3. Requirement Class “HTML”

This section defines the requirements class HTML.

Requirements class 4
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/html
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core
Dependency	API — Common HTML
Dependency	W3C HTML 5

Requirement 57

/req/html/content

Every 200-response of the server with the media type “text/html” SHALL be a W3C HTML 5 document that includes the following information in the HTML body:

all information identified in the schemas of the Response Object in the HTML <body/>, and
all links in HTML <a/> elements in the HTML <body/>.

10. Requirements Class “OpenAPI 3.0”

10.1. Basic requirements

APIs conforming to this requirements class are documented as an OpenAPI Document.

Requirements class 5
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/oas30
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes 1.0 Core
Dependency	API — Common OpenAPI 3.0
Dependency	OpenAPI Specification 3.0.1

Requirement 58
/req/oas30/oas-definition-1
A	An OpenAPI definition in JSON using the media type `application/vnd.oai.openapi+json;version=3.0` and a HTML version of the API definition using the media type `text/html` SHALL be available.

10.2. Complete definition

Note that APIs that, for example, are access-controlled (see Security), support web cache validation, CORS or that use HTTP redirection will make use of additional HTTP status codes beyond regular codes such as 200 for successful GET requests and 400, 404 or 500 for error situations. See Clause 7.5.1.

Clients have to be prepared to receive responses not documented in the OpenAPI definition. For example, additional errors may occur in the transport layer outside of the server.

10.3. Exceptions

Example — An exception response object definition

description: An error occurred.
content:
  application/json:
    schema:
      $ref: https://beta.schemas.opengis.net/ogcapi/common/part1/0.1/core/openapi/schemas/exception.yaml
  text/html:
    schema:
      type: string

10.4. Security

The OpenAPI specification currently supports the following security schemes:

HTTP authentication,
an API key (either as a header or as a query parameter),
OAuth2’s common flows (implicit, password, application and access code) as defined in RFC6749, and
OpenID Connect Discovery.

11. Requirements Class “Job list”

11.1. Overview

This requirement class specifies how to retrieve a job list from the API.

Requirements class 6
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/job-list
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core

11.2. Operation

11.2.1. Job list

11.2.2. Parameter `type`

Requirement 65

/req/job-list/type-definition

The operation SHALL support a parameter type with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: type
in: query
required: false
schema:
  type: array
  items:
    type: string

Requirement 66
/req/job-list/type-response
A	If the parameter is provided and its value is `process` then only jobs created by an OGC processes API SHALL be included in the response.
B	If the parameter is omitted, then all jobs SHALL be included in the response.

11.2.3. Parameter `processID`

Requirement 68

/req/job-list/processID-definition

The operation SHALL support a parameter processID with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: processID
in: query
required: false
schema:
  type: array
  items:
    type: string

Requirement 69
/req/job-list/processid-response
If the parameter is specified with the operation, only jobs that have a value for the `processID` property (see: statusInfo.yaml) that matches one of the values specified for the `processID` parameter SHALL be included in the response.

11.2.4. Parameter `status`

Requirement 70

/req/job-list/status-definition

The operation SHALL support a parameter status with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: status
in: query
required: false
schema:
  type: array
  items:
    type: string

Requirement 71
/req/job-list/status-response
If the parameter is specified with the operation, only jobs that have a value for the `status` property (see: statusInfo.yaml) that matches one of the specified values of the `status` parameter SHALL be included in the response.

11.2.5. Parameter `datetime`

Requirement 72
/req/job-list/datetime-definition
A	The operation SHALL support a parameter `datetime` with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: datetime in: query required: false schema: type: string
B	The value of the `datetime` parameter is either a date-time value or a time interval. The parameter value SHALL conform to the following syntax (using ABNF): interval-closed = date-time "/" date-time interval-open-start = [".."] "/" date-time interval-open-end = date-time "/" [".."] interval = interval-closed / interval-open-start / interval-open-end datetime = date-time / interval
C	The syntax of `date-time` is specified by RFC 3339, 5.6.
D	Open ranges in time intervals at the start or end are supported using a double-dot (`..`) or an empty string for the start/end.

Requirement 73
/req/job-list/datetime-response
If the parameter is specified with the operation, only jobs that have a value for the `created` property (see: statusInfo.yaml that intersects the temporal information in the `datetime` parameter SHALL be included in the response.

11.2.6. Parameter `minDuration`, `maxDuration`

Requirement 74

/req/job-list/duration-definition

The operation SHALL support a parameter minDuration with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: minDuration
in: query
required: false
schema:
  type: array
  items:
    type: integer

The operation SHALL support a parameter maxDuration with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: maxDuration
in: query
required: false
schema:
  type: array
  items:
    type: integer
style: form
explode: false

Requirement 75
/req/job-list/status-response
Conditions	If the `status` parameter is not specified then only jobs that are running (status: `running`) or have completed execution (`successful`, `failed` or `dismissed`) SHALL be considered for inclusion in the response. If the `status` parameter is specified, then only jobs with the specified status SHALL be considered for inclusion in the response.
A	If only the `minDuration` parameter is specified with the operation, only jobs with the appropriate status and a duration of at least the specified `minDuration` value SHALL be included in the response.
B	If only the `maxDuration` parameter is specified with the operation, only jobs with the appropriate status and a duration of no longer than the specified `maxDuration` value SHALL be included in the response.
C	If both the `minDuration` and `maxDuration` parameters are specified with the operation, only jobs with the appropriate status and a duration of at least the specified `minDuration` value and no longer than the specified `maxDuration` value SHALL be included in the response.
D	The value of the `minDuration` and `maxDuration` parameters SHALL be number of seconds.
E	For running jobs, the duration SHALL be computed at runtime as the time the operation was invoked minus the value of the `started` parameter (see: statusInfo.yaml).
F	For completed jobs, the duration SHALL be computed as the value of the `finished` parameter minus the value of the `started` parameter (see: statusInfo.yaml).
G	Jobs for which runtime statistics are not included in the status information or are incomplete for computing the duration of the job SHALL be omitted from the response.

11.2.7. Parameter `limit`

Requirement 76

/req/job-list/limit-definition

The operation SHALL support a parameter limit with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: limit
in: query
required: false
schema:
  type: integer
  minimum: 1
  maximum: 10000
  default: 10

Requirement 77
/req/job-list/limit-response
A	The response SHALL not contain more jobs than specified by the optional `limit` parameter.
B	If the API definition specifies a maximum value for `limit` parameter, the response SHALL not contain more jobs than this maximum value.

11.3. Response

Requirement 78
/req/job-list/job-list-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. The content of that response SHALL be based upon the OpenAPI 3.0 schema jobList.yaml.

type: object
required:
  - jobs
  - links
properties:
  jobs:
    type: array
    items:
      $ref: "statusInfo.yaml"
  links:
    type: array
    items:
      $ref: "link.yaml"

Figure 27 — Schema for the job list

NOTE This schema can also be obtained from jobList.yaml.

(see also: statusInfo.yaml, link.yaml)

The schema defines an array of status info elements and includes a links section for navigation links within the API.

The number of jobs returned depends on the server and the parameter limit.

See the discussion about the limit parameter in the Limit parameter section.

Requirement 79

/req/job-list/links

A 200-response SHALL include the following links:

a link to this response document (relation: self),
a link to the response document in every other media type supported by the service (relation: alternate).

See the discussion about the next links in the Limit parameter section.

Recommendation 23
/rec/job-list/next-3
A	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`), if there are more jobs in the selection that have not yet been returned.

See the discussion about the prev link in the Limit parameter section.

Permission 10
/per/job-list/prev
A	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`).

Example 1 — A HTTP GET request for retrieving a list of jobs encoded as JSON.

http://processing.example.org/jobs

Example 2 — A job list encoded as JSON.

{
  "jobs": [
    {
      "processID": "Voronoi",
      "jobID": "8ca109b4-3b86-4a9c-a284-a6d50f91019e",
      "status": "running",
      "message": "Perform step 1/2",
      "progress": 50,
      "links": [
        {
          "href": "http://processing.example.org/oapi-p/jobs/8ca109b4-3b86-4a9c-a284-a6d50f91019e",
          "rel": "status",
          "type": "application/json",
          "hreflang": "en",
          "title": "Job status"
        }
      ]
    },
    {
      "processID": "EchoProcess",
      "jobID": "0cf773a5-282a-4e23-96cc-f5dab18123e5",
      "status": "successful",
      "message": "EchoProcess job finished successful",
      "progress": 100,
      "links": [
        {
          "href": "http://processing.example.org/oapi-p/jobs/0cf773a5-282a-4e23-96cc-f5dab18123e5",
          "rel": "status",
          "type": "application/json",
          "hreflang": "en",
          "title": "Job status"
        },
        {
          "href": "http://processing.example.org/oapi-p/jobs/0cf773a5-282a-4e23-96cc-f5dab18123e5/results",
          "rel": "http://www.opengis.net/def/rel/ogc/1.0/results",
          "type": "application/json",
          "hreflang": "en",
          "title": "Job result"
        }
      ]
    },
    {
      "processID": "EchoProcess",
      "jobID": "63aadd9c-c0e5-4a7f-80f0-228dbb158f09",
      "status": "failed",
      "message": "EchoProcess job failed",
      "progress": 100,
      "links": [
        {
          "href": "http://processing.example.org/oapi-p/jobs/63aadd9c-c0e5-4a7f-80f0-228dbb158f09",
          "rel": "status",
          "type": "application/json",
          "hreflang": "en",
          "title": "Job status"
        },
        {
          "href": "http://processing.example.org/oapi-p/jobs/63aadd9c-c0e5-4a7f-80f0-228dbb158f09/results",
          "rel": "http://www.opengis.net/def/rel/ogc/1.0/exceptions",
          "type": "application/json",
          "hreflang": "en",
          "title": "Job exception"
        }
      ]
    }
  ],
  "links": [
    {
      "href": "http://processing.example.org/jobs?limit3&f=json",
      "rel": "self",
      "type": "application/json"
    },
    {
      "href": "http://processing.example.org/jobs?f=html",
      "rel": "alternate",
      "type": "text/html"
    },
    {
       "href": "http//processing.example.org/jobs?offset=4&limit=3&f=json",
       "rel": "next"
    }

  ]
}

11.4. Error situations

See Clause 7.5.1 for general guidance.

If the process with the specified identifier does not exist on the server, the status code of the response SHALL be 404 (see Clause 7.10.3, Requirement 15).

12. Requirements Class “Callback”

The Callback conformance class specifies a callback mechanism for completed jobs. In contrast to the pull-based mechanism specified in Clause 7.11 and Clause 7.12, this conformance class specifies a push-based mechanism, where a subscriber-URL is passed to the API in the execute request. After the job is completed, the result response is sent to the specified URL.

Requirements class 7
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/callback
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core

Requirement 80
/req/callback/job-callback
The server SHALL support callback functions for jobs.

Example — A callback in the execute operation

callbacks:
    jobCompleted:
      '{$request.body#/subscriber/successUri}':
        post:
          requestBody:
            content:
              application/json:
                schema:
                  $ref: '#/components/schemas/results'
          responses:
            '202':
              description: Results received successfully

If the server implements this conformance class, the optional subscriber element of the execute request JSON SHALL be used.

Adding multiple callbacks is possible for getting progress updates and notifications of the success or failure of a job completion.

Further guidance about how to use callbacks can be found in the OpenAPI documentation.

13. Requirements Class “Dismiss”

The Dismiss requirement class specifies how to dismiss a job. Dismiss can be seen as cancelling a running job or removing artifacts of a finished job.

Requirements class 8
http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/dismiss
Obligation	requirement
Target type	Web API
Dependency	OGC API — Processes Core

13.1. Operation

13.2. Response

Requirement 82
/req/dismiss/job-dismiss-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. The content of that response SHALL be based upon the OpenAPI 3.0 schema statusInfo.yaml. The status SHALL be set to “dismissed”.

Example — A dismissed job encoded as JSON.

{
  "jobID" : "81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
  "status": "dismissed",
  "message": "Job dismissed",
  "progress": 56,
  "links": [
    {
      "href": "http://processing.example.org/oapi-p/jobs",
      "rel": "up",
      "type": "application/json",
      "title": "The job list of this server"
    }
  ]
}

13.3. Error situations

See Clause 7.5.1 for general guidance.

If the process with the specified identifier does not exist on the server, the status code of the response SHALL be 404 (see /req/core/process-exception/no-such-process).

If the job with the specified identifier does not exist, the status code of the response SHALL be 404 (see /req/core/job-results-exception/no-such-job).

14. Media Types

JSON media types that would typically be used in a server that supports JSON are:

application/json for all resources.

The typical HTML media type for all “web pages” in a server would be:

text/html.

The media type for an OpenAPI 3.0 definition is application/vnd.oai.openapi+json;version=3.0 (JSON) or application/vnd.oai.openapi;version=3.0 (YAML).

NOTE The OpenAPI media types have not been registered yet with IANA and can change in the future.

15. Additional API Building Blocks

The core requirements classes of the Processes API standard are designed for the following workflow:

Access the list of available processes
Access the description of a specific process
Create an execute JSON request (based on the description) and send it to the server via POST
Process the status info and/or results

This workflow is useful for generic clients that are implemented against the JSON schemas and paths specified in this standard. Generic clients can communicate with any server implementing the OGC API — Processes Standard. However, there may be limitations regarding the handling of input and output formats.

The approach described above requires implementers of clients to have knowledge about the standard.

This standard uses the OpenAPI specification to define the JSON schemas and OpenAPI MAY also be used to describe the concrete API (see Clause 7.3). A variety of tools for automatic code generation exist for the OpenAPI specification. This makes it very easy for client and server implementers to work with APIs defined using OpenAPI. However, as the OGC API — Processes Standard defines several JSON schemas and leaves the concrete data types for input and outputs open, the automatic code generation cannot be used to its full extent. To cope with this and thus make the implementation of clients / servers easier for those that are not familiar with OGC (API) standards, additional alternatives to the process description and the paths to processes and jobs are permitted.

The following permissions do not affect the mandatory core requirements.

Permission 11
/per/core/alternative-process-description
Servers MAY support alternative means of describing the inputs and outputs of a process.

The alternative-process-description permission allows server implementations to describe a process, such as by defining the request and response body of a POST request to a process endpoint using the OpenAPI specification directly (see this example).

Permission 12
/per/core/alternative-process-paths
Servers MAY support alternative API paths.

The alternative-process-paths permission allows server implementations to specify alternative paths to processes and jobs.

An example of an OpenAPI document making use of these building blocks is shown in the following:

openapi: 3.0.2
info:
  title: Alternative OGC API - Processes
  description: This is an alternative OGC API - Processes
  contact:
    email: you@your-company.com
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  version: 1.0.0
paths:
  /buffer:
    post:
      summary: execute buffer process
      operationId: executeBuffer
      requestBody:
        description: buffer inputs
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/bufferExecute'
      responses:
        "200":
          description: buffer created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/bufferResult'
        "400":
          description: invalid input
components:
  schemas:
    bufferExecute:
      required:
        - data
        - width
      type: object
      properties:
        data:
          maxItems: 10
          minItems: 1
          type: array
          description: this is possible to provide the abstract in here
          items:
            oneOf:
              - type: string
                format: application/geo+json
              - type: string
                format: application/gml+xml
        width:
          maximum: 100
          minimum: 1
          type: integer
          default: 20
    bufferResult:
      type: object
      properties:
        outputs:
          type: array
          items:
            oneOf:
              - type: string
                format: application/geo+json
              - type: string
                format: application/gml+xml

Figure 28

The goals of these additional API building blocks are:

Enabling a more seamless integration of this API with other OGC API standards and
Enabling the use of tools to auto-generate clients / servers from the API description.

Annex A
(normative)
Abstract Test Suite

A.1. Introduction

OGC Web Application Programming Interfaces (APIs) are not Web Services in the traditional sense. Rather, they define the behavior and content of a set of Resources exposed through a Web API. Therefore, an API may expose resources in addition to those defined by the standard. A test engine must be able to traverse the API, identify and validate test points, and ignore resource paths which are not to be tested.

The following requirement applies for a server implementing the OGC API — Processes — Part 1: Core under test:

Requirement A.1
/req/core/test-process
If a server implementing the OGC API — Processes — Part 1: Core is tested using CITE tests, the server SHALL offer at least one testable process. Please refer to Annex A.1, Recommendation A.1 for further guidance.

A.2. Conformance Class Core

Conformance class A.1
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core
Requirements class	Requirements Class “Core”
Target type	Web API

A.2.1. Landing Page /

Abstract test A.1
/conf/core/landingpage-op
Requirement	/req/core/landingpage-op
Test purpose	Validate that a landing page can be retrieved from the expected location.
Test method	Issue an HTTP GET request to the root URL `/` Validate the contents of the returned document using test /conf/core/landingpage-success.

Abstract test A.2
/conf/core/landingpage-success
Requirement	/req/core/landingpage-success
Test purpose	Validate that the landing page complies with the require structure and contents.
Test method	Validate that a document was returned with an HTTP status code or 200. Validate the landing page for all supported media types using the resources and tests identified in Table A.1 For formats that require manual inspection, perform the following: Validate that the landing page includes a “service-desc” and/or “service-doc” link to an API Definition. Validate that the landing page includes a “http://www.opengis.net/def/rel/ogc/1.0/conformance” link to the conformance class declaration. Validate that the landing page includes a “processes” link to the list of processes.
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.

Table A.1 — Schema and Tests for Landing Pages

Format	Schema Document	Test ID
HTML	landingPage.yaml	/conf/html/content
JSON	landingPage.yaml	/conf/geojson/content

A.2.2. API Definition /api

Abstract test A.3
/conf/core/api-definition-op
Requirement	/req/core/api-definition-op
Test purpose	Validate that the API Definition document can be retrieved from the expected location.
Test method	Construct a path for the API Definition document that ends with `/api`. Issue a HTTP GET request on that path Validate the contents of the returned document using test /conf/core/api-definition-success.

Abstract test A.4
/conf/core/api-definition-success
Requirement	/req/core/api-definition-success
Test purpose	Validate that the API Definition complies with the required structure and contents.
Test method	Validate that a document was returned with a status code 200 Validate the API Definition document against an appropriate schema document.

A.2.3. Conformance Path /conformance

Abstract test A.5
/conf/core/conformance-op
Requirement	/req/core/conformance-op
Test purpose	Validate that a Conformance Declaration can be retrieved from the expected location.
Test method	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. Issue an HTTP GET request on each path Validate the contents of the returned document using test /conf/core/conformance-success.

Abstract test A.6
/conf/core/conformance-success
Requirement	/req/core/conformance-success
Test purpose	Validate that the Conformance Declaration response complies with the required structure and contents.
Test method	Validate that a document was returned with an HTTP status code of 200. Validate the response document against OpenAPI 3.0 schema link: confClasses.yaml Validate that the document includes the conformance class “http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core” Validate that the document list all OGC API conformance classes that the API implements.

A.2.4. HTTP 1.1

Abstract test A.7
/conf/core/http
Requirement	/req/core/http
Test purpose	Validate that the resource paths advertised through the API conform with HTTP 1.1 and, where appropriate, TLS.
Test method	All compliance tests SHALL be configured to use the HTTP 1.1 protocol exclusively. For APIs which support HTTPS, all compliance tests SHALL be configured to use HTTP over TLS (RFC 2818) with their HTTP 1.1 protocol.

A.2.5. Processes /processes

A.2.5.1. Process list

Abstract test A.8
/conf/core/process-list
Requirement	/req/core/process-list
Test purpose	Validate that information about the processes can be retrieved from the expected location.
Test method	Issue an HTTP GET request to the URL {root}/processes Validate the contents of the returned document using test /conf/core/process-list-success.

Abstract test A.9
/conf/core/pl-limit-definition
Requirement	/req/core/pl-limit-definition
Test purpose	Validate that the `limit` query parameter is constructed correctly.
Test method	Verify that the `limit` query parameter complies with its definition in requirement /req/core/pl-limit-definition. Note that the API can define different values for “minimum”, “maximum” and “default”.

Abstract test A.10
/conf/core/process-list-success
Requirement	/req/core/process-list-success
Test purpose	Validate that the process list content complies with the required structure and contents.
Test method	Validate that a document was returned with an HTTP status code of 200. Validate the process list content for all supported media types using the resources and tests identified in Table A.2
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.

Table A.2 — Schema and Tests for Lists content

Format	Schema Document	Test ID
HTML	processList.yaml	/conf/html/content
JSON	processList.yaml	/conf/json/content

Abstract test A.11
/conf/core/pl-links
Requirement	/req/core/pl-links
Test purpose	Validate that the proper links are included in a response.
Test method	Get a list of process summaries as per test /conf/core/process-list-op. Verify that the `links` section of the response contains a link with `rel=self`. Verify that the `links` section of the response contains a link with `rel=alternate` for each response representation the service claims to support in its conformance document.

Abstract test A.12
/conf/core/pl-limit-response
Requirement	/req/core/pl-limit-response
Test purpose	Validate that the `limit` query parameter is processed correctly.
Test method	Get a list of processes as per test /conf/core/process-list-op and append the `limit` query parameter to the request. Count the number of process summaries listed in the response. Verify that this count is not greater than the value specified by the `limit` parameter. If the API definition specifies a maximum value for `limit` parameter, verify that the count does not exceed this maximum value.

A.2.5.2. Process description /processes/{processID}

Abstract test A.13
/conf/core/process
Requirement	/req/core/process
Test purpose	Validate that a process description can be retrieved from the expected location.
Test method	For every Process described in the process list content, issue an HTTP GET request to the URL `/processes/{processID}` where `{processID}` is the `id` property for the process. Validate the response using the test /conf/core/process-success.

Abstract test A.14
/conf/core/process-success
Requirement	/req/core/process-success
Test purpose	Validate that the content complies with the required structure and contents.
Test method	Validate that a document was returned with an HTTP status code of 200. Verify that the content of the response is valid description of the interface of the process for all supported process description models.
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.

Table A.3 — Schema and Tests for Process Description Models

Model	Schema Document	Test ID
OGC Process Description JSON	process.yaml	/conf/ogc-process-description/json-encoding

A.2.5.3. Process exception

Abstract test A.15
/conf/core/process-exception-no-such-process
Requirement	/req/core/process-exception-no-such-process
Test purpose	Validate that an invalid process identifier is handled correctly.
Test method	Issue an HTTP GET request to a URL that includes the `{processID}` as a path element using a non-existent process identifier. Validate that the document was returned with a 404. Validate that the document contains the exception `type` “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-process”. Validate the document for all supported media types using the resources and tests identified in Table A.4
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.

Table A.4 — Schema and Tests for Non-existent Process

Format	Schema Document	Test ID
HTML	exception.yaml	/conf/html/content
JSON	exception.yaml	/conf/json/content

A.2.6. Jobs

A.2.6.1. Job creation /processes/{processID}/execution

Abstract test A.16
/conf/core/job-creation-op
Requirement	/req/core/job-creation-op
Test purpose	Validate the creation of a new job.
Test method	Issue an HTTP POST request to the URL ‘/processes/{processID}/execution’ for each execution mode according to requirements /conf/core/job-creation-default-execution-mode or /conf/core/job-creation-auto-execution-mode. Validate the contents of the POST request using the test /conf/core/job-creation-request. Validate the creation of the job according the requirements /req/core/job-creation-default-execution-mode, /req/core/job-creation-auto-execution-mode.

Abstract test A.17
/conf/core/job-creation-auto-execution-mode
Requirement	/req/core/job-creation-op
Test purpose	Validate that the server correctly handles the execution mode for a process.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and take note of the job control options for the process. Setting the HTTP `Prefer` header to include the `respond-sync` preference, construct an execute request according to test /conf/core/job-creation-request. For processes that are supposed to execute asynchronously according to the /req/core/job-creation-auto-execution-mode requirement, verify the successful execution according to the /conf/core/job-creation-success-async test. For processes that are supposed to execute synchronously according to the /req/core/job-creation-auto-execution-mode requirement, verify the successful execution according to the relevant requirement based on the combination of execute parameters. For processes that may execute either synchronously or asynchronously according to the /req/core/job-creation-auto-execution-mode requirement, verify that successful execution according to the relevant requirement based on the combination of execute parameters.

Abstract test A.18
/conf/core/job-creation-default-execution-mode
Requirement	/req/core/job-creation-op
Test purpose	Validate that the server correctly handles the default execution mode for a process.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and take note of the job control options for the process. Without setting the HTTP `Prefer` header, construct an execute request according to test /conf/core/job-creation-request. For processes that are supposed to execute asynchronously according to the /req/core/job-creation-default-execution-mode requirement, verify the successful execution according to the /conf/core/job-creation-success-async test. For processes that are supposed to execute synchronously according to the /req/core/job-creation-auto-execution-mode requirement, verify the successful synchronous execution according to the relevant requirement based on the combination of execute parameters.

Abstract test A.19
/conf/core/job-creation-request
Requirement	/req/core/job-creation-request
Test purpose	Validate that the body of a job creation operation complies with the required structure and contents.
Test method	Verify the contents of the request body against the OpenAPI 3.0 schema execute.yaml.

Abstract test A.20
/conf/core/job-creation-inputs
Requirement	/req/core/job-creation-inputs
Test purpose	Validate that servers can accept input values both inline and by reference.
Test method	Verify that the server passes tests /conf/core/job-creation-input-inline and /conf/core/job-creation-input-ref .

Abstract test A.21
/conf/core/job-creation-input-inline
Requirement	/req/core/job-creation-input-inline
Test purpose	Validate in-line process input values are validated against the corresponding schema from the process description.
Test method	Get a description of each process offered by the server using test /conf/core/process. For each process construct an execute request according to test /conf/core/job-creation-request taking care to encode process inputs in-line with the execute request according to the requirement /req/core/job-creation-input-inline. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.22
/conf/core/job-creation-input-ref
Requirement	/req/core/job-creation-input-ref
Test purpose	Validate that input values specified by reference in an execute request are correctly processed.
Test method	Get a description of each process offered by the server using test /conf/core/process. For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode input values by reference according to requirement /req/core/job-creation-input-ref. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.23
/conf/core/job-creation-input-array
Requirement	/req/core/job-creation-input-array
Test purpose	Verify that the server correctly recognizes the encoding of parameter values for input parameters with a maximum cardinality greater than one.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the list of processes that have inputs with a maximum cardinality greater that one. For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode the inputs with maximum cardinality > 1 according to the requirement /req/core/job-creation-input-array. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.24
/conf/core/job-creation-input-inline-object
Requirement	/req/core/job-creation-input-inline-object
Test purpose	Validate that inputs with a complex object schema encoded in-line in an execute request are correctly processed.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that have inputs with complex object schemas (i.e. inputs of type `object). For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode the identified object inputs in-line in the execute request according to requirement /req/core/job-creation-input-inline-object. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.25
/conf/core/job-creation-input-inline-mixed
Requirement	/req/core/job-creation-input-inline-mixed
Test purpose	Validate that inputs of mixed content encoded in-line in an execute request are correctly processed.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that have inputs of mixed content using the `oneOf[]` JSON Schema construct to define several alternate input value schemas. For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode the identified mix-content inputs in-line in the execute request according to requirement /req/core/job-creation-input-inline-mixed. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.26
/conf/core/job-creation-input-inline-binary
Requirement	/req/core/job-creation-input-binary
Test purpose	Validate that binary input values encoded as base-64 string in-line in an execute request are correctly processes.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that have binary inputs. For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode binary input values in-line in the execute request according to requirement /req/core/job-creation-input-inline-binary. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.27
/conf/core/job-creation-input-inline-bbox
Requirement	/req/core/job-creation-input-inline-bbox
Test purpose	Validate that inputs with a bounding box schema encoded in-line in an execute request are correctly processed.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that have bounding box inputs that are supposed to conform to the bbox.yaml schema. For each identified process construct an execute request according to test /conf/core/job-creation-request taking care to encode values for the identified bounding box inputs in-line in the execute request. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters.

Abstract test A.28
/conf/core/job-creation-input-validation
Requirement	/req/core/job-creation-input-validation
Test purpose	Verify that the server correctly validates process input values according to the definition obtained from the process description.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process taking note of the definition of each process input and specifically the schema of each process input. For each process construct an execute request according to test /conf/core/job-creation-request taking care to encode the input values according to the schema from the definition of each input. Verify that each process executes successfully according to the relevant requirement based on the combination of execute parameters. For each process construct an execute request according to test /conf/core/job-creation-request taking care to encode some of the input values in violation of the schema from the definition of the selected input. Verify that each process generates an exception report that identifies the improperly specified input value(s).

The response generated when executing a process depends on a number of parameters specified in the execute request. The following table enumerates the relevant requirement that needs to be satisfied based on the various execute parameter combinations.

mode	response	tx mode	# out	requirement
sync	raw	value	1	/req/core/job-creation-sync-raw-value-one
		value	*	/req/core/job-creation-sync-raw-value-multi
		ref	1	/req/core/job-creation-sync-raw-ref
		ref	*	/req/core/job-creation-sync-raw-ref
	document	value	1	/req/core/job-creation-sync-document
		value	*
		ref	1
		ref	*
async	any	any	any	/req/core/job-creation-success-async
NOTE The value any in a cell means “for any valid value of the execute parameter represented by that cell”.

Abstract test A.29
/conf/core/job-creation-sync-raw-value-one
Requirement	/req/core/job-creation-sync-raw-value-one
Test purpose	Validate that the server responds as expected when synchronous execution is negotiated, a single output value is requested, the response type is `raw` and the output transmission is `value`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate at least one output and support the `sync-execute` job control option and the `value` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-default-execution-mode, that only one output is requested, that the requested response type is `raw` (i.e. `"response": "raw"`) and that the output transmission is set to `value` (i.e. `"transmissionMode": "value"`) according to requirement /req/core/job-creation-sync-raw-value-one. Verify that each process executes successfully according to requirement /req/core/job-creation-sync-raw-value-one.

Abstract test A.30
/conf/core/job-creation-sync-raw-value-multi
Requirement	/req/core/job-creation-sync-raw-value-multi
Test purpose	Validate that the server responds as expected when synchronous execution is negotiated, the response type is `raw` and the output transmission is `value`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate more that one output, support the `sync-execute` job control option and the `value` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-default-execution-mode, that more than one output is requested, that the requested response type is `raw` (i.e. `"response": "raw"`) and the the transmission mode is set to `value` (i.e. `"transmissionMode": "value"`) according to requirement /req/core/job-creation-sync-raw-value-multi. Verify that each process executes successfully according to requirement /req/core/job-creation-sync-raw-value-multi.

Abstract test A.31
/conf/core/job-creation-sync-raw-ref
Requirement	/req/core/job-creation-sync-raw-ref
Test purpose	Validate that the server responds as expected when synchronous execution is negotiated, the response type is `raw` and the transmission mode is `ref`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that support the `sync-execute` job control option and the `reference` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-default-execution-mode, that the requested response type is `raw` (i.e. `"response": "raw"`) and the transmission mode is set to `ref` (i.e. `"transmissionMode": "ref"`) according to requirement /req/core/job-creation-sync-raw-ref. Verify that each process executes successfully according to requirement /req/core/job-creation-sync-raw-ref.

Abstract test A.32
/conf/core/job-creation-sync-raw-mixed-multi
Requirement	/req/core/job-creation-sync-raw-mixed-multi
Test purpose	Validate that the server responds as expected when synchronous execution is negotiated, the response type is `raw` and the output transmission is a mix of `value` and `reference`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate more that one output and support the `sync-execute` job control option. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-default-execution-mode, that more than one output is requested, that the requested response type is `raw` (i.e. `"response": "raw"`) and the the transmission mode is a mix of `value` (i.e. `"transmissionMode": "value"`) and reference (i.e. `"transmissionMode": "reference"`) according to requirement /req/core/job-creation-sync-raw-mixed-multi. Verify that each process executes successfully according to requirement /req/core/job-creation-sync-raw-mixed-multi. For each output requested with `"transmissionMode": "value"` verify that the body of the corresponding part contains the output value. For each output requested with `"transmissionMode": "reference"` verify that the body of the corresponding part is empty and the `Content-Location` header is included that points to the output value.

Abstract test A.33
/conf/core/job-creation-sync-document
Requirement	/req/core/job-creation-sync-document
Test purpose	Validate that the server responds as expected when synchronous execution is negotiated and the response type is `document`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that support the `sync-execute` job control option. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution has been negotiated according to tests /conf/core/job-creation-default-execution-mode and the requested response type is `document` (i.e. `"response": "document"`) according to requirement /req /core/job-creation-sync-document. Verify that each process executes successfully according to requirement /req/core/job-creation-sync-document.

Abstract test A.34
/conf/core/job-creation-success-async
Requirement	/req/core/job-creation-success-async
Test purpose	Validate the results of a job that has been created using the `async` execution mode.
Test method	Validate that results of the job was returned with an HTTP status code 201. Validate the HTTP headers of the results using the test /conf/core/job-creation-success-header-async.

A.2.6.2. Job status /jobs/{jobID}

Abstract test A.35
/conf/core/job-op
Requirement	/req/core/job
Test purpose	Validate that the status info of a job can be retrieved.
Test method	Create a job as per /req/core/job-creation-op and note the {jobID} assigned to the job. Issue an HTTP GET request to the URL ‘/jobs/{jobID}’. Validate the contents of the returned document using the test /conf/core/job-success.

Abstract test A.36
/conf/core/job-success
Requirement	/req/core/job-success
Test purpose	Validate that the job status info complies with the require structure and contents.
Test method	Validate that the document was returned with an HTTP status code of 200. Validate the job status info for all supported media types using the resources and tests identified in Table A.5
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.

Table A.5 — Schema and Tests for the Job Status Info

Format	Schema Document	Test ID
HTML	statusInfo.yaml	/conf/html/content
JSON	statusInfo.yaml	/conf/json/content

Abstract test A.37
/conf/core/job-exception-no-such-job
Requirement	/req/core/job-exception-no-such-job
Test purpose	Validate that an invalid job identifier is handled correctly.
Test method	Issue an HTTP GET request to the URL that includes the `{jobID}` as a path element using a non-existent job identifier. Validate that the document was returned with a 404. Validate that the document contains the exception type “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-job”. Validate the document for all supported media types using the resources and tests identified in Table A.6
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.

Table A.6 — Schema and Tests for the Job Result for Non-existent Job

Format	Schema Document	Test ID
HTML	exception.yaml	/conf/html/content
JSON	exception.yaml	/conf/json/content

A.2.6.3. Job results /jobs/{jobID}/results

Abstract test A.38
/conf/core/job-results
Requirement	/req/core/job-results
Test purpose	Validate that the results of a job can be retrieved.
Test method	Create a job as per /req/core/job-creation-op and note the {jobID} assigned to the job. Issue an HTTP GET request to the URL ‘/jobs/{jobID}/results’. Validate that the document was returned with a status code 200. Validate the contents of the returned document using the test /conf/core/job-results-success.

Retrieving the results of an asynchronously executed process depends on a number of parameters specified in the execute request. The following table enumerates the relevant requirement that needs to be satisfied based on the various execute parameter combinations.

mode	response	tx mode	# out	abstract test
sync	any	any	any	/conf/core/job-results-sync
async	raw	value	1	/conf/core/job-results-async-raw-value-one
		value	*	/conf/core/job-results-async-raw-value-multi
		ref	1	/conf/core/job-results-async-raw-ref
		ref	*	/conf/core/job-results-async-raw-ref
	document	value	1	/conf/core/job-results-async-document
		value	*
		ref	1
		ref	*
NOTE The value any in a cell means “for any valid value of the execute parameter represented by that cell”.

Abstract test A.39
/conf/core/job-results-sync
Requirement	/req/core/job-results-sync
Test purpose	Validate that the server responds as expected when getting results from a job for a process that has been executed synchronously.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that support the `sync-execute` job control option. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-default-execution-mode. Inspect the headers of the response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/core/job-op and ensure that the job status is set to `successful`.

Abstract test A.40
/conf/core/job-results-async-raw-value-one
Requirement	/req/core/job-results-async-raw-value-one
Test purpose	Validate that the server responds as expected when asynchronous execution is negotiated, one output is requested, the response type is `raw` and the output transmission is `value`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate at least one output and that support the `async-execute` job control option and the `value` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that asynchronous execution is negotiated according to test /conf/core/job-creation-auto-execution-mode, that the requested response type is `raw` (i.e. `"response": "raw"`) and that the output transmission is set to `value` (i.e. `"outputTransmission": "value"`) according to requirement /req/core/job-creation-async-raw-value-one. If the server responds asynchronously, periodically retrieve the status of the asynchronously executed job as per test /conf/core/job-op. When the job status is `successful`, get the results as per test /conf/core/job-results and verify that they conform to requirement /req/core/job-results-async-raw-value-one.
NOTE 1 In the case where a process supports both `async-execute` and `sync-execute` job control options there is a possibility that the server responds synchronously even though the `Prefer` headers asserts a `respond-async` preference. In this case, the following additional test should be performed.
Test method	Inspect the headers of the synchronous response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/core/job-op and ensure that the job status is set to `successful`. Get the results as per test /conf/core/job-results and verify that they conform to the test /conf/core/job-results-async-raw-value-multi. If the link does not exist then verify that the synchronous response conforms to requirement /req/core/job-creation-sync-raw-value-one.

Abstract test A.41
/conf/core/job-results-async-raw-value-multi
Requirement	/req/core/job-results-async-raw-value-multi
Test purpose	Validate that the server responds as expected when asynchronous execution is negotiated, more than one output is requested, the response type is `raw` and the output transmission is `value`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate more than one output and that support the `async-execute` job control option and the `value` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that asynchronous execution is negotiated according to test /conf/core/job-creation-auto-execution-mode, that the requested response type is `raw` (i.e. `"response": "raw"`) and that the output transmission is set to `value` (i.e. `"outputTransmission": "value"`) according to requirement /req/core/job-creation-async-raw-value-multi. Periodically retrieve the status of the asynchronously execute job as per test /conf/core/job-op. When the job status is `successful`, get the results as per test /conf/core/job-results and verify that they conform to requirement /conf/core/job-results-async-raw-value-multi.
NOTE 2 In the case where a process supports both `async-execute` and `sync-execute` job control options there is a possibility that the server responds synchronously even though the `Prefer` headers asserts a `respond-async` preference. In this case, the following additional test should be performed.
Test method	Inspect the headers of the synchronous response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/core/job-op and ensure that the job status is set to `successful`. Get the results as per test /conf/core/job-results and verify that they conform to the test /conf/core/job-results-async-raw-value-multi. If the link does not exist then verify that the synchronous response conforms to requirement /req/core/job-creation-sync-raw-value-multi.

Abstract test A.42
/conf/core/job-results-async-raw-ref
Requirement	/req/core/job-results-async-raw-ref
Test purpose	Validate that the server responds as expected when asynchronous execution is negotiated, the response type is `raw` and the output transmission is `reference`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that support the `async-execute` job control option and the `reference` output transmission. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that synchronous execution is negotiated according to test /conf/core/job-creation-auto-execution-mode, that the requested response type is `raw` (i.e. `"response": "raw"`) and that the output transmission is set to `reference` (i.e. `"outputTransmission": "reference"`) according to requirement /req/core/job-creation-async-raw-ref. If the server responds asynchronously, periodically retrieve the status of the asynchronously executed job as per test /conf/core/job-op. When the job status is `successful`, get the results as per test /conf/core/job-results and verify that they conform to requirement /req/core/job-results-async-ref.
NOTE 3 In the case where a process supports both `async-execute` and `sync-execute` job control options there is a possibility that the server responds synchronously even though the `Prefer` headers asserts a `respond-async` preference. In this case, the following additional test should be performed.
Test method	Inspect the headers of the synchronous response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/core/job-op and ensure that the job status is set to `successful`. Get the results as per test /conf/core/job-results and verify that they conform to the test /conf/core/job-results-async-document. If the link does not exist then verify that the synchronous response conforms to requirement /req/core/job-creation-sync-raw-ref.

Abstract test A.43
/conf/core/job-results-async-raw-mixed-multi
Requirement	/req/core/job-results-async-raw-mixed-multi
Test purpose	Validate that the server responds as expected when asynchronous execution is negotiated, more than one output is requested, the response type is `raw` and the output transmission is a mix of `value` and `reference`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that generate more than one output and that support the `async-execute` job control option. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that asynchronous execution is negotiated according to test /conf/core/job-creation-auto-execution-mode, that the requested response type is `raw` (i.e. `"response": "raw"`) and that the output transmission is set to a mix of `value` (i.e. `"outputTransmission": "value"`) and `reference` (i.e. `"outputTransmission": "reference"`) according to requirement /req/core/job-creation-async-raw-mixed-multi. Periodically retrieve the status of the asynchronously execute job as per test /conf/core/job-op. When the job status is `successful`, get the results as per test /conf/core/job-results and verify that they conform to requirement /conf/core/job-results-async-raw-mixed-multi. For each output requested with `"transmissionMode": "value"` verify that the body of the corresponding part contains the output value. For each output requested with `"transmissionMode": "reference"` verify that the body of the corresponding part is empty and the `Content-Location` header is included that points to the output value.
NOTE 4 In the case where a process supports both `async-execute` and `sync-execute` job control options there is a possibility that the server responds synchronously even though the `Prefer` headers asserts a `respond-async` preference. In this case, the following additional test should be performed.
Test method	Inspect the headers of the synchronous response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/cor e/job-op and ensure that the job status is set to `successful`. Get the results as per test /conf/core/job-results and verify that they conform to the test /conf/core/job-results-async-raw-mixed-multi. If the link does not exist then verify that the synchronous response conforms to requirement /req/core/job-creation-sync-raw-mixed-multi.

Abstract test A.44
/conf/core/job-results-async-document
Requirement	/req/core/job-results-async-document
Test purpose	Validate that the server responds as expected when the asynchronous execution is negotiated and the response type is `document`.
Test method	Get a description of each process offered by the server using test /conf/core/process. Inspect the description of each process and identify the subset of processes that support the `async-execute` job control option. For each identified process construct an execute request according to test /conf/core/job-creation-request ensuring that asynchronous execution is negotiated according to test /conf/core/job-creation-auto-execution-mode and that the requested response type is `document` (i.e. `"response": "document"`) according to requirement /req/core/job-creation-async-document. If the server responds asynchronously periodically retrieve the status of the asynchronously execute job as per test /conf/core/job-op. When the job status is `successful`, get the results as per test /conf/core/job-results and verify that they conform to requirement /req/core/job-results-async-document.
NOTE 5 In the case where a process supports both `async-execute` and `sync-execute` job control options there is a possibility that the server responds synchronously even though the `Prefer` headers asserts a `respond-async` preference. In this case, the following additional test should be performed:
Test method	Inspect the headers of the synchronous response and see if a `Link` header is included with `rel=monitor`. If the link exists, get the job status as per test /conf/cor e/job-op and ensure that the job status is set to `successful`. Get the results as per test /conf/core/job-results and verify that they conform to the test /conf/core/job-results-async-document. If the link does not exist then verify that the synchronous response conforms to the requirement /req/core/job-creation-sync-documen.

Abstract test A.45
/conf/core/job-results-failed
Requirement	/req/core/job-results-exception-no-such-job
Test purpose	Validate that the job results retrieved using an invalid job identifier complies with the require structure and contents.
Test method	Issue an HTTP GET request to the URL ‘/jobs/{jobID}/results’ using an invalid {jobID}. Validate that the document was returned with a 404. Validate that the document contains the exception type “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/no-such-job”. Validate the document for all supported media types using the resources and tests identified in Table A.7
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.

Table A.7 — Schema and Tests for the Job Result for Non-existent Job

Format	Schema Document	Test ID
HTML	exception.yaml	/conf/html/content
JSON	exception.yaml	/conf/json/content

Abstract test A.46
/conf/core/job-results-exception-results-not-ready
Requirement	/req/core/job-results-exception-results-not-ready
Test purpose	Validate that the job results retrieved for an incomplete job complies with the require structure and contents.
Test method	Create a job as per /req/core/job-creation-op and note the {jobID} assigned to the job; ensure that the job is long-running. Issue an HTTP GET request to the URL ‘/jobs/{jobID}/results’ before the job completes execution. Validate that the document was returned with a 404. Validate that the document contains the exception `type` “http://www.opengis.net/def/exceptions/ogcapi-processes-1/1.0/result-not-ready”. Validate the document for all supported media types using the resources and tests identified in Table A.8
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.

Table A.8 — Schema and Tests for the Job Result for an Incomplete Job

Format	Schema Document	Test ID
HTML	exception.yaml	/conf/html/content
JSON	exception.yaml	/conf/json/content

Abstract test A.47
/conf/core/job-results-failed
Requirement	/req/core/job-results-failed
Test purpose	Validate that the job results for a failed job complies with the require structure and contents.
Test method	Create a job as per /req/core/job-creation-op but arrange a priori that the job will fail; note the {jobID} assigned to the job. Ensure that the failed job will not result in an HTTP error code of 404. Issue an HTTP GET request to the URL ‘/jobs/{jobID}/results’. Validate that the document was returned with a HTTP error code (4XX or 5XX). Validate that the document contains an exception `type` that corresponds to the reason the job failed (e.g. InvalidParameterValue for invalid input data). Validate the document for all supported media types using the resources and tests identified in Table A.9
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.

Table A.9 — Schema and Tests for the Job Result for a Failed Job

Format	Schema Document	Test ID
HTML	exception.yaml	/conf/html/content
JSON	exception.yaml	/conf/json/content

A.3. Conformance Class OGC Process Description

Conformance class A.2
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/ogc-process-description
Requirements class	Requirements Class “OGC Process Description”
Target type	Web API

Abstract test A.48
/conf/ogc-process-description/json-encoding
Requirement	/req/ogc-process-description/json-encoding
Test purpose	Verify that a JSON-encoded OGC Process Description complies with the required structure and contents.
Test method	Retrieve a description of each process according to test /conf/core/process. For each process, verify the contents of the response body validate against the JSON Schema: process.yaml.

Abstract test A.49
/conf/ogc-process-description/inputs-def
Requirement	/req/ogc-process-description/inputs-def
Test purpose	Verify that the definition of `inputs` for each process complies with the required structure and contents.
Test method	Retrieve a description of each process according to test /conf/core/process. For each process, verify that the definition of the inputs conforms to the JSON Schema: inputDescription.yaml.

Abstract test A.50
/conf/ogc-process-description/input-def
Requirement	/req/ogc-process-description/input-def
Test purpose	Verify that the definition of each input for each process complies with the required structure and contents.
Test method	For each input identified according to the test /conf/ogc-process-description/inputs-def verify that the value of the `schema` key, that defines the input, validates according to the JSON Schema: schema.yaml.

Abstract test A.51
/conf/ogc-process-description/input-mixed-type
Requirement	/req/ogc-process-description/input-mixed-type
Test purpose	Validate that each input of mixed type complies with the required structure and contents.
Test method	Retrieve a description of each process according to test /conf/core/process. For each process identify if the process has one or more inputs of mixed type. For each sub-schema of each identified input, verify that the definition validates according to the JSON Schema: schema.yaml.

Abstract test A.52
/conf/ogc-process-description/outputs-def
Requirement	/req/ogc-process-description/outputs-def
Test purpose	Verify that the definition of `outputs` for each process complies with the required structure and contents.
Test method	Retrieve a description of each process according to test /conf/core/process. For each process, verify that the definition of the outputs conforms to the JSON Schema: outputDescription.yaml.

Abstract test A.53
/conf/ogc-process-description/output-def
Requirement	/req/ogc-process-description/output-def
Test purpose	Verify that the definition of each output for each process complies with the required structure and contents.
Test method	For each output identified according to the test /conf/ogc-process-description/outputs-def verify that the value of the `schema` key, that defines the output, validates according to the JSON Schema: schema.yaml.

Abstract test A.54
/conf/ogc-process-description/output-mixed-type
Requirement	/req/ogc-process-description/output-mixed-type
Test purpose	Validate that each output of mixed type complies with the required structure and contents.
Test method	Retrieve a description of each process according to test /conf/core/process. 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. For each sub-schema or each identified output, verify that the definition validates according to the JSON Schema: schema.yaml.

A.4. Conformance Class JSON

Conformance class A.3
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/json
Requirements class	Requirements Class “Core”
Target type	Web API

Abstract test A.55
/conf/json/definition
Requirement	/req/json/definition
Test purpose	Verify support for JSON.
Test method	A resource is requested with response media type of `application/json`. All `200` responses SHALL support the following media types: `application/json` for all resources.

A.5. Conformance Class HTML

Conformance class A.4
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/dismiss
Requirements class	Requirements Class “Core”
Dependency	Conformance Class “Core”
Target type	Web API

Abstract test A.56
/conf/html/content
Requirement	/req/html/content
Test purpose	Verify the content of an HTML document given an input document and schema.
Test method	Validate that the document is an W3C HTML 5 document Manually inspect the document and verify that the HTML body contains: all information in the schemas of the Response Object in the HTML `<body/>` all links in HTML `<a/>` elements in the HTML `<body/>`.

Abstract test A.57
/conf/html/definition
Requirement	/req/html/definition
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`.

A.6. Conformance Class OpenAPI 3.0

Conformance class A.5
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/oas30
Requirements class	Requirements Class “OpenAPI Specification 3.0”
Dependency	Conformance Class “Core”
Target type	Web API

Abstract test A.58
/conf/oas30/completeness
Requirement	/req/oas30/completeness
Test purpose	Verify the completeness of an OpenAPI document.
Test method	Verify that for each operation, the OpenAPI document describes all HTTP Status Codes and Response Objects that the API uses in responses.

Abstract test A.59
/conf/oas30/exceptions-codes
Requirement	/req/oas30/exceptions-codes
Test purpose	Verify that the OpenAPI document fully describes potential exception codes.
Test method	Verify that for each operation, the OpenAPI document describes all HTTP Status Codes that may be generated.

Abstract test A.60
/conf/oas30/oas-definition-1
Requirement	/req/oas30/oas-definition-1
Test purpose	Verify that JSON and HTML versions of the OpenAPI document are available.
Test method	Verify that an OpenAPI definition in JSON is available using the media type `application/vnd.oai.openapi+json;version=3.0` and link relation `service-desc` Verify that an HTML version of the API definition is available using the media type `text/html` and link relation `service-doc`.

Abstract test A.61
/conf/oas30/oas-definition-2
Requirement	/req/oas30/oas-definition-2
Test purpose	Verify that the OpenAPI document is valid JSON.
Test method	Verify that the JSON representation conforms to the OpenAPI Specification, version 3.0.

Abstract test A.62
/conf/oas30/oas-impl
Requirement	/req/oas30/oas-impl
Test purpose	Verify that all capabilities specified in the OpenAPI definition are implemented by the API.
Test method	Construct a path from each URL template including all server URL options and all enumerated path parameters. For each path defined in the OpenAPI document, validate that the path performs in accordance with the API definition and the OGC API — Processes standard.

Abstract test A.63
/conf/oas30/security
Requirement	/req/oas30/security
Test purpose	Verify that any authentication protocols implemented by the API are documented in the OpenAPI document.
Test method	Identify all authentication protocols supported by the API. Validate that each authentication protocol is described in the OpenAPI document by a Security Schema Object and its use is specified by a Security Requirement Object.

A.7. Conformance Class Job list

Conformance class A.6
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/job-list
Requirements class	Requirements Class “Core”
Target type	Web API

Abstract test A.64
/conf/job-list/job-list-op
Requirement	/req/job-list/job-list-op
Test purpose	Validate that information about jobs can be retrieved from the expected location.
Test method	Issue an HTTP GET request to the URL /jobs. Validate the contents of the returned document using test /conf/job-list/job-list-success.

Abstract test A.65
/conf/job-list/type-definition
Requirement	/req/job-list/type-definition
Test purpose	Validate that the `type` query parameter is constructed correctly.
Test method	Verify that the `type` query parameter complies with its definition in requirement /req/job-list/type-definition.

Abstract test A.66
/conf/job-list/processID-definition
Requirement	/req/job-list/processID-definition
Test purpose	Validate that the `processID` query parameter is constructed correctly.
Test method	Verify that the `processID` query parameter complies with its definition in requirement /req/job-list/processID-definition.

Abstract test A.67
/conf/job-list/status-definition
Requirement	/req/job-list/status-definition
Test purpose	Validate that the `status` query parameter is constructed correctly.
Test method	Verify that the `status` query parameter complies with its definition in requirement /req/job-list/status-definition.

Abstract test A.68
/conf/job-list/datetime-definition
Requirement	/req/job-list/datetime-definition
Test purpose	Validate that the `datetime` query parameter is constructed correctly.
Test method	Verify that the `datetime` query parameter complies with its definition in requirement /req/job-list/datetime-definition.

Abstract test A.69
/conf/job-list/duration-definition
Requirement	/req/job-list/duration-definition
Test purpose	Validate that the `minDuration` and `maxDuration` query parameter are constructed correctly.
Test method	Verify that the `minDuration` query parameter complies with its definition in requirement /req/job-list/duration-definition, A. Verify that the `maxDuration` query parameter complies with its definition in requirement /req/job-list/duration-definition, B.

Abstract test A.70
/conf/job-list/limit-definition
Requirement	/req/job-list/limit-definition
Test purpose	Validate that the `limit` query parameter is constructed correctly.
Test method	Verify that the `limit` query parameter complies with its definition in requirement /req/job-list/limit-definition. Note that the API can define different values for “minimum”, “maximum” and “default”.

Abstract test A.71
/conf/job-list/job-list-success
Requirement	/req/job-list/job-list-success
Test purpose	Validate that the job list content complies with the required structure and contents.
Test method	Validate that a document was returned with an HTTP status code of 200. Validate the job list content for all supported media types using the resources and tests identified in Table A.10
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.

Table A.10 — Schema and Tests for Job List Content

Format	Schema Document	Test ID
HTML	jobList.yaml	/conf/html/content
JSON	jobList.yaml	/conf/json/content

Abstract test A.72
/conf/job-list/links
Requirement	/req/job-list/links
Test purpose	Validate that the proper links are included in a response.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op. Verify that the `links` section of the response contains a link with `rel=self`. Verify that the `links` section of the response contains a link with `rel=alternate` for each response representation the service claims to support in its conformance document.

Abstract test A.73
/conf/job-list/type-response
Requirement	/req/job-list/type-response
Test purpose	Validate that the `type` query parameter is processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `type` query parameter to the request. Inspect the value of the `type` property for each job listed in the response. Verify that that value of the `type` property matches one of the values specified for the `type` query parameter.

Abstract test A.74
/conf/job-list/processID-mandatory
Requirement	/req/job-list/processID-mandatory
Test purpose	Validate that the `processID` property is present in every job.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op. Verify that each job includes a `processID` property.

Abstract test A.75
/conf/job-list/processID-response
Requirement	/req/job-list/processID-response
Test purpose	Validate that the `processID` query parameter is processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `processID` parameter to the request. Inspect the value of the `processID` property for each job listed in the response. Verify that that value of the `processID` property matches one of the values specified for the `processID` query parameter.

Abstract test A.76
/conf/job-list/status-response
Requirement	/req/job-list/status-response
Test purpose	Validate that the `status` query parameter is processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `status` query parameter to the request. Inspect the value of the `status` property (see: statusInfo.yaml) for each job listed in the response. Verify that the value of the `status` property matches one of the values specified for the `status` query parameter.

Abstract test A.77
/conf/job-list/datetime-response
Requirement	/req/job-list/datetime-response
Test purpose	Validate that the `datetime` query parameter is processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `datetime` query parameter to the request. Inspect the value of the `created` (see: statusInfo.yaml) property for each job listed in the response. Verify that the value of the `created` temporally intersects with the value specified for the `datetime` query parameter.

Abstract test A.78
/conf/job-list/duration-response
Requirement	/req/job-list/duration-response
Test purpose	Validate that the `minDuration` and `maxDuration` query parameter are processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `minDuration` query parameter to the request. Compute the duration of each job listed in the response document as per requirements /req/job-list/status-response, E or F depending on the current status of the job. Verify that the computed duration of each job listed in the response is at least as long as the specified value of the `minDuration` query parameter. Get a list of jobs as per test /conf/job-list/job-list-op and append the `maxDuration` query parameter to the request. Compute the duration of each job listed in the response document as per requirements /req/job-list/status-response, E or F depending on the current status of the job. Verify that the computed duration of each job listed in the response is no longer than the specified value of the `maxDuration` query parameter. Get a list of jobs as per test /conf/job-list/job-list-op and append the `minDuration` and `maxDuration` query parameters to the request. Compute the duration of each job listed in the response document as per requirements /req/job-list/status-response, E or F depending on the current status of the job. Verify that the computed duration of each job listed in the response is at least as long as the specified value of the `minDuration` query parameter AND no longer than the value of the `maxDuration` query parameter.

Abstract test A.79
/conf/job-list/limit-response
Requirement	/req/job-list/limit-response
Test purpose	Validate that the `limit` query parameter is processed correctly.
Test method	Get a list of jobs as per test /conf/job-list/job-list-op and append the `limit` query parameter to the request. Count the number of jobs listed in the response. Verify that this count is not greater than the value specified by the `limit` parameter. If the API definition specifies a maximum value for `limit` parameter, verify that the count does not exceed this maximum value.

A.8. Conformance Class Callback

Conformance class A.7
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/callback
Requirements class	Requirements Class “Core”
Target type	Web API

Abstract test A.80
/conf/callback/job-callback
Requirement	/req/callback/job-callback
Test purpose	Validate the passing of a subscriber-URL in an execute request.
Test method	Configure a URL endpoint to accept message body from the server. Create an asynchronous execute request that includes the optional `subscriber` key (see execute.yaml. Execute the asynchronous job using test /conf/core/job-creation-request. Validate the job results are received by the specified callback URL.

A.9. Conformance Class Dismiss

Conformance class A.8
http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/dismiss
Requirements class	Requirements Class “Core”
Target type	Web API

Abstract test A.81
/conf/dismiss/job-dismiss-op
Requirement	/req/dismiss/job-dismiss-op
Test purpose	Validate that a running job can be dismissed.
Test method	Create an asynchronous job as per test /conf/core/job-creation-op; not the job identifier, {jobID}, assigned to the job. Issue an HTTP DELETE operation to the URL ‘/jobs/{jobID}’. Validate the contents of the returned document using test /conf/dismiss/job-dismiss-success.

Abstract test A.82
/conf/dismiss/job-dismiss-success
Requirement	/req/dismiss/job-dismiss-success
Test purpose	Validate that the content returned when dismissing a job complies with the required structure and contents.
Test method	Validate that a document was returned with an HTTP status code of 200. Validate that the status is the response is set to “dismissed”. Validate the process list content for all supported media types using the resources and tests identified in Table A.11
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 the against that schema. All supported formats should be exercised.

Table A.11 — Schema and Tests for Dismissing a Job

Format	Schema Document	Test ID
HTML	statusInfo.yaml	/conf/html/content
JSON	statusInfo.yaml	/conf/json/content

Annex B
(informative)
Revision history

Date	Release	Editor	Primary clauses modified	Description
2017-03-07	0.1	Benjamin Pross	all	initial version
2018-05-16	0.1	Stan Tillman	1-5	Update section 1-5
2018-07-25	1.0-draft	Benjamin Pross	all	1.0-draft
2018-08-15	1.0-draft	Benjamin Pross	all	Restructuring, added requirements classes
2018-11-29	1.0-draft	Benjamin Pross	7	Update schemas and examples
2019-02-20	1.0-draft	Benjamin Pross	7	Fix for #3
2019-03-21	1.0-draft	Benjamin Pross	6,7,8,9,10	Alignment with OAPI Common, adjust schemas
2019-03-27	1.0-draft	Tom Kralidis, Benjamin Pross	6,7,8,9,10	Fix for #7, align bbox schema to WFS
2019-03-28	1.0-draft	Benjamin Pross	7	Formatting
2019-03-29	1.0-draft	Benjamin Pross	7	Adjust schemas and examples
2019-04-16	1.0-draft	Benjamin Pross	7	Adjust schemas, fix validation errors, add more data types
2019-06-05	1.0-draft	Gérald Fenoy	7	Allow unbounded for maxOccurs, Fix issue with ValueDefinition references
2019-06-12	1.0-draft	Benjamin Pross	7	Possible solution for #26
2019-06-19	1.0-draft	Gérald Fenoy	7	Add additionalParameter.yaml, update metadata.yaml and, descriptionType.yaml, fix indentation
2019-06-20	1.0-draft	Brad Hards	6,7	Fix typo noted during OGC API presentation, fix for #34
2019-08-09	1.0-draft.2	Benjamin Pross	7	1.0-draft.2, use plural for results path, remove wrapper
2019-08-21	1.0-draft.2	Benjamin Pross	7	adjust schemas, examples and figures, remove section about web caching
2019-10-01	1.0-draft.3	Benjamin Pross	7	1.0-draft.3, minor edits
2019-10-10	1.0-draft.3	Gérald Fenoy, Tom Kralidis	7	Add implementations, Use status in place of infos in jobInfo definition
2019-10-22	1.0-draft.3	Benjamin Pross	7	Remove mandatory path /api, fix for #50
2020-01-06	1.0-draft.3	Francis Charette	7	Add implementation
2020-01-28	1.0-draft.3	Gérald Fenoy	7	Adjust schemas and examples
2020-02-03	1.0-draft.3	Benjamin Pross	7	Fix for #63
2020-02-18	1.0-draft.3	Chris Durbin	7	Fix for #61
2020-04-01	1.0-draft.3	Benjamin Pross	7	Add optional subscriber property to execute request, avoid duplication, create own type for entities with properties name and reference
2020-04-06	1.0-draft.3	Benjamin Pross	5,7	Abbreviate process-description link relation to process-desc, update example, alphabetical ordering of link relations
2020-04-09	1.0-draft.3	Benjamin Pross	7	Rename root.yaml to landingPage.yaml, add title and description to root.yaml
2020-04-28	1.0-draft.3	Benjamin Pross	7	Move examples, responses and parameters from core asciidoc to external files
2020-04-29	1.0-draft.3	Benjamin Pross	11	Add Requirements Class ‘Callback’
2020-04-30	1.0-draft.3	Benjamin Pross	6,11	Move overview table to abstract, allow multiple URIs for callbacks
2020-05-05	1.0-draft.3	Gérald Fenoy	12	Add Requirements Class ‘Dismiss’, fix includes and section headers
2020-05-8	1.0-draft.3	Benjamin Pross	14	Add section with info about additional/alternative building blocks
2020-05-11	1.0-draft.3	Benjamin Pross	12	Move ‘Job List’ from core to separate Requirements Class
2020-05-12	1.0-draft.3	Panagiotis (Peter) A. Vretanos	N/A	Create a home for extensions to the core, initial check in of draft transactions extension, add placeholders for the quotation and billing APIs
2020-05-12	1.0-draft.3	Stan Tillman	6,7,8,9,10	Review
2020-05-20	1.0-draft.3	Panagiotis (Peter) A. Vretanos	2,7	Separate the OGC process description into its own conformance class.
2020-07-21	1.0-draft.4	Benjamin Pross	2,6,10, Annex A	Editorial fixes, incorporated comments from Carl Reed, updated example
2020-07-23	1.0-draft.4	Benjamin Pross	7,10,11	Add dependency to API Common
2020-07-27	1.0-draft.4	Benjamin Pross	9	Add security considerations section
2020-07-30	1.0-draft.4	Benjamin Pross	7,9	Add section about HTTP and HTTPS, fix links to RFCs, add additional guidance to security considerations section
2020-08-10	1.0-draft.4	Panagiotis (Peter) A. Vretanos	all	Add ATS, adjust links throughout the document
2020-08-13	1.0-draft.4	Benjamin Pross	9	Work on security considerations section
2020-09-02	1.0-draft.4	Benjamin Pross	9	Incorporated further comments from Andreas Matheus
2020-10-08	1.0-draft.5	Benjamin Pross	All	Tag version 1.0-draft.4, continue work on version 1.0-draft.5
2020-10-22	1.0-draft.5	Benjamin Pross	Annex A	Continued to rename collection to list
2020-11-02	1.0-draft.5	Benjamin Pross	7	Fix issue #100
2020-11-13	1.0-draft.5	Benjamin Pross	7	Fix issue #103
2021-01-15	1.0-draft.5	Benjamin Pross	7, 12	Move /jobs endpoint to root level, changes in execute and result schema
2021-01-19	1.0-draft.6	Benjamin Pross	-	Set version to 1.0-draft.6-SNAPSHOT
2021-01-19	1.0-draft.6	Benjamin Pross	7	Adjust example paths
2021-01-19	1.0-draft.6	Benjamin Pross	7	Part B.x
2021-01-25	1.0-draft.6	Benjamin Pross	7	Fix issue 3
2021-01-25	1.0-draft.6	Benjamin Pross	7	Adjust links and replace WPS 2.0 SWG with OGC API — Processes SWG
2021-01-25	1.0-draft.6	Benjamin Pross	7	Fix CNR3
2021-01-25	1.0-draft.6	Benjamin Pross	7	CNR13
2021-01-25	1.0-draft.6	Benjamin Pross	7	CNR19
2021-01-25	1.0-draft.6	Benjamin Pross	7	CNR21
2021-01-25	1.0-draft.6	Benjamin Pross	7	CNR23
2021-01-25	1.0-draft.6	Benjamin Pross	7	CNR24
2021-02-01	1.0-draft.6	Benjamin Pross	7	Fixes #87
2021-02-01	1.0-draft.6	Benjamin Pross	7	Fixes #118
2021-02-02	1.0-draft.6	Benjamin Pross	7	Adjust text for additional api building blocks
2021-02-02	1.0-draft.6	Benjamin Pross	7	CNR9
2021-02-02	1.0-draft.6	Benjamin Pross	7	Replace term Web Processing Service in core
2021-02-09	1.0-draft.6	Benjamin Pross	7	CNR7, CNR14
2021-02-09	1.0-draft.6	Benjamin Pross	7	CNR8
2021-02-09	1.0-draft.6	Benjamin Pross	7	CNR25
2021-02-09	1.0-draft.6	Benjamin Pross	7	CNR20]
2021-02-09	1.0-draft.6	Benjamin Pross	7	CNR26
2021-02-22	1.0-draft.6	Benjamin Pross	7	Editorial fixes
2021-02-22	1.0-draft.6	Benjamin Pross	7	Fixes #130
2021-03-01	1.0-draft.6	Benjamin Pross	7	Adjust texts to moved execute endpoint
2021-03-08	1.0-draft.6	Gérald Fenoy	10	Fix old syntaxes in JobList example used from the file: clause_10_job_list.adoc
2021-03-08	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Modify process description to allow JSON-Schema to be used to describe inputs and outputs. As a result of this change, a lot of the current structures, boundingBoxData, complexData, literalData, etc. can all be removed since these can be adequately described using JSON-Schema.
2021-03-11	1.0-draft.6	Benjamin Pross	X	Fix issue #143
2021-03-11	1.0-draft.6	Benjamin Pross	X	Fix links
2021-03-11	1.0-draft.6	Benjamin Pross	X	Fixes #148
2021-03-11	1.0-draft.6	Benjamin Pross	X	Fix #145
2021-03-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Refine the use of JSON Schema to describe input and output process parameters.
2021-03-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update input/output description schema to convert the `inputs` and `outputs` keys in the process description from arrays to objects. Each key in the updated `inputs`/`outputs` object is the identified for the corresponding process input/output.
2021-03-19	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Merge pull request #6 from opengeospatial/master
2021-03-24	1.0-draft.6	Benjamin Pross	-	Update UML
2021-03-24	1.0-draft.6	Benjamin Pross	-	Add eap and xmi files
2021-03-28	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the ability to infinitely nest inputs.
2021-03-29	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	* Remove unnecessary schemas that can now be defined using JSON Schema and propagate those changes to the other schemas. * Update some of the indentation in the yaml files so the yamllint does not complain. * Further refine the examples. * Update the text of the specification accordingly.
2021-03-29	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Move additionalProperties from output.yaml to execute.yaml to be consistent with what was done with input.yaml.
2021-03-29	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Allow simple values to be encoded directly. So, `"key": {"value":10}` becomes `"key": 10`.
2021-03-29	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add array, in additiona to string, number & boolean, to possible direct input types.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update example to use new, more compact form for specifying simple scalar values.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	1. Make mediateType optional 2. Modify the schema tag to be a reference to a schema or be an inline JSON schema. 3. Change name of “encoding” tag to “characterEncoding” to make more clear what it means.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add missing input type array.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch merge inconsistency between issues #122, #152 and #155.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Fix some spacing issues with the yaml files.
2021-04-09	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch dangling reference in result.yaml.
2021-04-12	1.0-draft.6	Benjamin Pross	X	This should fix #142
2021-04-12	1.0-draft.6	Benjamin Pross	X	Use upper case in bullet point list
2021-04-12	1.0-draft.6	Benjamin Pross	X	Add new requirement for inputs, this should fix #129
2021-04-12	1.0-draft.6	Benjamin Pross	X	Remove id from execute JSON schema
2021-04-12	1.0-draft.6	Benjamin Pross	X	Adjust requirement to new execute endpoint
2021-04-12	1.0-draft.6	Benjamin Pross	X	Adjust examples
2021-04-12	1.0-draft.6	Benjamin Pross	X	Adjust execute endpoint in ATS
2021-04-12	1.0-draft.6	Benjamin Pross	X	Add recommendation regarding access control for the /jobs endpoint
2021-04-13	1.0-draft.6	Gérald Fenoy	X	Update execute.yaml
2021-04-13	1.0-draft.6	Gérald Fenoy	X	Update format.yaml
2021-04-13	1.0-draft.6	Gérald Fenoy	X	Create referenceData.yaml
2021-04-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch JSON schema fragments in some of the example inputs. All add a units of measure input example.
2021-04-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	A review after the merge of #122, #152 and #155 revealed an inconsistency in the input definition. Specifically the merge overwrote the change that allow direct input values (i.e. “key”: “value”). This commit fixes these inconsistencies.
2021-04-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove include path fragment that appears in clause 7. For some reason it was commented out. I uncommented it and clean up the format of the permission.
2021-04-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add some additional requirements around process inputs. Specifically an input can be specified inline or by reference. It it is specified inline than it shall conform to its schema in the process description. If by reference then a link.yaml link shall be used.
2021-04-14	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add requirements for input cardinality and for inlining or referencing input values.
2021-04-14	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add the schema for a standard bbox definition that process descriptions can reference. This was everyone can uses the same bbox definition.
2021-04-14	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update the bbox schema to enforce either 4 or 6 items (i.e. 5 is not allowed).
2021-04-14	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add a description indicating how this file can be used.
2021-04-15	1.0-draft.6	Benjamin Pross	X	Remove unnecessary oneOf
2021-04-15	1.0-draft.6	Benjamin Pross	X	Remove dash
2021-04-15	1.0-draft.6	Benjamin Pross	X	Use additionalProperties instead of patternProperties
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove observedProperty as per SWG resolution of 29MAR2021. The observedProperty is useful for certain domains but seems out of scope for the core.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove file that does not seem to be referenced anywhere.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch reference to input and output descriptions.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add an additional requirement that if a value is specified by reference then its value type must match the type or types specified in the process description. I suppose that an allOf could be used to constrain the type property of the link but that seem a bit heavy.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Rename the file name of the ATS so that it matched the requirement file name.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update the description example.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch the $ref.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Clarify the language of the requirement a bit (I think).
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Split the /req/core/job-creation-input-cardinality requirement into two requirements to make it easier to test in the ATS.
2021-04-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add tests for input cardinality handing.
2021-04-16	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Clarify the text of the requirements and the ATS about input multiplicity (i.e. issue #129).
2021-04-16	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove obsolete note.
2021-04-16	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Fix formatting.
2021-04-19	1.0-draft.6	Benjamin Pross	X	Add requirement and recommendation for testing. Should fix #157
2021-04-19	1.0-draft.6	Benjamin Pross	X	Adjust wording
2021-04-19	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	- Get rid on minOccurs/maxOccurs and rely instead on JSON Schema structures to define the cardinality of a process input. — The schema object in the process description is too generic so add three levels of JSON Schema conformance ranging from very simple to full JSON schema.
2021-04-19	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch small $ref issues.
2021-04-20	1.0-draft.6	Benjamin Pross	X	Adjust path of execution endpoint
2021-04-20	1.0-draft.6	Benjamin Pross	X	Remove unused schema, fixes #173
2021-04-20	1.0-draft.6	Benjamin Pross	X	Remove link to execute endpoint from landing page
2021-04-20	1.0-draft.6	Benjamin Pross	X	Add recommendation to add link to job monitoring endpoint to the landing page
2021-04-25	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the patternProperties key that allow JSON Schema extensions keys that begin with “x-”. Two point about this extension mechanism… (1) it breaks compatablity with swagger which is bad; (2) I can’t really think of a good reason right now that we would want to extend the syntax of JSON Schema using this mechanism and so I think removing it is OK.
2021-04-26	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	- Update ATS to handle JSON Schema compliance levels. — Update examples to add a multi-type feature collection input. — Add a general inline value structure (qualifiedValue.yaml) that allows selection of a specified input type of a multi-type input.
2021-04-26	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove duplicate facet definitions.
2021-04-29	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the various schema levels and only support the full OpenApi 3.0 compatible version of JSON Schema (formerly called schemaLevel3.yaml).
2021-05-03	1.0-draft.6	Benjamin Pross	X	Merge pull request #172 from pvretano/issue-170
2021-05-03	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch invalid references the schemaFull.yaml/schemaLevel3.yaml. All should be references to schema.yaml.
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Fix typo
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Use relative urls.
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Ue correct reference for bbox
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Fix typo
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Few typo
2021-05-05	1.0-draft.6	Gérald Fenoy	X	Fix typo
2021-05-06	1.0-draft.6	Gérald Fenoy	X	Remove link.yaml references when schema.yaml is already referenced.
2021-05-06	1.0-draft.6	Gérald Fenoy	X	Get back enum items, default and, example.
2021-05-06	1.0-draft.6	Gérald Fenoy	X	Keep only items.
2021-05-06	1.0-draft.6	Gérald Fenoy	X	Fix typo
2021-05-06	1.0-draft.6	Gérald Fenoy	X	Go bak
2021-05-06	1.0-draft.6	Ubuntu	X	Make Swagger-UI working again and the api able to validate.
2021-05-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the concept of Level 0,1,2,3 JSON schema and simply use what was called Level 3 which is the full JSON Schema.
2021-05-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Make the mode on execute options with the default being specified in the process description.
2021-05-10	1.0-draft.6	Ubuntu	X	Remove uneeded yaml file.
2021-05-11	1.0-draft.6	Ubuntu	X	Get the not, allOf, oneOf, anyOf, items and contentSchema available in the meta-schema.
2021-05-11	1.0-draft.6	Gérald Fenoy	X	Reset example despite warnings messages.
2021-05-11	1.0-draft.6	Gérald Fenoy	X	Reset additionalProperties in schema.yaml
2021-05-11	1.0-draft.6	Gérald Fenoy	X	Fix indentation
2021-05-11	1.0-draft.6	Gérald Fenoy	X	Reset properties/additionalProperties
2021-05-11	1.0-draft.6	Gérald Fenoy	X	Remove schema.yaml references from schema.yaml
2021-05-11	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add optional date-time fields that track milestones in the lifecycle of a job.
2021-05-11	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Fix small inconsistencies in the sequence diagrams.
2021-05-11	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Make sure result/results is consistently applied everywhere. The schemas and the resource endpoints should be ‘results’ (plural).
2021-05-12	1.0-draft.6	Gérald Fenoy	X	Fix typo in example definition for ProcessDescription
2021-05-12	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Clarify some requirements that where flagged as ambiguous in issue 178.
2021-05-13	1.0-draft.6	Gérald Fenoy	X	Add schema_swagger.yaml for a minimal schema definition to be used from swagger-ui and schema.yaml for the full featured schema.
2021-05-14	1.0-draft.6	Gérald Fenoy	X	Add swagger relevant files for giving the opportunity to use the schema_swagger.yaml finally and be able to using your API from swagger-ui
2021-05-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the ambiguity introduced by allowing process input values to be any object type. If the process input schema is similar to one of the builtin schemas (link.yaml, qualifiedValue.yaml, etc.) a server may not be able ti disambiguate the input intent.
2021-05-18	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update Execute.json
2021-05-18	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update Result.json
2021-05-19	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Clarify the behavior for all the combinations of mode/response/transmissionMode/# of outputs.
2021-05-19	1.0-draft.6	Panagiotis (Peter) A. Vretanos	Annex A	Align ATS with all the changes made for issue #178.
2021-05-20	1.0-draft.6	Panagiotis (Peter) A. Vretanos	7	Update clause_7_core.adoc
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Change the job status “completed” to “successful”. The job status “completed” is not a value status.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Change the job status “completed” to “successful”. The job status “completed” is not a valid job status.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update exception reporting to align with common which uses RFC 7807.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add OpenAPI example. I following the pattern used in OGG API Features for the example OpenAPI files found there.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Simplify the response tables, for sync and async execution, by collapsing similarly responding paths into fewer rows.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update the exception status codes referenced in the ATS to be the URIs defined as a result of RFC 7807.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Clarify that server must implement support for both in-line process input values and process input values specified by reference.
2021-05-22	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add abstract tests for verifying that a server can handle inputs by value and by reference.
2021-05-25	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Refactor the schemas execute.yaml, inlineOrRefData.yaml and qualifiedValue.yaml to better emphasize the validation relationship between the definition of a process input in the process description and an process input value in an execute request. This, of course, cascaded into a whole bunch of other related clarifications.
2021-05-25	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Lint all the yaml and json files.
2021-05-26	1.0-draft.6	Benjamin Pross	X	Add Panagiotis (Peter) A. Vretanos as editor
2021-05-26	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Move bbox.yaml from inlineOrRefData.yaml to inputValue.yaml so that it is also a validation target.
2021-05-26	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	The intent was to add bbox.yaml to inputValueNoObject.yaml but not inputValue.yaml.
2021-05-26	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove references to the now obsolete Level 0, Level 1, etc. schema conformance classes.
2021-05-28	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove the mode parameter and instead rely on the HTTP Prefer header and defined default execution mode behavior.
2021-05-28	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add a recommendation to included the Preference-Applied header in the response if the request was accompanied with the HTTP Prefer header.
2021-06-02	1.0-draft.6	Jerome St-Louis	i. Abstract	Fixed mismatched sections in i. Abstract
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Initial integration of files require for use with swagger-ui
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix path for reference.yaml file
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix typos in process and exception. Try fixing the example ProcessDescription.
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Replace tabs with spaces, fix URLs for geometryGeoJSON schema which is available in yaml, add nullable and remove
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Replace tabs with spaces.
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Move ref to binaryInputValue.yaml from inlineOrRefData.yaml to inputValueNoObject.yaml
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix use of externalValue
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix 2 use of externalValue
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Try fixing issue with example ProcessDescription
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix issue with binaryInputValue.yaml
2021-06-03	1.0-draft.6	Gérald Fenoy	X	General fix in ogcapi-process-1.yaml. Fix responses/Results to use relative path.
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Small fix in path.
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Try fixing issue with ProcessDescription example
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Try fixing issue with ProcessDescription example using allOf for value
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Try fixing issue with ProcessDescription example using basic object and a ref
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Fix the ProcessDescription example issue by using externalValue
2021-06-03	1.0-draft.6	Gérald Fenoy	X	Add the Preference-Applied header information’s.
2021-06-08	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Path invalid reference to component file.
2021-06-08	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Patch type that is preventing swagger validation of example OpenAPI file.
2021-06-08	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	(1) Remove the consolidated building blocks YAML file. (2) Update the example OpenAPI definition file to reference each component individually from its corresponding schema file instead of referencing the component from the now-deleted building blocks YAML file.
2021-06-09	1.0-draft.6	Steve McDaniel	X	Indentation issue in process.yaml, outputs should be at the same level as inputs
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	7	Minor typo.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add missing default value for `response` parameter. Should be `raw`.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add an informative statement about the default value for the `response` parameters. This is normatively defined in the schema.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update server URL to point to the correct endpoint.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Fix invalid reference to transmissionMode=ref. Should be reference.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Make explicit the fact that omitting the “outputs” parameter in an execute request means that all defined outputs are being requested.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove file to conform to ATS file name pattern.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Update all OAPIR-specific link relations to use the pattern http://www.opengis.net/def/rel/ogc/1.0/{rel}. Eventually there will be registered with the OGC-NA.
2021-06-10	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove unused link relation.
2021-06-11	1.0-draft.6	Jerome St-Louis	X	results.yaml: Removed array (#219)
2021-06-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add a light-weight query capability to the jobs list. Add paging to the jobs list. Add paging to the process list.
2021-06-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add requirements and abstract tests to handle the case where the negotiated execution mode is sync or async, the response mode is raw, more than one output is requested and a mix of transmission modes (value or reference) are requested.
2021-06-13	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add requirements and abstract tests to handle the case where the negotiated execution mode is sync or async, the requested response is raw, more that 1 output is requested and a mix of transmission modes (value or reference) are requested.
2021-06-14	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Change “processList” to “processes” and “jobsList” to “jobs” so that the key name matches the resource endpoint name.
2021-06-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Remove default value for job control options. In the OGC process description the supported execution modes must be explicitly listed so there is no need for a default.
2021-06-15	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Add the contentMediaType facet to the GeoJSON feature collection inputs/outputs. Although this is not strictly necessary is makes parsing and interpreting the input/output easier.
2021-06-16	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Rel value should be ‘job-list’ not ‘jobs-list’.
2021-06-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Extend the list of “format” values to provide semantic hints inputs and outputs.
2021-06-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Reword requirement for clarity.
2021-06-17	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Fix missing allOf[] in one of the examples outputs.
2021-06-18	1.0-draft.6	Panagiotis (Peter) A. Vretanos	X	Oopsie! Forgot to make processID mandatory if the server supports the Job List conformance class.
2021-06-18	1.0-draft.7	Benjamin Pross	X	Adjust version
2021-06-22	1.0-draft.7	Panagiotis (Peter) A. Vretanos	X	Housekeeping.
2021-06-28	1.0-draft.7	Benjamin Pross	X	Merge pull request #235 from pvretano/housekeeping
2021-07-05	1.0-draft.7	Benjamin Pross	X	Revert “Adjust version”
2021-07-21	1.0-draft.7	Gérald Fenoy	X	Small fix about parameters
2021-07-21	1.0-draft.7	Gérald Fenoy	X	Fix title headers
2021-07-21	1.0-draft.7	Gérald Fenoy	-	Update clause_0_front_material.adoc
2021-07-28	1.0-draft.7	Benjamin Pross	12	Fix issue with empty chapter 12
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Add enum to status.yaml
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Add statuses.yaml in schema
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Delete statuses.yaml
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Create status.yaml
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Add status.yaml
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Try using status.yaml reference
2021-08-06	1.0-draft.7	Gérald Fenoy	X	Revert changes
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Update status.yaml
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Update statusInfo.yaml
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Rename status.yaml to statusCode.yaml
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Update status.yaml
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Update statusInfo.yaml
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Rename processId.yaml and processid.yaml to processIdPathParam.yaml and processIdQueryParam.yaml respectively
2021-08-09	1.0-draft.7	Gérald Fenoy	X	Add missing parameters to OpenAPI example
2021-08-19	1.0-draft.7	Gérald Fenoy	X	Add process value
2021-08-23	1.0-draft.7	Gérald Fenoy	X	Set format to date-time for more clarity
2021-08-23	1.0-draft.7	Gérald Fenoy	X	Update datetime.yaml
2021-08-24	1.0-draft.7	Benjamin Pross	X	Use HTTP GET method (instead of operation) throughout the document
2021-08-25	1.0-draft.7	Benjamin Pross	X	Add informative texts
2021-08-25	1.0-draft.7	Benjamin Pross	X	Merge branch ‘comments-emmanuel-devys’ into comments-amy-youmans
2021-08-25	1.0-draft.7	Benjamin Pross	X	Fix ordering of requirements
2021-08-26	1.0-draft.7	Benjamin Pross	7	Revert changes — replace GET method with GET operation
2021-09-03	1.0-draft.7	Benjamin Pross	7	Add informative text about execution paths

Bibliography

[1] Panagiotis (Peter) A. Vretanos: OGC 09-025r2, OGC® Web Feature Service 2.0 Interface Standard — With Corrigendum. Open Geospatial Consortium (2014). http://docs.opengeospatial.org/is/09-025r2/09-025r2.html

[2] Andreas Matheus: OGC 15-022, OGC® Testbed 11 Engineering Report: Implementing Common Security Across the OGC Suite of Service Standards. Open Geospatial Consortium (2015). https://portal.ogc.org/files/?artifact_id=63312

[3] Hutton, B.: JSON Schema: A Media Type for Describing JSON Documents, https://json-schema.org/draft/2020-12/json-schema-core.html

[4] Hutton, B.: JSON Schema Validation: A Vocabulary for Structural Validation of JSON, https://json-schema.org/draft/2020-12/json-schema-validation.html

[5] https://www.w3.org/TR/html5/

[6] Open API Initiative. OpenAPI Specification 3.0.2. Available at: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md.

Requirement 23
/req/core/process-execute-input-inline-bbox
Servers SHALL support process input values that conform to the bbox.yaml schema.

Permission 6
/per/core/process-execute-input-inline-bbox
Servers MAY copy the contents of bbox.yaml into another file and adjust the `default` and `enum` values are required.

Permission 7
/per/core/process-execute-sync-job
Servers MAY support the creation of a job for synchronously executed processes.

Requirement 39
/req/core/job-results-async-raw-value-one
The server SHALL response as per requirement /req/core/process-execute-sync-raw-value-one.

Requirement 40
/req/core/job-results-async-raw-value-multi
The server SHALL respond as per requirement /req/core/process-execute-sync-raw-value-multi.

Requirement 47
/req/ogc-process-description/json-encoding
A JSON-encoded OGC process description SHALL validate against the JSON Schema: process.yaml.

Recommendation 18
/rec/ogc-process-description/format-short-code
In addition to the key values listed in Table 13, servers SHOULD also accept the short codes.

Recommendation 19
/rec/ogc-process-description/format-value-registration
Servers wishing to extend this list of `format` key values, SHOULD officially register such values with the OGC Naming Authority.

Requirement 56
/req/html/definition
Every `200`-response of an operation of the server SHALL support the media type `text/html`.

Requirement 59
/req/oas30/oas-definition-2
The JSON representation SHALL conform to the OpenAPI Specification, version 3.0.

Requirement 60
/req/oas30/oas-impl
The server SHALL implement all capabilities specified in the OpenAPI definition.

Requirement 62
/req/oas30/exceptions-codes
For error situations that originate from the server, the API definition SHALL cover all applicable HTTP Status Codes.

Requirement 63
/req/oas30/security
For cases, where the operations of the server are access-controlled, the security scheme(s) SHALL be documented in the OpenAPI definition.

Requirement 67
/req/job-list/processID-mandatory
A	If the server supports this conformance class, the optional `processID` property in the statusInfo.yaml schema SHALL be mandatory.

Permission 8
/per/job-list/limit-default-minimum-maximum
A	The values for `minimum`, `maximum` and `default` in requirement `/req/job-list/limit-definition` are only examples and MAY be changed.

Permission 9
/per/job-list/limit-response
A	The server MAY return fewer jobs than requested (but not more).

Recommendation 21
/rec/job-list/next-1
A	A `200`-response SHOULD include a link to the next page (relation: `next`) of jobs, if more jobs have been selected than returned in the response.

Recommendation 22
/rec/job-list/next-2
A	Dereferencing a next page link (relation: `next`) SHOULD return additional jobs from the set of selected jobs that have not yet been returned.

Requirement 81
/req/dismiss/job-dismiss-op
The server SHALL support the HTTP DELETE operation at the path `/jobs/{jobID}`.

License Agreement

I. Abstract

II. Keywords

III. Security Considerations

III.A. Operations using HTTP GET

III.B. Execute operation

III.C. Dismiss operation

IV. Submitting Organizations

V. Submitters

1. Scope

2. Conformance

3. Normative references

4. Terms, definitions and abbreviated terms

4.1. Terms and definitions

4.1.1. process

4.1.2. job

4.1.3. JSON

4.1.4. Link

4.1.5. Link header

4.1.6. process description

4.1.7. process execution

4.1.8. process input

4.1.9. process offering

4.1.10. process output

4.1.11. REST

4.2. Abbreviated terms

5. Conventions

5.1. Identifiers

5.2. Link relations

5.3. Use of HTTPS

5.4. HTTP URIs

6. Overview

6.1. Encodings

7. Requirements Class “Core”

7.1. Overview

7.2. Retrieve the API landing page

7.2.1. Operation

7.2.2. Response

7.2.3. Error situations

7.3. Retrieve an API definition

7.3.1. Operation

7.3.2. Response

7.3.3. Error situations

7.4. Declaration of conformance classes

7.4.1. Operation

7.4.2. Response

7.4.3. Error situations

7.5. Use of HTTP 1.1

7.5.1. HTTP status codes

7.6. Support for cross-origin requests

7.7. Limit parameter

7.8. Link headers

7.9. Retrieve a process list

7.9.1. Operation

7.9.1.1. Process list

7.9.1.2. Parameter limit

7.9.2. Response

7.9.3. Error situations

7.10. Retrieve a process description

7.10.1. Operation

7.10.2. Response

7.10.3. Error situations

7.11. Execute a process

7.11.1. Operation

7.11.2. Request body

7.11.2.1. Content schema

7.11.2.2. Process inputs

7.11.2.3. Execution mode

7.11.2.4. Response type

7.11.2.5. Process outputs

7.11.3. Example

7.11.4. Response

7.11.5. Error situations

7.12. Retrieve status information about a job

7.12.1. Operation

7.12.2. Response

7.12.3. Error situations

7.13. Retrieve job results

7.13.1. Operation

7.13.2. Response

7.9.1.2. Parameter `limit`

11.2.2. Parameter `type`

11.2.3. Parameter `processID`

11.2.4. Parameter `status`

11.2.5. Parameter `datetime`

11.2.6. Parameter `minDuration`, `maxDuration`

11.2.7. Parameter `limit`

Annex A
(normative)
Abstract Test Suite

Annex B
(informative)
Revision history