From 3cd54af60cd7fede3fc9647aa39c5fbeddd219f0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=A9rald=20Fenoy?= Date: Thu, 14 Nov 2024 15:47:02 +0100 Subject: [PATCH 1/3] Rename endopint from /run to /prov (closes #464) Add headers array containing the specific headers used to create the job --- .../job_management/standard/._24-051.html | Bin 0 -> 4096 bytes .../job_management/standard/24-051.err.html | 757 ++++++ .../job_management/standard/24-051.html | 2386 +++++++++++++++++ .../job_management/standard/24-051.pdf.err | 241 ++ .../standard/24-051.presentation.xml | 1800 +++++++++++++ extensions/job_management/standard/24-051.xml | 923 +++++++ .../PER_content-negotiation.adoc | 0 .../provenance/prov/REQ_get-op.adoc | 8 + .../{run => prov}/REQ_response.adoc | 4 +- .../provenance/run/REQ_get-op.adoc | 8 - .../sections/clause_9_provenance.adoc | 10 +- openapi/paths/processes-dru/pDeploy.yaml | 2 + .../pProcessDescriptionReplaceUndeploy.yaml | 2 + .../processes-dru/pProcessListDeploy.yaml | 2 + openapi/paths/processes-dru/pReplace.yaml | 2 + .../processes-job-management/headers.yaml | 3 + .../processes-job-management/inputs.yaml | 4 + 17 files changed, 6137 insertions(+), 15 deletions(-) create mode 100755 extensions/job_management/standard/._24-051.html create mode 100644 extensions/job_management/standard/24-051.err.html create mode 100644 extensions/job_management/standard/24-051.html create mode 100644 extensions/job_management/standard/24-051.pdf.err create mode 100644 extensions/job_management/standard/24-051.presentation.xml create mode 100644 extensions/job_management/standard/24-051.xml rename extensions/job_management/standard/recommendations/provenance/{run => prov}/PER_content-negotiation.adoc (100%) create mode 100644 extensions/job_management/standard/requirements/provenance/prov/REQ_get-op.adoc rename extensions/job_management/standard/requirements/provenance/{run => prov}/REQ_response.adoc (86%) delete mode 100644 extensions/job_management/standard/requirements/provenance/run/REQ_get-op.adoc create mode 100644 openapi/schemas/processes-job-management/headers.yaml diff --git a/extensions/job_management/standard/._24-051.html b/extensions/job_management/standard/._24-051.html new file mode 100755 index 0000000000000000000000000000000000000000..972984c4aff1959ab793f1015850656f34fa522c GIT binary patch literal 4096 zcmZQz6=P>$Vqox1Ojhs@R)|o50+1L3ClDJkFz{^v(m+1nBL)UWIUt(=a103vf+zv$ zU|0ae0uVl&WCXGn05MQpDmgz_FR`E?Csi*evACqPI5j0Du_RSFAQ+_j#%I%X5G{Lh ziz2B>oSaI9oYb@ug`}Lsylh}!7^-VXQ>gxjdqsvp H?*D%Pu^}oY literal 0 HcmV?d00001 diff --git a/extensions/job_management/standard/24-051.err.html b/extensions/job_management/standard/24-051.err.html new file mode 100644 index 00000000..7516e5aa --- /dev/null +++ b/extensions/job_management/standard/24-051.err.html @@ -0,0 +1,757 @@ +extensions/job_management/standard/24-051.err.html errors + + +

extensions/job_management/standard/24-051.err.html errors

+ +

AsciiDoc Input

+ + + + + + + +
LineIDMessageContextSeverity
_​referencesno anchor on reference, markup may be malformed: seehttps://​www.​metanorma.org/​author/topics/​sections/​bibliography/ ,https://​www.​metanorma.org/​author/iso/​topics/​markup/​#bibliographies +: ​ Bryan, P., Nottingham, M.: IETF RFC 6902, ​JavaScript Object Notation (JSON) Patch, 2013 
#<Asciidoctor::List@8460 {context: :ulist, style: "bibliography", items: 5}>
1
+

Relaton

+ + + + + + + + + + + + + + + + + + + + + + + + + +
LineIDMessageContextSeverity
--Downloaded index from https://​raw.​githubusercontent.com/​relaton/​relaton-data-ogc/main/​index-v1.zip
3
OGC 17-069r3Found: 17-069r3
3
OGC 18-062Found: 18-062r2
3
OGC 20-044Not found.
3
OGC 21-009Not found.
3
OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2 does not have a recognised prefix
3
OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2 does not have a recognised prefix
3

+
Anchors

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
000066_56b07a2e-6f5d-ebf5-a3bd-15a3e1e35665Crossreference target rc_job-management is undefined
<xref target="rc_job-management">Job Management</xref>
1
000086_86bead28-60b4-0781-cecf-c858aa93826fCrossreference target rc_​provenance is undefined
<xref target="rc_provenance">Provenance</xref>
1
000275rc_job-mangementCrossreference target rfc2616 is undefined
<xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref>
1
000593_d9bc2000-cc20-5230-6108-e910ec6796b9Crossreference target rfc2616 is undefined
<xref target="rfc2616">HTTP 1.1</xref>
1
000773_a35f98ae-79c4-cabf-4b34-7df10f32509eCrossreference target deploy-replace-undeploy-http_​status_codes is undefined
<xref target="deploy-replace-undeploy-http_status_codes">HTTP status codes</xref>
1
000800rc_ogcapi-processesCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref>
1
000904rc_openeoCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref>
1
001168ats_jmCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref>
1

+
Style

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
--Preface is missing!
2
000001_​misccontainer_​anchor_aliasesTable should have title
<table id="_misccontainer_anchor_aliases">
+  <tbody>
+    <tr>
+      <th>ats_jm</th>
+      <td>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</td>
2
000034_d723ae37-c7be-e4a9-a3fc-86ffc4a83cb9Table should have title
<table id="_d723ae37-c7be-e4a9-a3fc-86ffc4a83cb9" unnumbered="true"> <thead> <tr> <th valign="middle" align="left">Name</th>
+<th valign="middle" align="left">Affiliation</th>
+</tr> </thead>
+<tbody> <tr> <td valign="middle" align="left">Gérald Fenoy <em>(editor)</em> </td>
+<td valign="middle" align="left">GeoLabs</td>
2
000260job-managementHanging paragraph in clause
<clause id="job-management" obligation="normative">
+<title>Overview</title>
+<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
+</requirement>
+
2
000569_overview_​2Hanging paragraph in clause
<clause id="_overview_2" obligation="normative">
+<title>Overview</title>
+<requirement id="req_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-body</value> </classification> <component class="part"> <p id="_05adf478-66b0-bb00-4ff1-d41511e77fcf">The body of a PATCH request SHALL be in JSON format.</p>
+</component>
+</requirement>
2
000728job-management-definitionHanging paragraph in clause
<clause id="job-management-definition" obligation="normative">
+<title>Job definition</title>
+<p id="_d7f18ae5-2f90-1fb8-76fe-9621df1a7334">For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.</p>
+
+<clause id="_operation_4" obligation="normative">
2
001029_inputsHanging paragraph in clause
<clause id="_inputs" obligation="normative">
+<title>Inputs</title>
+<p id="_7b70acb8-1919-5d25-4608-cf6095ab5153">The server MUST provide an endpoint to retrieve the inputs of a job run.</p>
+
+<clause id="_operation_5" obligation="normative">
2
001064_provHanging paragraph in clause
<clause id="_prov" obligation="normative">
+<title>Prov</title>
+<p id="_21c472f6-0653-e0a5-bccf-680806aac136">The server MUST provide an endpoint to retrieve the provenance of a job.</p>
+
+<clause id="_operation_6" obligation="normative">
2
001160_​conformance_class_​job_​managementHanging paragraph in clause
<clause id="_conformance_class_job_management" obligation="normative">
+<title>Conformance Class Job Management</title>
+<requirement id="ats_jm" model="ogc" type="conformanceclass">
+<title>Job Management</title> <identifier>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</identifier> <subject> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref> </subject> <classification> <tag>Target Type</tag> <value>Web API</value> </classification> <requirement id="_a86d877f-b639-4c33-aaf0-aafbda999bc2" model="ogc" type="verification"> <identifier>/conf/dru/deploy/post-op</identifier> </requirement>
+
2
001207_1af3e526-b98d-61df-00c5-7c89dc3c51a2Table should have title
<table id="_1af3e526-b98d-61df-00c5-7c89dc3c51a2" unnumbered="true"> <colgroup> <col width="12%"/> <col width="18%"/> <col width="12%"/> <col width="12%"/> <col width="46%"/> </colgroup> <thead> <tr> <th valign="middle" align="left">Date</th>
+<th valign="middle" align="left">Release</th>
+<th valign="middle" align="left">Editor</th>
+<th valign="middle" align="left">Primary clauses modified</th>
+<th valign="middle" align="left">Description</th>
2

+
Requirements

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
000262rc_job-mangementProvision rc_job-mangement points to Prerequisite OGC API — ​Processes — ​Part 1: Core, Conformance Class ‘core’ outside this document
+
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
+</requirement>
2
000262rc_job-mangementProvision rc_job-mangement points to Prerequisite RFC 2616 (HTTP/​1.1) outside this document
+
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
+</requirement>
2
000262rc_job-mangementRequirement class rc_job-mangement has no corresponding Conformance class
+
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
+</requirement>
2
000262rc_job-mangementRequirement class rc_job-mangement has no corresponding Requirement
+
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
+</requirement>
2
000350per_job-management_​additional-status-codesRequirement per_job-management_​additional-status-codes has no corresponding Conformance test
+
<permission id="per_job-management_additional-status-codes" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/additional-status-codes</value> </classification> <component class="part"> <p id="_68f9b4b5-98ba-065b-7473-169909f0c800">Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in <xref target="status_codes"/>.</p>
+</component>
+</permission>
2
000390req_job-management_create_​post-opRequirement req_job-management_create_​post-op has no corresponding Conformance test
+
<requirement id="req_job-management_create_post-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-post-op</value> </classification> <component class="part"> <p id="_59b20392-f885-485f-3d60-60874d0e69c5">The server SHALL support the HTTP POST operation at the path <tt>/jobs</tt>.</p>
+</component>
+</requirement>
2
000404req_job-management_create_​bodyRequirement req_job-management_create_​body has no corresponding Conformance test
+
<requirement id="req_job-management_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-body</value> </classification> <component class="part"> <p id="_9eada9e6-11fc-b695-6cab-cd3860462ebb">The body of the POST request SHALL be in JSON format.</p>
+</component>
+</requirement>
2
000413per_job-management_create_​bodyRequirement per_job-management_create_​body has no corresponding Conformance test
+
<permission id="per_job-management_create_body" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/create-body</value> </classification> <component class="part"> <p id="_56fcb431-af59-80f5-2c2b-8557db1c1155">A server MAY support any encoding in the body of a HTTP POST operation.</p>
+</component>
+</permission>
2
000422req_job-management_create_​content-typeRequirement req_job-management_create_​content-type has no corresponding Conformance test
+
<requirement id="req_job-management_create_content-type" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-content-type</value> </classification> <component class="part"> <p id="_9d144068-d98a-2172-3d82-11ea53de687b">The <tt>Content-Type</tt> <link target="https://tools.ietf.org/html/rfc2616#section-14.17">header</link> SHALL be used to declare the media type of the request.</p>
+</component>
+</requirement>
2
000433per_job-management_create_​content-schemaRequirement per_job-management_create_​content-schema has no corresponding Conformance test
+
<permission id="per_job-management_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/create-content-schema</value> </classification> <component class="part"> <p id="_ea06a074-ff10-1347-6037-03ec924d5517">The <tt>Content-Schema</tt> header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.</p>
+</component>
+</permission>
2
000445rec_job-management_create_​body-ogcapi-processesRequirement rec_job-management_create_​body-ogcapi-processes has no corresponding Conformance test
+
<recommendation id="rec_job-management_create_body-ogcapi-processes" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/create-body-ogcapi-processes</value> </classification> <component class="part"> <p id="_21e4c515-b1ec-6e86-8d1e-c9d2bbe0e2da">If the job can be encoded as an <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref>, implementation SHOULD consider supporting the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref> encoding.</p>
+</component>
+</recommendation>
2
000457rec_job-management_create_​body-openeoRequirement rec_job-management_create_​body-openeo has no corresponding Conformance test
+
<recommendation id="rec_job-management_create_body-openeo" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/create-body-openeo</value> </classification> <component class="part"> <p id="_b40d2102-36ca-1186-ee28-472de8b30d16">If the job can be encoded as an <xref target="rc_openeo">OpenEO graph</xref>, implementation SHOULD consider supporting the <xref target="rc_openeo">OpenEO graph</xref> encoding.</p>
+</component>
+</recommendation>
2
000470req_job-management_create_​response-jobidRequirement req_job-management_create_​response-jobid has no corresponding Conformance test
+
<requirement id="req_job-management_create_response-jobid" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-jobid</value> </classification> <component class="part"> <p id="_120716a1-2fcd-aefe-f0e8-260f528fa15c">If the operation completes, the server SHALL generate a job identifier (i.e. <tt>{jobId}</tt>) for the created job.</p>
+</component>
+</requirement>
2
000479req_job-management_create_​response_​successRequirement req_job-management_create_​response_​success has no corresponding Conformance test
+
<requirement id="req_job-management_create_response_success" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-success</value> </classification> <component class="part"> <p id="_217f3c95-ce68-0151-7b40-f5ae2f400e4b">A successful execution of the operation SHALL be reported as a response with a HTTP status code <tt>201</tt>.</p>
+</component> <component class="part"> <p id="_8aefb5a1-d845-7e7f-a696-fc8565fef146">A response with HTTP status code <tt>201</tt> SHALL include a <tt>Location</tt> header with the URI of the deployed processes (path: <tt>/jobs/{jobId}</tt>).</p>
+</component>
+</requirement>
2
000491req_job-management_create_​response-bodyRequirement req_job-management_create_​response-body has no corresponding Conformance test
+
<requirement id="req_job-management_create_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-body</value> </classification> <component class="part"> <p id="_a717cdef-e9c0-0893-8e0d-d666c5dc5907">The response SHALL include a body that contains a status information of the created job that conforms to the <link target="https://schemas.opengis.net/ogcapi/processes/part1/1.0/openapi/schemas/statusInfo.yaml">statusInfo.yaml</link> schema.</p>
+</component> <component class="part"> <p id="_9d1820bb-ee5b-fabc-cd9e-80282886dfd2">The response SHALL contain a <tt>created</tt> status code and the <tt>id</tt> property that contains the job identifier.</p>
+</component>
+</requirement>
2
000510req_job-management_create_​unsupported-schemaRequirement req_job-management_create_​unsupported-schema has no corresponding Conformance test
+
<requirement id="req_job-management_create_unsupported-schema" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-unsupported-schema</value> </classification> <component class="part"> <p id="_fe235e0b-0a77-20de-482a-ce15ddb12610">If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be <tt>422 Unprocessable Content</tt>.</p>
+</component> <component class="part"> <p id="_ecff7330-b3f6-6298-e8d7-0b81c63d4f1d">The content of that response SHALL be based upon the OpenAPI 3.0 schema  <link target="https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/exception.yaml">exception.yaml</link>.</p>
+</component> <component class="part"> <p id="_58f15e2f-0f8e-04e1-fdc1-79fe389ddd90">The <tt>type</tt> of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.</p>
+</component>
+</requirement>
2
000552req_job-management_update_​patch-opRequirement req_job-management_update_​patch-op has no corresponding Conformance test
+
<requirement id="req_job-management_update_patch-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-patch-op</value> </classification> <component class="part"> <p id="_5765e160-3b4b-f86d-3d8f-d13f8c23e7d9">For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.</p>
+</component> <component class="part"> <p id="_b7d85a9c-dff1-a81c-cbea-6e16b88a44df">The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
+</component>
+</requirement>
2
000571req_job-management_update_​bodyRequirement req_job-management_update_​body has no corresponding Conformance test
+
<requirement id="req_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-body</value> </classification> <component class="part"> <p id="_05adf478-66b0-bb00-4ff1-d41511e77fcf">The body of a PATCH request SHALL be in JSON format.</p>
+</component>
+</requirement>
2
000580per_job-management_update_​bodyRequirement per_job-management_update_​body has no corresponding Conformance test
+
<permission id="per_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/update-body</value> </classification> <component class="part"> <p id="_d716a117-40e2-ac55-f5bc-c9af59d8fbe6">A server MAY support any encoding in the body of a HTTP PATCH operation.</p>
+</component>
+</permission>
2
000589req_job-management_update_​content-typeRequirement req_job-management_update_​content-type has no corresponding Conformance test
+
<requirement id="req_job-management_update_content-type" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-content-type</value> </classification> <component class="part"> <p id="_d9bc2000-cc20-5230-6108-e910ec6796b9">As per <xref target="rfc2616">HTTP 1.1</xref> (<link target="https://tools.ietf.org/html/rfc2616#section-14.17"/>) the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.</p>
+</component>
+</requirement>
2
000598per_job-management_update_​content-schemaRequirement per_job-management_update_​content-schema has no corresponding Conformance test
+
<permission id="per_job-management_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/update-content-schema</value> </classification> <component class="part"> <p id="_16d37cee-0841-4288-ca0d-8cd4672121c9">The <tt>Content-Schema</tt> header MAY be used to indicate the schema of a request body for updating a job.</p>
+</component>
+</permission>
2
000609rec_job-management_update-ogcapi-processesRequirement rec_job-management_update-ogcapi-processes has no corresponding Conformance test
+
<recommendation id="rec_job-management_update-ogcapi-processes" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/update-body-ogcapi-processes</value> </classification> <component class="part"> <p id="_67a207fd-d9a2-a735-bc26-54a4bf15ab28">If a job can be created from an <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref>, implementations SHOULD consider supporting the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref> encoding.</p>
+</component>
+</recommendation>
2
000621rec_job-management_update-openeoRequirement rec_job-management_update-openeo has no corresponding Conformance test
+
<recommendation id="rec_job-management_update-openeo" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/update-body-openeo</value> </classification> <component class="part"> <p id="_16a2a097-005c-3bef-61a6-62474908c4e4">If a job can be created from an <xref target="rc_openeo">OpenEO Process Graph</xref>, implementations SHOULD consider supporting the <xref target="rc_openeo">OpenEO Process Graph</xref> encoding.</p>
+</component>
+</recommendation>
2
000634req_job-management_update_​responseRequirement req_job-management_update_​response has no corresponding Conformance test
+
<requirement id="req_job-management_update_response" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-response</value> </classification> <component class="part"> <p id="_f4007821-8d26-0559-e45b-b6385e13a710">A successful execution of the operation SHALL be reported as a response with a HTTP status code <tt>200</tt> or <tt>204</tt>.</p>
+</component>
+</requirement>
2
000654req_job-management_update_​response-lockedRequirement req_job-management_update_​response-locked has no corresponding Conformance test
+
<requirement id="req_job-management_update_response-locked" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-response-locked</value> </classification> <component class="part"> <p id="_849aaff6-e15c-b002-5fb2-b358cbb7227b">If a job is locked, meaning that it is currently being processed (status set to <tt>accepted</tt> or <tt>running</tt>), the server SHALL respond with HTTP status code <tt>423 Locked</tt>.</p>
+</component> <component class="part"> <p id="_11452159-22bd-60f4-4530-ed85f966408d">The response body SHALL be based upon the OpenAPI 3.0 schema <link target="https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/exception.yaml">exception.yaml</link>.</p>
+</component> <component class="part"> <p id="_18e34c4f-05f1-8950-9559-26a3f570c035">The <tt>type</tt> of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.</p>
+</component>
+</requirement>
2
000690req_job-management_start_​post-opRequirement req_job-management_start_​post-op has no corresponding Conformance test
+
<requirement id="req_job-management_start_post-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/start-post-op</value> </classification> <component class="part"> <p id="_a93fd6ec-bfcc-87d0-2e65-50946f1dfa25">For every created jobs (path: <tt>/jobs/{jobId}/results</tt>), the server SHALL support the HTTP POST operation.</p>
+</component> <component class="part"> <p id="_8436153b-6dc8-bea6-a88a-620e448adf62">The parameter <tt>jobId</tt> is each <tt>jobID</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
+</component>
+</requirement>
2
000705req_job-management_start_​responseRequirement req_job-management_start_​response has no corresponding Conformance test
+
<requirement id="req_job-management_start_response" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/start-response</value> </classification> <component class="part"> <p id="_bfd626f2-403f-eaea-72c4-0cd09f7f4d04">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
+</component> <component class="part"> <p id="_0dc83efb-3525-4df8-e7fa-b5648b3c4609">A response SHALL be a document that conforms to statusInfo.yaml.</p>
+</component>
+</requirement>
2
000734req_job-management_​definition_get-opRequirement req_job-management_​definition_get-op has no corresponding Conformance test
+
<requirement id="req_job-management_definition_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-get-op</value> </classification> <component class="part"> <p id="_f8343c8c-67a6-5853-89bb-4b924e0a0c7c">For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path <tt>/jobs/{jobId}/definition</tt>.</p>
+</component> <component class="part"> <p id="_ac22c114-f460-53f1-0b37-b3ce1437ce56">The parameter <tt>jobId</tt> is each <tt>id</tt> property in the job-list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
+</component>
+</requirement>
2
000751req_job-management_​definition_​response-successRequirement req_job-management_​definition_​response-success has no corresponding Conformance test
+
<requirement id="req_job-management_definition_response-success" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-response-success</value> </classification> <component class="part"> <p id="_a711b14a-7976-bbb2-20e3-d97c7c898cd5">A successful access to the resource SHALL be reported as a response with a HTTP status code <tt>200</tt>.</p>
+</component>
+</requirement>
2
000760req_job-management_​definition_​response-bodyRequirement req_job-management_​definition_​response-body has no corresponding Conformance test
+
<requirement id="req_job-management_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-response-body</value> </classification> <component class="part"> <p id="_52f35875-3584-1c6c-85f4-6a450ca422bc">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the request body used to create or update the job.</p>
+</component>
+</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite OGC API — ​Processes — ​Part 1: Core outside this document
+
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
+</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite OGC API — ​Processes — ​Part 3: Workflows, Conformance Class ‘nested-processing’ outside this document
+
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
+</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​req/job-management outside this document
+
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
+</requirement>
2
000784rc_ogcapi-processesRequirement class rc_​ogcapi-processes has no corresponding Conformance class
+
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
+</requirement>
2
000784rc_ogcapi-processesRequirement class rc_​ogcapi-processes has no corresponding Requirement
+
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
+</requirement>
2
000812req_​ogcapi-processes_schemaRequirement req_​ogcapi-processes_schema has no corresponding Conformance test
+
<requirement id="req_ogcapi-processes_schema" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/schema</value> </classification> <component class="part"> <p id="_055e7b96-29a0-5380-0b91-38af56973b63">An <tt>OGC API - Processes - Workflow - Execute Request</tt> document SHALL be based upon the JSON schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflow.yaml</link>.</p>
+</component>
+</requirement>
2
000827req_​ogcapi-processes_create_​bodyRequirement req_​ogcapi-processes_create_​body has no corresponding Conformance test
+
<requirement id="req_ogcapi-processes_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/create-body</value> </classification> <component class="part"> <p id="_75888451-6c79-eddd-65b7-cc780518339b">The body of the POST request SHALL be based upon the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link> </p>
+</component> <component class="part"> <p id="_01239b62-2694-e6b9-5971-dfe78f1037ea">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a processes description encoded as an <xref target="rc_ogcapi-processes">OGC API — Processes</xref>.</p>
+</component>
+</requirement>
2
000839per_​ogcapi-processes_create_​content-schemaRequirement per_​ogcapi-processes_create_​content-schema has no corresponding Conformance test
+
<permission id="per_ogcapi-processes_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/ogcapi-processes/create-content-schema</value> </classification> <component class="part"> <p id="_b7a060ab-25d5-fdcc-67a8-104e19c5bd6d">The <tt>Content-Schema</tt> header MAY be pointing to the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link>.</p>
+</component>
+</permission>
2
000854req_​ogcapi-processes_update__​bodyRequirement req_​ogcapi-processes_update__​body has no corresponding Conformance test
+
<requirement id="req_ogcapi-processes_update__body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/update-body</value> </classification> <component class="part"> <p id="_611bbb8b-c9fa-bbef-e5c6-cef9ae1b9952">The media type <tt>application/ogcapi-processes+json</tt> SHALL be used to indicate that request body contains a job encoded as an <xref target="rc_openeo">OpenEO</xref>.</p>
+</component>
+</requirement>
2
000863per_​ogcapi-processes_update_​content-schemaRequirement per_​ogcapi-processes_update_​content-schema has no corresponding Conformance test
+
<permission id="per_ogcapi-processes_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/ogcapi-processes/update-content-schema</value> </classification> <component class="part"> <p id="_a595adf4-05cf-ff64-7335-c84d8a299ba7">The <tt>Content-Schema</tt> header MAY be pointing to the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link>.</p>
+</component>
+</permission>
2
000878req_​ogcapi-processes_​definition_​response-bodyRequirement req_​ogcapi-processes_​definition_​response-body has no corresponding Conformance test
+
<requirement id="req_ogcapi-processes_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/definition-response-body</value> </classification> <component class="part"> <p id="_5bdd268e-40d8-4c3b-5a25-a54dfb85dea5">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow — Execute Request</xref> to use to deploy the process.</p>
+</component>
+</requirement>
2
000894rc_openeoProvision rc_​openeo points to Prerequisite http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​req/job-management outside this document
+
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
+</requirement>
2
000894rc_openeoRequirement class rc_​openeo has no corresponding Conformance class
+
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
+</requirement>
2
000894rc_openeoRequirement class rc_​openeo has no corresponding Requirement
+
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
+</requirement>
2
000916req_​openeo_schemaRequirement req_​openeo_schema has no corresponding Conformance test
+
<requirement id="req_openeo_schema" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/schema</value> </classification> <component class="part"> <p id="_b547b858-02be-9df8-f006-9b81b930fe3c">An <tt>OpenEO Process Graph</tt> document SHALL be based upon the OpenEO Process Graph JSON schema <link target="https://openeo.org/documentation/1.0/developers/api/assets/pg-schema.json"/>.</p>
+</component>
+</requirement>
2
000945req_​openeo_create_​bodyRequirement req_​openeo_create_​body has no corresponding Conformance test
+
<requirement id="req_openeo_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/create-body</value> </classification> <component class="part"> <p id="_c03efe59-3bdd-80dd-8068-f491b4769083">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a processes description encoded as an <xref target="rc_openeo">OpenEO Process Graph</xref>.</p>
+</component>
+</requirement>
2
000954per_​openeo_create_​content-schemaRequirement per_​openeo_create_​content-schema has no corresponding Conformance test
+
<permission id="per_openeo_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/openeo/create-content-schema</value> </classification> <component class="part"> <p id="_dd2a38a1-1801-ea40-b40b-9306ffe963f5">The <tt>Content-Schema</tt> header MAY be pointing to <link target="https://raw.githubusercontent.com/Open-EO/openeo-processes/master/meta/subtype-schemas.json#/definitions/process-graph">OpenEO Process Graph schema</link>.</p>
+</component>
+</permission>
2
000969req_​openeo_update__​bodyRequirement req_​openeo_update__​body has no corresponding Conformance test
+
<requirement id="req_openeo_update__body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/update-body</value> </classification> <component class="part"> <p id="_d6d4d725-2e03-023e-6461-60f14e3dad00">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a job encoded as an <xref target="rc_openeo">OpenEO Process Graph</xref>.</p>
+</component>
+</requirement>
2
000978per_​openeo_update_​content-schemaRequirement per_​openeo_update_​content-schema has no corresponding Conformance test
+
<permission id="per_openeo_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/openeo/update-content-schema</value> </classification> <component class="part"> <p id="_d50f6b34-5c18-28c4-e3b4-e4bee8fb8ef3">The <tt>Content-Schema</tt> header MAY be pointing to <link target="https://raw.githubusercontent.com/Open-EO/openeo-processes/master/meta/subtype-schemas.json#/definitions/process-graph">OpenEO Process Graph schema</link>.</p>
+</component>
+</permission>
2
000993req_​openeo_​definition_​response-bodyRequirement req_​openeo_​definition_​response-body has no corresponding Conformance test
+
<requirement id="req_openeo_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/definition-response-body</value> </classification> <component class="part"> <p id="_e853fc8d-2e27-66d9-4e92-f94a581748c2">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the <xref target="rc_openeo">OpenEO Process Graph</xref> to use to deploy the process.</p>
+</component>
+</requirement>
2
001011rc_cwlProvision rc_cwl points to Prerequisite OGC API — ​Processes — ​Part 1: Core outside this document
+
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
+</requirement>
2
001011rc_cwlRequirement class rc_cwl has no corresponding Conformance class
+
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
+</requirement>
2
001011rc_cwlRequirement class rc_cwl has no corresponding Requirement
+
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
+</requirement>
2
001035req_job-provenance_inputs_​get-opRequirement req_job-provenance_inputs_​get-op has no corresponding Conformance test
+
<requirement id="req_job-provenance_inputs_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/inputs-get-op</value> </classification> <component class="part"> <p id="_d27b2f4a-46fe-e7a7-381a-3ef7f6992a3c">For every created jobs (path: <tt>/jobs/{jobId}/inputs</tt>), the server SHALL support the HTTP GET operation.</p>
+</component> <component class="part"> <p id="_a345c40a-d33e-e3cf-3ced-8f913b19061a">The parameter <tt>jobId</tt> is each <tt>jobID</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
+</component>
+</requirement>
2
001050req_​provenance_​inputs_​responseRequirement req_​provenance_​inputs_​response has no corresponding Conformance test
+
<requirement id="req_provenance_inputs_response" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/inputs-response</value> </classification> <component class="part"> <p id="_e9c66c92-5cc7-d756-9380-557ef120ef46">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
+</component> <component class="part"> <p id="_3494a24c-e31d-ae3c-e69f-870d5b2c7b1f">The response SHALL contains a JSON document that conforms to the schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-job-management/inputs.yaml">inputs.yaml</link>.</p>
+</component>
+</requirement>
2
001070req_job-provenance_prov_​get-opRequirement req_job-provenance_prov_​get-op has no corresponding Conformance test
+
<requirement id="req_job-provenance_prov_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/prov-get-op</value> </classification> <component class="part"> <p id="_05bee4f3-96a3-3cce-7f1f-bd4c27d62d2b">For every created jobs (path: <tt>/jobs/{jobId}/prov</tt>), the server SHALL support the HTTP GET operation.</p>
+</component> <component class="part"> <p id="_739e0c7c-5b29-f5cd-1dee-df8657a543c4">The parameter <tt>{jobId}</tt> is each <tt>id</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
+</component>
+</requirement>
2
001082per_job-provenance_run_​content-negotiationRequirement per_job-provenance_run_​content-negotiation has no corresponding Conformance test
+
<permission id="per_job-provenance_run_content-negotiation" model="ogc"> <classification> <tag>label</tag> <value>/per/provenance/run-content-negotiation</value> </classification> <component class="part"> <p id="_b966ac06-48ee-fd02-42ce-3cf08626284b">Content negotiation MAY be supported to provide alternate representations of the response.</p>
+</component> <component class="part"> <p id="_45871990-3a83-68b4-bfad-9867a122efa5">The server MAY support the following additional content type: <tt>application/ld+json</tt> for PROV-O as JSON-LD</p>
+</component> <component class="part"> <p id="_92f4d43e-d24a-0a26-7955-80f1674a1c99">The server MAY support the following additional content type: <tt>application/xml</tt> for PROV-XML</p>
+</component> <component class="part"> <p id="_a65968fc-deee-e0f6-c8e0-e101f4d89ed4">The server MAY support the following additional content type: <tt>text/provenance-notation; charset="UTF-8"</tt> for PROV-N.</p>
+</component>
2
001103req_​provenance_prov_​responseRequirement req_​provenance_​prov_response has no corresponding Conformance test
+
<requirement id="req_provenance_prov_response" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/prov-response</value> </classification> <component class="part"> <p id="_ecc83e9d-6eef-d592-a0b2-7608331e339c">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
+</component> <component class="part"> <p id="_815d65be-9385-0e4a-4be7-1dcb0d5d41c7">Per default, the response SHALL contains a JSON document that conforms to the <link target="https://www.w3.org/submissions/prov-json/schema">schema for PROV-JSON</link>.</p>
+</component> <component class="part"> <p id="_f8fa4c50-f38c-e314-3262-6ef9c84bb780">In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.</p>
+</component>
+</requirement>
2
001162ats_jmConformance class http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​conf/job-management has no corresponding Requirement class
+
<requirement id="ats_jm" model="ogc" type="conformanceclass">
+<title>Job Management</title> <identifier>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</identifier> <subject> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref> </subject> <classification> <tag>Target Type</tag> <value>Web API</value> </classification> <requirement id="_a86d877f-b639-4c33-aaf0-aafbda999bc2" model="ogc" type="verification"> <identifier>/conf/dru/deploy/post-op</identifier> </requirement>
+
+</requirement>
2
001181ats_jm_​deploy_post-opConformance test /conf/jm/​create/​post-op has no corresponding Conformance class
+
<requirement id="ats_jm_deploy_post-op" model="ogc" type="abstracttest"> <identifier>/conf/jm/create/post-op</identifier> <classification> <tag>target</tag> <value> <xref target="req_job-management_create_post-op">/req/job-management/create-post-op</xref> </value> </classification> <component class="test-purpose"> <p id="_cc03f424-278b-0166-2639-4f077846924c">Validate that the server support HTTP POST operation at the path /jobs/</p>
+</component> <component class="test-method"> <ol id="_8869dbb8-db35-c3f4-fc88-7b4faed37dd4" type="arabic"> <li> <p id="_e09e3851-35f0-f0ea-17a8-fddcc8354223">Construct a path for the {root}/jobs path.</p>
+</li>
+<li> <p id="_fc72724e-f13a-c143-3f82-e72502e115b7">Issue an HTTP POST request for each path.</p>
+</li>
2
001181ats_jm_​deploy_post-opConformance test /conf/jm/​create/​post-op has no corresponding Requirement
+
<requirement id="ats_jm_deploy_post-op" model="ogc" type="abstracttest"> <identifier>/conf/jm/create/post-op</identifier> <classification> <tag>target</tag> <value> <xref target="req_job-management_create_post-op">/req/job-management/create-post-op</xref> </value> </classification> <component class="test-purpose"> <p id="_cc03f424-278b-0166-2639-4f077846924c">Validate that the server support HTTP POST operation at the path /jobs/</p>
+</component> <component class="test-method"> <ol id="_8869dbb8-db35-c3f4-fc88-7b4faed37dd4" type="arabic"> <li> <p id="_e09e3851-35f0-f0ea-17a8-fddcc8354223">Construct a path for the {root}/jobs path.</p>
+</li>
+<li> <p id="_fc72724e-f13a-c143-3f82-e72502e115b7">Issue an HTTP POST request for each path.</p>
+</li>
2

+
Document Attributes

+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
--draft is not an allowed status for standard
2

+
Metanorma XML Syntax

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LineIDMessageContextSeverity
XML Line 000005:247character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000005:293character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000005:341character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000015:254element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000019:170element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000021:154element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000023:159element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000025:13element "admonition" missing required attribute "type"
2
XML Line 000028:113text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:121element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:139text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:147element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:162text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:170element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:188text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:196element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:210text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:218element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:235text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:243element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:260text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:268element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:285text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:293element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:307text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:315element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:332text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:340element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:355text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:363element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:379text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:387element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:402text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:410element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:427text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:435element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:532element "ext" incomplete; missing required element "editorialgroup"
2
XML Line 000028:86text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:94element "keyword" incomplete; missing required element "taxon"
2
XML Line 000079:104element "clause" not allowed here; expected element "foreword"
2
XML Line 000096:39element "submitters" not allowed yet; missing required element "foreword"
2
XML Line 000132:131IDREF "rc_job-management" without matching ID
2
XML Line 000150:204IDREF "rc_​provenance" without matching ID
2
XML Line 000162:60element "clause" not allowed here; expected the element end-tag or element "admonition", "amend", "bookmark", "columnbreak", "definitions", "dl", "example", "figure",​ "form", "formula", "hr", "imagemap", "note", "ol", "p", "pagebreak", "passthrough", "permission", "pre", "quote", "recommendation", "requirement", "review",​ "sourcecode", "svgmap",​ "table", "term", "terms", "toc" or "ul"
2
XML Line 000170:15element "definitions" incomplete; missing required element "dl"
2
XML Line 000181:294IDREF "rfc2616" without matching ID
2
XML Line 000181:455element "link" not allowed here; expected the element end-tag or text
2
XML Line 000401:274IDREF "rfc2616" without matching ID
2
XML Line 000519:108IDREF "deploy-replace-undeploy-http_​status_codes" without matching ID
2
XML Line 000530:446IDREF "rc_job-management" without matching ID
2
XML Line 000530:659element "link" not allowed here; expected the element end-tag or text
2
XML Line 000590:148IDREF "rc_job-management" without matching ID
2
XML Line 000590:351element "link" not allowed here; expected the element end-tag or text
2
XML Line 000665:347element "link" not allowed here; expected the element end-tag or text
2
XML Line 000752:167IDREF "rc_job-management" without matching ID
2
XML Line 000758:211element "xref" not allowed here; expected the element end-tag or text
2
XML Line 000835:61attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 000844:72found attribute "format",​ but no attributes allowed here
2
XML Line 000845:72found attribute "format",​ but no attributes allowed here
2
XML Line 000901:61attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 000908:51found attribute "format",​ but no attributes allowed here
2
XML Line 000909:8element "link" missing required attribute "target"
2
XML Line 000913:370element "link" missing required attribute "target"
2
XML Line 000913:51found attribute "format",​ but no attributes allowed here
2
XML Line 000916:116element "link" missing required attribute "target"
2
XML Line 000916:51found attribute "format",​ but no attributes allowed here
2

+
diff --git a/extensions/job_management/standard/24-051.html b/extensions/job_management/standard/24-051.html
new file mode 100644
index 00000000..71172760
--- /dev/null
+++ b/extensions/job_management/standard/24-051.html
@@ -0,0 +1,2386 @@
+
+
+OGC API - Processes - Part 4: Job Management
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

+    
Draft

+

+
+

+    
OGC Standard

+

+
+
+
+  
 • 

+
+  

+
+
+  

+    

+
+  

+
+    

+      OGC API - Processes - Part 4: Job Management
+      
+    

+  

+
+  
+
+  
+
+  

+    
+    
+    
+
+    
+    
+    Gérald Fenoy Editor
+    
+    
+  

+
+    

+      Submission Date:  yyyy-mm-dd
+      Approval Date:  yyyy-mm-dd
+      Publication Date:  yyyy-mm-dd
+      External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-processes-4/1.0
+      Internal identifier of this OGC® document: 24-051
+      
+      
+    

+
+    

+      
+      Version:  1.0

+      
+    
+    

+
+  

+
+    

+
+  

+  

+    OGC Standard
+  

+
+  

+    
Draft

+  

+

+
+  

+    

+
+
Notice for Drafts

+
+
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+
+
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+

+

+ 

+         
+
+
+

+  
+    
+    
+    
+    
+    
+  
Document number:24-051
Document type:OGC Standard
Document subtype:Implementation
Document stage:Draft
Document language:English

+

+
+

+

+  

+
+
Copyright notice

+
+
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visithttps://www.ogc.org/legal

+

+
+
Note

+
+
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

+
+
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

+

+

+

+
+

+

+  

+


+  

+
+
License Agreement

+
+
Use of this document is subject to the license agreement at https://www.ogc.org/license

+

+

+
+
+

+
+

+
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://ogc.standardstracker.org/

+

+

+
+
+

+
+
+
+
+

+


+
+
+
+
+
+
+


I.  Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to …​
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
CAUTION
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

+
II.  Keywords
The following are keywords to be used by search engines and document catalogues.
process, instance, spatial, data, openapi, job, create, update, delete, add, remove, REST, PATCH, POST, DELETE
III.  Security Considerations
See OGC API — Processes — Part 1: Core, Clause 10.4.
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.
Users making modifications to job resources need to:
  1. Be authenticated,
    
+
    2. 
+
  2. Have “modification privileges” on the jobs offered through the API,
    
+
    3. 
+
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
+
    4. 
+
The API definition, as defined in Clause 7.3 from OGC 18-062r2, must reflect this in the resource paths and their available methods.
IV.  Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
  • Geolabs
    • 
+
  • Terradue Srl.
    • 
+
  • Computer Research Institute of Montréal (CRIM).
V.  Submitters
All questions regarding this submission should be directed to the editors or the submitters:
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.
1.  Scope
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [OGC 18-062r2] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.
Specifically, the Processes Part 4 Standard specifies:
  • How to manage job.
    
+
    • 
+
  • How to handle provenenance information associated with a job.
    
+
    • 
+
2.  Conformance
The OGC API — Processes — Part 4 Standard defines the following requirements classes.
The main requirements class is:
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.
The standardization target for all Conformance class defined in this Standard is “Web API”.
Conformance with this Standard shall be checked using all the relevant tests specified in  Annex A 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.
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.

+
+
Benjamin Pross, Panagiotis (Peter) A. Vretanos: OGC 18-062r2, OGC API — Processes — Part 1: Core. Open Geospatial Consortium (2021). http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0.

+
Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, Undeploy

+
Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: Workflows

+
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0.

+
4.  Terms, definitions and abbreviated terms

+
No terms and definitions are listed in this document.

+
+
4.1.  Terms and definitions

+
+
See OGC 18-062r2, Clause 4.1.

+

+
+
4.2.  Abbreviated terms

+
+
See OGC 18-062r2, Clause 4.2.

+
5.  Conventions and background
See OGC 18-062r2, Clause 5.
6.  Requirements Class “Job Management”
6.1.  Overview

+
+
Requirements class 1
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core, Conformance Class ‘core’
RFC 2616 (HTTP/1.1)
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management

+
+
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

+
+
The HTTP POST method on the /jobs path is used on to create new jobs.

+
+
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

+
+
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

+
+
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

+
+

+
+
6.1.1.  HTTP status codes

+
+
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

+
+
The Status Codes listed in Table 1 are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in Table 1 are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

+
+
Table 1 — Typical HTTP status codes
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.
NOTE:    Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

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

+
+
Permission 1
Label/per/job-management/additional-status-codes
A
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in Table 1.

+

+
+
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

+

+
+
+
6.2.  Creating a new job

+
+
6.2.1.  Sequence diagram

+
+
The following diagram illustrates the sequence diagram for deploying a new process to the API:

+
+
 
Client                                                        Server
  |                                                             |
  |  POST /jobs   HTTP/1.1                                      |
  |  Content-Type: application/json                             |
  |                                                             |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 201 Created                                       |
  |  Location: /jobs/{jobId}                                    |
  |<------------------------------------------------------------|
Listing 1

+
+

+
+
6.2.2.  Operation

+
+
Requirement 1
Label/req/job-management/create-post-op
A
The server SHALL support the HTTP POST operation at the path /jobs.

+

+

+
+
6.2.3.  Request body

+
+
6.2.3.1.  Overview

+
+
Requirement 2
Label/req/job-management/create-body
A
The body of the POST request SHALL be in JSON format.

+

+
+
Permission 2
Label/per/job-management/create-body
A
A server MAY support any encoding in the body of a HTTP POST operation.

+

+
+
Requirement 3
Label/req/job-management/create-content-type
A
The Content-Type header SHALL be used to declare the media type of the request.

+

+
+
See section 3.1.1.5 of RFC 7231 for details.

+
+
Permission 3
Label/per/job-management/create-content-schema
A
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

+

+

+
+
6.2.3.2.  OGC API — Processes — Workflow Execute Request body

+
+
Recommendation 1
Label/rec/job-management/create-body-ogcapi-processes
A
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+

+

+
+
6.2.3.3.  OpenEO Process Graph body

+
+
Recommendation 2
Label/rec/job-management/create-body-openeo
A
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

+

+

+

+
+
6.2.4.  Response

+
+
Requirement 4
Label/req/job-management/create-response-jobid
A
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

+

+
+
Requirement 5
Label/req/job-management/create-response-success
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

+
B
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

+

+
+
Requirement 6
Label/req/job-management/create-response-body
A
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

+
B
The response SHALL contain a created status code and the id property that contains the job identifier.

+

+

+
+
6.2.5.  Exceptions

+
+
See Clause 6.1.1 for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

+
+
Requirement 7
Label/req/job-management/create-unsupported-schema
A
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

+
B
The content of that response SHALL be based upon the OpenAPI 3.0 schema  exception.yaml.

+
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.

+

+

+
6.3.  Updating an existing job

+
+
6.3.1.  Sequence diagram

+
+
The following diagram illustrates the sequence diagram for updating a
+previously created job.  The identifier of the job does not change.
NOTE:    The new job definition replaces the old job definition. Version control is not discussed in this Standard.

+
+
+
+
 
Client                                                        Server
  |                                                             |
  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
  |  Content-Type: application/json                             |
  |                                                             |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 200 OK                                            |
  |<------------------------------------------------------------|
Listing 2

+
+

+
+
6.3.2.  Operation

+
+
Requirement 8
Label/req/job-management/update-patch-op
A
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

+
B
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

+

+

+
+
6.3.3.  Request body

+
+

+
+
6.3.4.  Overview

+
+
Requirement 9
Label/req/job-management/update-body
A
The body of a PATCH request SHALL be in JSON format.

+

+
+
Permission 4
Label/per/job-management/update-body
A
A server MAY support any encoding in the body of a HTTP PATCH operation.

+

+
+
Requirement 10
Label/req/job-management/update-content-type
A
As per HTTP 1.1 (https://tools.ietf.org/html/rfc2616#section-14.17) the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

+

+
+
Permission 5
Label/per/job-management/update-content-schema
A
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

+

+
+
6.3.4.1.  OGC API — Processes — Workflow Execute Request

+
+
Recommendation 3
Label/rec/job-management/update-body-ogcapi-processes
A
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+

+

+
+
6.3.4.2.  OpenEO Process Graph

+
+
Recommendation 4
Label/rec/job-management/update-body-openeo
A
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

+

+

+

+
+
6.3.5.  Response

+
+
Requirement 11
Label/req/job-management/update-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

+

+
+
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

+

+
+
6.3.6.  Exceptions

+
+
See Clause 6.1.1 for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+
+
Requirement 12
Label/req/job-management/update-response-locked
A
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

+
B
The response body SHALL be based upon the OpenAPI 3.0 schema exception.yaml.

+
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.

+

+

+
6.4.  Staring a job

+
+
6.4.1.  Sequence diagram

+
+
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

+
+
 
Client                                                        Server
  |                                                             |
  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 200 OK                                            |
  |<------------------------------------------------------------|
Listing 3

+
+

+
+
6.4.2.  Operation

+
+
Requirement 13
Label/req/job-management/start-post-op
A
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

+
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+

+

+
+
6.4.3.  Response

+
+
Requirement 14
Label/req/job-management/start-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
A response SHALL be a document that conforms to statusInfo.yaml.

+

+

+
+
6.4.4.  Exceptions

+
+
See HTTP status codes for general guidance.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+
+
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from Clause 6.3.

+

+
6.5.  Job definition

+
+
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

+
+
6.5.1.  Operation

+
+
Requirement 15
Label/req/job-management/definition-get-op
A
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

+
B
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

+

+

+
+
6.5.2.  Response

+
+
6.5.2.1.  Overview

+
+
Requirement 16
Label/req/job-management/definition-response-success
A
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

+

+
+
Requirement 17
Label/req/job-management/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

+

+

+

+
+
6.5.3.  Exceptions

+
+
See HTTP status codes for general guidance.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+

+
7.  Requirements Class “OGC API — Process — Workflow Execute Request”
7.1.  Overview

+
+
Requirements class 2
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core
OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’
http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes

+
+
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

+
7.2.  OGC API — Processes — Workflow Execute Request

+
+
7.2.1.  Overview

+
+
Requirement 18
Label/req/ogcapi-processes/schema
A
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

+

+

+
7.3.  Creating a new job

+
+
7.3.1.  Request body

+
+
Requirement 19
Label/req/ogcapi-processes/create-body
A
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

+
B
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

+

+
+
Permission 6
Label/per/ogcapi-processes/create-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+

+

+
7.4.  Updating an existing job

+
+
7.4.1.  Request body

+
+
Requirement 20
Label/req/ogcapi-processes/update-body
A
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

+

+
+
Permission 7
Label/per/ogcapi-processes/update-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+

+

+
7.5.  Job definition

+
+
7.5.1.  Response content

+
+
Requirement 21
Label/req/ogcapi-processes/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

+

+

+
8.  Requirements Class “OpenEO Process Graph”
8.1.  Overview

+
+
Requirements class 3
Obligationrequirement
Target typeWeb API
Prerequisitehttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo

+
+
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

+
8.2.  OpenEO Process Graph

+
+
8.2.1.  Overview

+
+
Requirement 22
Label/req/openeo/schema
A
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema https://openeo.org/documentation/1.0/developers/api/assets/pg-schema.json.

+

+
+
 


type: object
additionalProperties:
  type: object
  required: 
    - process_id
    - arguments
  properties:
    process_id:
      type: string
    arguments: {}
Listing 4 —
+  Schema for OpenEO Process Graph
+

+
+

+
8.3.  Creating a new job

+
+
8.3.1.  Request body

+
+
Requirement 23
Label/req/openeo/create-body
A
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

+

+
+
Permission 8
Label/per/openeo/create-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+

+

+
8.4.  Updating an existing job

+
+
8.4.1.  Request body

+
+
Requirement 24
Label/req/openeo/update-body
A
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

+

+
+
Permission 9
Label/per/openeo/update-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+

+

+
8.5.  Job definition

+
+
8.5.1.  Response content

+
+
Requirement 25
Label/req/openeo/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

+

+

+
9.  Requirements Class “Provenance”
9.1.  Overview

+
+
This requirements class defines how to allow client application accessing the provenance of a job run.

+
+
Requirements class 4
Obligationrequirement
Target typeWeb API
PrerequisiteOGC API — Processes — Part 1: Core
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance

+
9.2.  Additional endpoints

+
+
9.2.1.  Inputs

+
+
The server MUST provide an endpoint to retrieve the inputs of a job run.

+
+
9.2.1.1.  Operation

+
+
Requirement 26
Label/req/provenance/inputs-get-op
A
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

+
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+

+

+
+
9.2.1.2.  Response

+
+
Requirement 27
Label/req/provenance/inputs-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

+

+

+

+
+
9.2.2.  Prov

+
+
The server MUST provide an endpoint to retrieve the provenance of a job.

+
+
9.2.2.1.  Operation

+
+
Requirement 28
Label/req/provenance/prov-get-op
A
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

+
B
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

+

+
+
Permission 10
Label/per/provenance/run-content-negotiation
A
Content negotiation MAY be supported to provide alternate representations of the response.

+
B
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

+
C
The server MAY support the following additional content type: application/xml for PROV-XML

+
D
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

+

+

+
+
9.2.2.2.  Response

+
+
Requirement 29
Label/req/provenance/prov-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

+
C
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

+

+

+

+

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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

+
+
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

+
A.2.  Conformance Class Job Management

+
+
Conformance class A.1: Job Management
Identifierhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Subjecthttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Target TypeWeb API
Conformance testConformance test A.1-1: /conf/dru/deploy/post-op

+
+
A.2.1.  Create operation

+
+
Abstract test A.1
Identifier/conf/jm/create/post-op
Requirement/req/job-management/create-post-op
Test purpose
Validate that the server support HTTP POST operation at the path /jobs/

+
Test method
  1. Construct a path for the {root}/jobs path.
    
+
    2. 
+
  2. Issue an HTTP POST request for each path.
    
+
    3. 
+
  3. Validate that the response header does not contain 405 Method not allowed
    
+
    4. 
+

+

+

+

Annex B
(informative)
Revision History
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

Bibliography

+
[1]  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
+https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md.
[2]  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. https://w3id.org/cwl/v1.2/
[3]  OpenEO: OpenEO Developers API Reference / Process Graphs. https://openeo.org/documentation/1.0/developers/api/reference.html#section/Processes/Process-Graphs

+
+
+
+

+
+  
+
+  
+
+
+
+
+
+  
+
+
+
+
+
+  
+    
+
+
+
+
+
+
diff --git a/extensions/job_management/standard/24-051.pdf.err b/extensions/job_management/standard/24-051.pdf.err
new file mode 100644
index 00000000..8ed3c414
--- /dev/null
+++ b/extensions/job_management/standard/24-051.pdf.err
@@ -0,0 +1,241 @@
+Content overflows the viewport of an fo:block-container in inline-progression direction by 36506 millipoints. (See position 595:3617)
+Page 4: Unresolved ID reference "rc_provenance" found.
+Page 4: Unresolved ID reference "rc_job-management" found.
+Page 12: Unresolved ID reference "rfc2616" found.
+Page 19: Unresolved ID reference "rfc2616" found.
+Page 23: Unresolved ID reference "deploy-replace-undeploy-http_status_codes" found.
+Page 25: Unresolved ID reference "rc_job-management" found.
+Page 29: Unresolved ID reference "rc_job-management" found.
+Page 41: Unresolved ID reference "_a86d877f-b639-4c33-aaf0-aafbda999bc2" found.
+Page 41: Unresolved ID reference "rc_job-management" found.
+5 link targets could not be fully resolved and now points to the top of the page or are dysfunctional.
+PDF isn't valid PDF/UA-1:
+ValidationResult [flavour=ua1, totalAssertions=278311, assertions=[
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
+message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
+message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
+message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
+location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[3](3023 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[5](3025 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[6](3026 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[7](3027 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[8](3028 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[9](3029 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[10](3030 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[11](3031 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[12](3032 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[13](3033 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[14](3034 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[15](3035 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[16](3036 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[17](3037 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[18](3038 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[19](3039 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[20](3040 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[21](3041 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[22](3042 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[23](3043 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[24](3044 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[25](3045 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[26](3046 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[27](3047 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[28](3048 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[29](3049 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[30](3050 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[31](3051 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[32](3052 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[33](3053 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[34](3054 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[35](3055 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[36](3056 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[37](3057 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[38](3058 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[39](3059 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[40](3060 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[41](3061 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[42](3062 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[43](3063 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[44](3064 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[45](3065 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[46](3066 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[47](3067 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[48](3068 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[49](3069 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[50](3070 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[51](3071 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
+TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
+message=TOCI element should be contained in TOC element,
+location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[52](3072 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null]], isCompliant=false]
diff --git a/extensions/job_management/standard/24-051.presentation.xml b/extensions/job_management/standard/24-051.presentation.xml
new file mode 100644
index 00000000..b59f2969
--- /dev/null
+++ b/extensions/job_management/standard/24-051.presentation.xml
@@ -0,0 +1,1800 @@
+
+
+
+OGC API - Processes - Part 4: Job Management
+http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
+Geolabs
+
+Terradue Srl.
+
+Computer Research Institute of Montréal (CRIM).
+
+Gérald Fenoy
+
+Open Geospatial Consortium
+OGC1.0en
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

+
+
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

+
+
The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.

+
+
The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to …​

+
+
The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

+
+CAUTION
This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.

+draftDraft2019
+Open Geospatial Consortium
+OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogcScopeSymbols and abbreviated termsAbbreviated termsSymbolsContentsIntroductionPrefaceAbstractAcknowledgementsTerms and definitionsTerms, definitions, symbols and abbreviated termsTerms, definitions and symbolsTerms, definitions and abbreviated termsNormative referencesBibliographyPrefaceSectionClauseAnnexAppendixcontinuedNo terms and definitions are listed in this document.
+This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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.
+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.There are no normative references in this document.This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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 terms and definitions given in % additionally apply.
+This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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 terms and definitions given in % and the following additionally apply.
+[NO INFORMATION AVAILABLE](%)%1 and %2%1, and %2%1 or %2%1, or %2%1 and %2%1 or %2%1 from %2%1 to %2%1, %2%1 %2spellout-ordinaldigits-ordinalNOTENoteNote % to entryListDefinition ListFigureDiagramFormulaFormulaTableRequirementRecommendationPermissionBox(NO ID)Recommendation testRequirement testPermission testRecommendations classRequirements classPermissions classAbstract testConformance classKeyExampleExamplewherewhereWhole of textdraftinformativenormativemodifiedadaptedDEPRECATEDSOURCEandAll Parts{{ var1 | ordinal_word: '', '' }} editioneditionversionList of FiguresList of TablesList of RecommendationsJanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberObligationDangerWarningCautionImportantSafety PrecautionsEditorial NoteSectionClausePartParagraphChapterPageTableAnnexFigureExampleNoteFormulamfncommonsgdualplpreppartadjadvnounverbdeprecatessupersedesnarrowerbroaderequivalentcomparecontrastseesee alsoClauseClausesAnnexAnnexesAppendixAppendixesNoteNotesNote % to entryNotes % to entryListListsFigureFiguresFormulaFormulasTableTablesRequirementRequirementsRecommendationRecommendationsPermissionPermissionsExampleExamplesPartPartsSectionSectionsParagraphParagraphsChapterChaptersPagePagesALTERNATIVESubmittersContributorsRevision historyListingTable of FiguresNo security considerations have been made for this document.Submission DateApproval DatePublication DateAuthorEditorContributorDraftWork Item DraftCandidate SWG DraftCandidate OAB Review DraftCandidate Public RFC DraftCandidate TC Vote DraftApprovedPublishedDeprecatedRescindedRetiredenLatncolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)Table
ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-op
ats_jm_deploy_post-op/conf/jm/create/post-op
TOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
+
+OGC API - Processes - Part 4: Job Management
+http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
+Geolabs
+
+Terradue Srl.
+
+Computer Research Institute of Montréal (CRIM).
+
+Gérald Fenoy
+
+Open Geospatial Consortium
+OGC1.0enLatnOGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
+
+The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
+
+The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.
+
+The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to …​
+
+The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
+
+This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.
+draft2019
+Open Geospatial Consortium
+OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogccolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-opats_jm_deploy_post-op/conf/jm/create/post-opTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
+
+
+
+Copyright notice
+Copyright © 2019 Open Geospatial Consortium To obtain additional rights of use, visit
+
+
+
+Note
+Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
+
+Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
+
+
+
+
+
+
+License Agreement
+Use of this document is subject to the license agreement at 
+
+
+
+
+
+
+Notice for Drafts
+This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.
+
+Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
+
+
+
+
+
+
+Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 
+
+
+AbstractOGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
+
+The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
+
+The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.
+
+The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to …​
+
+The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
+
+This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.
+
+Security Considerations
+See OGC API — Processes — Part 1: Core, Clause 10.4.
+
+Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.
+
+Users making modifications to job resources need to:
+
+Be authenticated,
+
+Have “modification privileges” on the jobs offered through the API,
+
+Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
+
+
+
+The API definition, as defined in Clause 7.3 from , must reflect this in the resource paths and their available methods.
+
+Submitters
+All questions regarding this submission should be directed to the editors or the submitters:
+
+Name
+Affiliation
+
+Gérald Fenoy (editor)
+GeoLabs
+Francis Charette Migneault (editor)
+Centre de Recherche Informatique de Montréal (CRIM)
+Panagiotis (Peter) A. Vretanos
+CubeWerx Inc.
+
+
+
+
+
+Scope
+The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.
+
+Specifically, the Processes Part 4 Standard specifies:
+
+How to manage job.
+
+How to handle provenenance information associated with a job.
+
+
+
+
+
+Conformance
+The OGC API — Processes — Part 4 Standard defines the following requirements classes.
+
+The main requirements class is:
+
+Job Management.
+
+
+
+This class specifies requirements that any Web API implementing Processes Part 4 must conform with.
+
+The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:
+
+OGC API — Processes — Workflow Execute Request
+
+OpenEO Process Graph
+
+
+
+The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.
+
+The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.
+
+The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.
+
+The standardization target for all Conformance class defined in this Standard is “Web API”.
+
+Conformance with this Standard shall be checked using all the relevant tests specified in   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.
+
+
+
+
+
+Terms, definitions and abbreviated termsNo terms and definitions are listed in this document.
+
+
+Terms and definitions
+See , Clause 4.1.
+
+
+
+Abbreviated terms
+See , Clause 4.2.
+
+
+
+Conventions and background
+See , Clause 5.
+
+
+
+Requirements Class “Job Management”
+
+Overview
+ Web APIOGC API — Processes — Part 1: Core, Conformance Class ‘core’RFC 2616 (HTTP/1.1)label
+
+
+A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.
+
+The HTTP POST method on the /jobs path is used on to create new jobs.
+
+The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.
+
+Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.
+
+Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:
+
+OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
+
+OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
+
+
+
+
+HTTP status codes
+Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.
+
+The Status Codes listed in  are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in  are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.
+
+
+Typical HTTP status codes
+Status code
+Description
+
+200
+A successful request.
+201
+The server has successfully completed the operation and a new resource has been created.
+202
+The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
+204
+A successful request with no additional content to send in the response.
+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 execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that 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
+Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
+412
+The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
+413
+The server is refusing to process the request because the request content is larger than the server is willing or able to process.
+415
+The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
+422
+The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
+500
+An internal error occurred in the server.
+
+Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.
+
+
+
+
+More specific guidance is provided for each resource, where applicable.
+
+ label/per/job-management/additional-status-codesServers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in .
+
+
+
+The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.
+
+
+
+Cross-origin requests
+See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).
+
+
+
+
+Creating a new job
+
+Sequence diagram
+The following diagram illustrates the sequence diagram for deploying a new process to the API:
+
+Client                                                        Server
+  |                                                             |
+  |  POST /jobs   HTTP/1.1                                      |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 201 Created                                       |
+  |  Location: /jobs/{jobId}                                    |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/create-post-opThe server SHALL support the HTTP POST operation at the path /jobs.
+
+
+
+
+
+Request body
+
+Overview
+ label/req/job-management/create-bodyThe body of the POST request SHALL be in JSON format.
+
+
+
+ label/per/job-management/create-bodyA server MAY support any encoding in the body of a HTTP POST operation.
+
+
+
+ label/req/job-management/create-content-typeThe Content-Type header SHALL be used to declare the media type of the request.
+
+
+
+See section 3.1.1.5 of RFC 7231 for details.
+
+ label/per/job-management/create-content-schemaThe Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.
+
+
+
+
+
+OGC API — Processes — Workflow Execute Request body
+ label/rec/job-management/create-body-ogcapi-processesIf the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.
+
+
+
+
+
+OpenEO Process Graph body
+ label/rec/job-management/create-body-openeoIf the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.
+
+
+
+
+
+
+Response
+ label/req/job-management/create-response-jobidIf the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.
+
+
+
+ label/req/job-management/create-response-successA successful execution of the operation SHALL be reported as a response with a HTTP status code 201.
+A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).
+
+
+
+ label/req/job-management/create-response-bodyThe response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.
+The response SHALL contain a created status code and the id property that contains the job identifier.
+
+
+
+
+
+Exceptions
+See  for general guidance.
+
+If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .
+
+ label/req/job-management/create-unsupported-schemaIf the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.
+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-4/1.0/unsupported-schema”.
+
+
+
+
+
+
+Updating an existing job
+
+Sequence diagram
+The following diagram illustrates the sequence diagram for updating a
+previously created job.  The identifier of the job does not change.The new job definition replaces the old job definition. Version control is not discussed in this Standard.
+
+
+
+
+Client                                                        Server
+  |                                                             |
+  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/update-patch-opFor every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.
+The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).
+
+
+
+
+
+Request body
+
+
+
+Overview
+ label/req/job-management/update-bodyThe body of a PATCH request SHALL be in JSON format.
+
+
+
+ label/per/job-management/update-bodyA server MAY support any encoding in the body of a HTTP PATCH operation.
+
+
+
+ label/req/job-management/update-content-typeAs per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.
+
+
+
+ label/per/job-management/update-content-schemaThe Content-Schema header MAY be used to indicate the schema of a request body for updating a job.
+
+
+
+
+OGC API — Processes — Workflow Execute Request
+ label/rec/job-management/update-body-ogcapi-processesIf a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.
+
+
+
+
+
+OpenEO Process Graph
+ label/rec/job-management/update-body-openeoIf a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.
+
+
+
+
+
+
+Response
+ label/req/job-management/update-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.
+
+
+
+The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).
+
+
+
+Exceptions
+See  for general guidance.
+
+If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .
+
+If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
+
+ label/req/job-management/update-response-lockedIf a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.
+The response body 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-4/1.0/locked”.
+
+
+
+
+
+
+Staring a job
+
+Sequence diagram
+The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.
+
+Client                                                        Server
+  |                                                             |
+  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/start-post-opFor every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.
+The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).
+
+
+
+
+
+Response
+ label/req/job-management/start-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
+A response SHALL be a document that conforms to statusInfo.yaml.
+
+
+
+
+
+Exceptions
+See HTTP status codes for general guidance.
+
+If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
+
+If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from .
+
+
+
+
+Job definition
+For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.
+
+
+Operation
+ label/req/job-management/definition-get-opFor every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.
+The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).
+
+
+
+
+
+Response
+
+Overview
+ label/req/job-management/definition-response-successA successful access to the resource SHALL be reported as a response with a HTTP status code 200.
+
+
+
+ label/req/job-management/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.
+
+
+
+
+
+
+Exceptions
+See HTTP status codes for general guidance.
+
+If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
+
+
+
+
+
+Requirements Class “OGC API — Process — Workflow Execute Request”
+
+Overview
+ Web APIOGC API — Processes — Part 1: CoreOGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
+
+
+This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.
+
+
+
+OGC API — Processes — Workflow Execute Request
+
+Overview
+ label/req/ogcapi-processes/schemaAn OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.
+
+
+
+
+
+
+Creating a new job
+
+Request body
+ label/req/ogcapi-processes/create-bodyThe body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml
+The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.
+
+
+
+ label/per/ogcapi-processes/create-content-schemaThe Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.
+
+
+
+
+
+
+Updating an existing job
+
+Request body
+ label/req/ogcapi-processes/update-bodyThe media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.
+
+
+
+ label/per/ogcapi-processes/update-content-schemaThe Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.
+
+
+
+
+
+
+Job definition
+
+Response content
+ label/req/ogcapi-processes/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.
+
+
+
+
+
+
+
+Requirements Class “OpenEO Process Graph”
+
+Overview
+ Web APIhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
+
+
+This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.
+
+
+
+OpenEO Process Graph
+
+Overview
+ label/req/openeo/schemaAn OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .
+
+
+
+
+Schema for OpenEO Process Graph
+type: object
+additionalProperties:
+  type: object
+  required: 
+    - process_id
+    - arguments
+  properties:
+    process_id:
+      type: string
+    arguments: {}
+
+
+
+
+
+Creating a new job
+
+Request body
+ label/req/openeo/create-bodyThe media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.
+
+
+
+ label/per/openeo/create-content-schemaThe Content-Schema header MAY be pointing to OpenEO Process Graph schema.
+
+
+
+
+
+
+Updating an existing job
+
+Request body
+ label/req/openeo/update-bodyThe media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.
+
+
+
+ label/per/openeo/update-content-schemaThe Content-Schema header MAY be pointing to OpenEO Process Graph schema.
+
+
+
+
+
+
+Job definition
+
+Response content
+ label/req/openeo/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.
+
+
+
+
+
+
+
+Requirements Class “Provenance”
+
+Overview
+This requirements class defines how to allow client application accessing the provenance of a job run.
+
+ Web APIOGC API — Processes — Part 1: Corelabel
+
+
+
+
+Additional endpoints
+
+Inputs
+The server MUST provide an endpoint to retrieve the inputs of a job run.
+
+
+Operation
+ label/req/provenance/inputs-get-opFor every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.
+The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).
+
+
+
+
+
+Response
+ label/req/provenance/inputs-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
+The response SHALL contains a JSON document that conforms to the schema inputs.yaml.
+
+
+
+
+
+
+Prov
+The server MUST provide an endpoint to retrieve the provenance of a job.
+
+
+Operation
+ label/req/provenance/prov-get-opFor every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.
+The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).
+
+
+
+ label/per/provenance/run-content-negotiationContent negotiation MAY be supported to provide alternate representations of the response.
+The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD
+The server MAY support the following additional content type: application/xml for PROV-XML
+The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.
+
+
+
+
+
+Response
+ label/req/provenance/prov-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
+Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.
+In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.
+
+
+
+
+
+
+
+
+OpenAPI 3.0
+See , Clause 9.
+
+
+
+Media Types
+See , Clause 13.
+
+
+
+
+
+
+
+
+
+
+Abstract Test Suite
+
+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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.
+
+The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.
+
+
+
+Conformance Class Job Management
+
+Job Managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementTarget TypeWeb API /conf/dru/deploy/post-op
+
+
+
+
+Create operation
+ /conf/jm/create/post-optarget/req/job-management/create-post-opValidate that the server support HTTP POST operation at the path /jobs/
+Construct a path for the {root}/jobs path.
+
+Issue an HTTP POST request for each path.
+
+Validate that the response header does not contain 405 Method not allowed
+
+
+
+
+
+
+
+Revision History
+Date
+Release
+Editor
+Primary clauses modified
+Description
+
+2024-08-22
+None
+Gérald Fenoy
+all
+Boostraping the document
+
+
+
+Normative referencesThe 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.
+
+
+  2024-11-14
+  
+OGC API
+
+  
+Processes
+
+  
+Part 1: Core
+
+  
+OGC API — Processes — Part 1: Core
+
+  http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0
+  https://docs.ogc.org/is/18-062r2/18-062r2.html
+  OGC 18-062r2
+  
+    2021-12-20
+  
+  
+    
+    
+      
+          Benjamin Pross       
+
+    
+  
+  
+    
+    
+      
+          Panagiotis (Peter) A. Vretanos       
+
+    
+  
+  
+    
+    
+      
+Open Geospatial Consortium
+
+    
+  
+  2
+  en
+  Latn
+  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.
+  
+
+Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-04420-044
+Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-00921-009
+
+  2024-11-14
+  
+OGC API
+
+  
+Features
+
+  
+Part 1: Core
+
+  
+OGC API — Features — Part 1: Core
+
+  http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0
+  https://docs.ogc.org/is/17-069r3/17-069r3.html
+  OGC 17-069r3
+  
+    2019-10-07
+  
+  
+    
+    
+      
+          Clemens Portele       
+
+    
+  
+  
+    
+    
+      
+          Panagiotis (Peter) A. Vretanos       
+
+    
+  
+  
+    
+    
+      
+          Charles Heazel       
+
+    
+  
+  
+    
+    
+      
+Open Geospatial Consortium
+
+    
+  
+  3
+  en
+  Latn
+  OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
+
+The OGC API family of standards is organized by resource type. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term ‘feature’ for things in the real world that are of interest.
+  
+
+
+Bibliography
+  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
+.
+  OpenAPI Specification 3.0.2
+  3.0.2
+
+  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. 
+  [2]
+
+  OpenEO: OpenEO Developers API Reference / Process Graphs. 
+  [3]
+
+
+
+
+
+sourcecode table td { padding: 5px; }
+sourcecode table pre { margin: 0; }
+sourcecode, sourcecode .w {
+  color: #444444;
+}
+sourcecode .cp {
+  color: #CC00A3;
+}
+sourcecode .cs {
+  color: #CC00A3;
+}
+sourcecode .c, sourcecode .ch, sourcecode .cd, sourcecode .cm, sourcecode .cpf, sourcecode .c1 {
+  color: #1E90FF;
+}
+sourcecode .kc {
+  color: #C34E00;
+}
+sourcecode .kd {
+  color: #0000FF;
+}
+sourcecode .kr {
+  color: #007575;
+}
+sourcecode .k, sourcecode .kn, sourcecode .kp, sourcecode .kt, sourcecode .kv {
+  color: #0000FF;
+}
+sourcecode .s, sourcecode .sb, sourcecode .sc, sourcecode .ld, sourcecode .sd, sourcecode .s2, sourcecode .se, sourcecode .sh, sourcecode .si, sourcecode .sx, sourcecode .sr, sourcecode .s1, sourcecode .ss {
+  color: #009C00;
+}
+sourcecode .sa {
+  color: #0000FF;
+}
+sourcecode .nb, sourcecode .bp {
+  color: #C34E00;
+}
+sourcecode .nt {
+  color: #0000FF;
+}
+
+
+
+
+Copyright notice
+
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visit

+
+
+
+Note
+
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

+
+
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

+
+
+
+
+
+
+License Agreement
+
Use of this document is subject to the license agreement at 

+
+
+
+
+
+
+Notice for Drafts
+
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+
+
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+
+
+
+
+
+
+
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 

+
+
+Contents
+I.<tab/>Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

+
+
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

+
+
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

+
+
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to …​

+
+
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

+
+CAUTION
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

+
+II.<tab/>Keywords
+
The following are keywords to be used by search engines and document catalogues.

+
process, instance, spatial, data, openapi, job, create, update, delete, add, remove, REST, PATCH, POST, DELETE

+
+III.<tab/>Security Considerations
+
See OGC API — Processes — Part 1: Core, Clause 10.4.

+
+
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.

+
+
Users making modifications to job resources need to:

+
+
  1. Be authenticated,
    
+
    2. 
+
  2. Have “modification privileges” on the jobs offered through the API,
    
+
    3. 
+
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
+
    4. 
+

+
+
The API definition, as defined in Clause 7.3 from OGC 18-062r2, must reflect this in the resource paths and their available methods.

+
+IV.<tab/>Submitting Organizations
+
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

+ 
  • Geolabs
    • 
+
  • Terradue Srl.
    • 
+
  • Computer Research Institute of Montréal (CRIM).

+ 
+
+V.<tab/>Submitters
+
All questions regarding this submission should be directed to the editors or the submitters:

+
+
+
+
+
+
+
+
+
+
+
+
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.

+
+
+
+1.<tab/>Scope
+
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [OGC 18-062r2] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.

+
+
Specifically, the Processes Part 4 Standard specifies:

+
+
  • How to manage job.
    
+
    • 
+
  • How to handle provenenance information associated with a job.
    
+
    • 
+

+
+
+
+2.<tab/>Conformance
+
The OGC API — Processes — Part 4 Standard defines the following requirements classes.

+
+
The main requirements class is:

+
+
  • Job Management.
    
+
    • 
+

+
+
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.

+
+
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:

+
+
  • OGC API — Processes — Workflow Execute Request
    
+
    • 
+
  • OpenEO Process Graph
    
+
    • 
+

+
+
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.

+
+
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.

+
+
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.

+
+
The standardization target for all Conformance class defined in this Standard is “Web API”.

+
+
Conformance with this Standard shall be checked using all the relevant tests specified in  Annex A 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.

+
+
+
+
+
+4.<tab/>Terms, definitions and abbreviated terms
No terms and definitions are listed in this document.

+
+
+4.1.<tab/>Terms and definitions
+
See OGC 18-062r2, Clause 4.1.

+
+
+
+4.2.<tab/>Abbreviated terms
+
See OGC 18-062r2, Clause 4.2.

+
+
+
+5.<tab/>Conventions and background
+
See OGC 18-062r2, Clause 5.

+
+
+
+6.<tab/>Requirements Class “Job Management”
+
+6.1.<tab/>Overview
+
+
Requirements class 1
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core, Conformance Class ‘core’
RFC 2616 (HTTP/1.1)
Label

+
+
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

+
+
The HTTP POST method on the /jobs path is used on to create new jobs.

+
+
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

+
+
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

+
+
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

+
+
  • OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
    
+
    • 
+
  • OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
    
+
    • 
+

+
+
+6.1.1.<tab/>HTTP status codes
+
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

+
+
The Status Codes listed in Table 1 are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in Table 1 are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

+
+
+Table 1 — Typical HTTP status codes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NOTE:
Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

+
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.

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

+
+
+
Permission 1
Label/per/job-management/additional-status-codes
A
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in Table 1.

+

+
+
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

+
+
+
+6.1.2.<tab/>Cross-origin requests
+
See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).

+
+
+
+
+6.2.<tab/>Creating a new job
+
+6.2.1.<tab/>Sequence diagram
+
The following diagram illustrates the sequence diagram for deploying a new process to the API:

+
+Listing 1Client                                                        Server
+  |                                                             |
+  |  POST /jobs   HTTP/1.1                                      |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 201 Created                                       |
+  |  Location: /jobs/{jobId}                                    |
+  |<------------------------------------------------------------|
+
+
+
+
+6.2.2.<tab/>Operation
+
+
Requirement 1
Label/req/job-management/create-post-op
A
The server SHALL support the HTTP POST operation at the path /jobs.

+

+
+
+
+6.2.3.<tab/>Request body
+
+6.2.3.1.<tab/>Overview
+
+
Requirement 2
Label/req/job-management/create-body
A
The body of the POST request SHALL be in JSON format.

+

+
+
+
Permission 2
Label/per/job-management/create-body
A
A server MAY support any encoding in the body of a HTTP POST operation.

+

+
+
+
Requirement 3
Label/req/job-management/create-content-type
A
The Content-Type header SHALL be used to declare the media type of the request.

+

+
+
See section 3.1.1.5 of RFC 7231 for details.

+
+
+
Permission 3
Label/per/job-management/create-content-schema
A
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

+

+
+
+
+6.2.3.2.<tab/>OGC API — Processes — Workflow Execute Request body
+
+
Recommendation 1
Label/rec/job-management/create-body-ogcapi-processes
A
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+

+
+
+
+6.2.3.3.<tab/>OpenEO Process Graph body
+
+
Recommendation 2
Label/rec/job-management/create-body-openeo
A
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

+

+
+
+
+
+6.2.4.<tab/>Response
+
+
Requirement 4
Label/req/job-management/create-response-jobid
A
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

+

+
+
+
Requirement 5
Label/req/job-management/create-response-success
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

+
B
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

+

+
+
+
Requirement 6
Label/req/job-management/create-response-body
A
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

+
B
The response SHALL contain a created status code and the id property that contains the job identifier.

+

+
+
+
+6.2.5.<tab/>Exceptions
+
See Clause 6.1.1 for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

+
+
+
Requirement 7
Label/req/job-management/create-unsupported-schema
A
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

+
B
The content of that response SHALL be based upon the OpenAPI 3.0 schema  exception.yaml.

+
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.

+

+
+
+
+
+6.3.<tab/>Updating an existing job
+
+6.3.1.<tab/>Sequence diagram
+
The following diagram illustrates the sequence diagram for updating a
+previously created job.  The identifier of the job does not change.NOTE:
The new job definition replaces the old job definition. Version control is not discussed in this Standard.

+

+
+
+
+Listing 2Client                                                        Server
+  |                                                             |
+  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+6.3.2.<tab/>Operation
+
+
Requirement 8
Label/req/job-management/update-patch-op
A
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

+
B
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

+

+
+
+
+6.3.3.<tab/>Request body
+
+
+
+6.3.4.<tab/>Overview
+
+
Requirement 9
Label/req/job-management/update-body
A
The body of a PATCH request SHALL be in JSON format.

+

+
+
+
Permission 4
Label/per/job-management/update-body
A
A server MAY support any encoding in the body of a HTTP PATCH operation.

+

+
+
+
Requirement 10
Label/req/job-management/update-content-type
A
As per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

+

+
+
+
Permission 5
Label/per/job-management/update-content-schema
A
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

+

+
+
+6.3.4.1.<tab/>OGC API — Processes — Workflow Execute Request
+
+
Recommendation 3
Label/rec/job-management/update-body-ogcapi-processes
A
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+

+
+
+
+6.3.4.2.<tab/>OpenEO Process Graph
+
+
Recommendation 4
Label/rec/job-management/update-body-openeo
A
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

+

+
+
+
+
+6.3.5.<tab/>Response
+
+
Requirement 11
Label/req/job-management/update-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

+

+
+
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

+
+
+
+6.3.6.<tab/>Exceptions
+
See Clause 6.1.1 for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+
+
+
Requirement 12
Label/req/job-management/update-response-locked
A
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

+
B
The response body SHALL be based upon the OpenAPI 3.0 schema exception.yaml.

+
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.

+

+
+
+
+
+6.4.<tab/>Staring a job
+
+6.4.1.<tab/>Sequence diagram
+
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

+
+Listing 3Client                                                        Server
+  |                                                             |
+  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+6.4.2.<tab/>Operation
+
+
Requirement 13
Label/req/job-management/start-post-op
A
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

+
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+

+
+
+
+6.4.3.<tab/>Response
+
+
Requirement 14
Label/req/job-management/start-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
A response SHALL be a document that conforms to statusInfo.yaml.

+

+
+
+
+6.4.4.<tab/>Exceptions
+
See HTTP status codes for general guidance.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+
+
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from Clause 6.3.

+
+
+
+
+6.5.<tab/>Job definition
+
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

+
+
+6.5.1.<tab/>Operation
+
+
Requirement 15
Label/req/job-management/definition-get-op
A
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

+
B
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

+

+
+
+
+6.5.2.<tab/>Response
+
+6.5.2.1.<tab/>Overview
+
+
Requirement 16
Label/req/job-management/definition-response-success
A
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

+

+
+
+
Requirement 17
Label/req/job-management/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

+

+
+
+
+
+6.5.3.<tab/>Exceptions
+
See HTTP status codes for general guidance.

+
+
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

+
+
+
+
+
+7.<tab/>Requirements Class “OGC API — Process — Workflow Execute Request”
+
+7.1.<tab/>Overview
+
+
Requirements class 2
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core
OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’
http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Label

+
+
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

+
+
+
+7.2.<tab/>OGC API — Processes — Workflow Execute Request
+
+7.2.1.<tab/>Overview
+
+
Requirement 18
Label/req/ogcapi-processes/schema
A
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

+

+
+
+
+
+7.3.<tab/>Creating a new job
+
+7.3.1.<tab/>Request body
+
+
Requirement 19
Label/req/ogcapi-processes/create-body
A
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

+
B
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

+

+
+
+
Permission 6
Label/per/ogcapi-processes/create-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+

+
+
+
+
+7.4.<tab/>Updating an existing job
+
+7.4.1.<tab/>Request body
+
+
Requirement 20
Label/req/ogcapi-processes/update-body
A
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

+

+
+
+
Permission 7
Label/per/ogcapi-processes/update-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+

+
+
+
+
+7.5.<tab/>Job definition
+
+7.5.1.<tab/>Response content
+
+
Requirement 21
Label/req/ogcapi-processes/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

+

+
+
+
+
+
+8.<tab/>Requirements Class “OpenEO Process Graph”
+
+8.1.<tab/>Overview
+
+
Requirements class 3
Obligationrequirement
Target typeWeb API
Prerequisitehttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Label

+
+
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

+
+
+
+8.2.<tab/>OpenEO Process Graph
+
+8.2.1.<tab/>Overview
+
+
Requirement 22
Label/req/openeo/schema
A
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .

+

+
+Listing 4 — 
+  Schema for OpenEO Process Graph
+
+
+type: object
+additionalProperties:
+  type: object
+  required: 
+    - process_id
+    - arguments
+  properties:
+    process_id:
+      type: string
+    arguments: {}
+
+
+
+
+
+8.3.<tab/>Creating a new job
+
+8.3.1.<tab/>Request body
+
+
Requirement 23
Label/req/openeo/create-body
A
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

+

+
+
+
Permission 8
Label/per/openeo/create-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+

+
+
+
+
+8.4.<tab/>Updating an existing job
+
+8.4.1.<tab/>Request body
+
+
Requirement 24
Label/req/openeo/update-body
A
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

+

+
+
+
Permission 9
Label/per/openeo/update-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+

+
+
+
+
+8.5.<tab/>Job definition
+
+8.5.1.<tab/>Response content
+
+
Requirement 25
Label/req/openeo/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

+

+
+
+
+
+
+9.<tab/>Requirements Class “Provenance”
+
+9.1.<tab/>Overview
+
This requirements class defines how to allow client application accessing the provenance of a job run.

+
+
+
Requirements class 4
Obligationrequirement
Target typeWeb API
PrerequisiteOGC API — Processes — Part 1: Core
Label

+
+
+
+9.2.<tab/>Additional endpoints
+
+9.2.1.<tab/>Inputs
+
The server MUST provide an endpoint to retrieve the inputs of a job run.

+
+
+9.2.1.1.<tab/>Operation
+
+
Requirement 26
Label/req/provenance/inputs-get-op
A
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

+
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+

+
+
+
+9.2.1.2.<tab/>Response
+
+
Requirement 27
Label/req/provenance/inputs-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

+

+
+
+
+
+9.2.2.<tab/>Prov
+
The server MUST provide an endpoint to retrieve the provenance of a job.

+
+
+9.2.2.1.<tab/>Operation
+
+
Requirement 28
Label/req/provenance/prov-get-op
A
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

+
B
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

+

+
+
+
Permission 10
Label/per/provenance/run-content-negotiation
A
Content negotiation MAY be supported to provide alternate representations of the response.

+
B
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

+
C
The server MAY support the following additional content type: application/xml for PROV-XML

+
D
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

+

+
+
+
+9.2.2.2.<tab/>Response
+
+
Requirement 29
Label/req/provenance/prov-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
B
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

+
C
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

+

+
+
+
+
+
+
+10.<tab/>OpenAPI 3.0
+
See OGC 18-062r2, Clause 9.

+
+
+
+11.<tab/>Media Types
+
See OGC 18-062r2, Clause 13.

+
+
+
+
+
+
+
+
+
+
+3.<tab/>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.

+
+Benjamin Pross, Panagiotis (Peter) A. Vretanos: OGC 18-062r2, OGC API — Processes — Part 1: Core. Open Geospatial Consortium (2021). http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0.http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0https://docs.ogc.org/is/18-062r2/18-062r2.htmlOGC 18-062r2OGC 18-062r2
+Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-044OGC 20-04420-044
+Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-009OGC 21-00921-009
+Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0.http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0https://docs.ogc.org/is/17-069r3/17-069r3.htmlOGC 17-069r3OGC 17-069r3
+
+<strong>Annex A</strong><br/>(normative)<br/><strong>Abstract Test Suite</strong>
+
+A.1.<tab/>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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

+
+
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

+
+
+
+A.2.<tab/>Conformance Class Job Management
+
+
+
+
Conformance class A.1: Job Management
Identifierhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Subjecthttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Target TypeWeb API
Conformance testConformance test A.1-1: /conf/dru/deploy/post-op

+
+
+A.2.1.<tab/>Create operation
+
+
+
+
Abstract test A.1
Identifier/conf/jm/create/post-op
Requirement/req/job-management/create-post-op
Test purpose
Validate that the server support HTTP POST operation at the path /jobs/

+
Test method
  1. Construct a path for the {root}/jobs path.
    
+
    2. 
+
  2. Issue an HTTP POST request for each path.
    
+
    3. 
+
  3. Validate that the response header does not contain 405 Method not allowed
    
+
    4. 
+

+

+
+
+
+<strong>Annex B</strong><br/>(informative)<br/><strong>Revision History</strong>
+
+
+
+
+
+
+
+
+
+
+
+
+
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

+
+Bibliography
+  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
+.[1]
+  OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2
+  3.0.2
+[1]
+  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. [2]
+  
+[2]
+  OpenEO: OpenEO Developers API Reference / Process Graphs. [3]
+  
+[3]
+
+
+
+
+
diff --git a/extensions/job_management/standard/24-051.xml b/extensions/job_management/standard/24-051.xml
new file mode 100644
index 00000000..1104fe0a
--- /dev/null
+++ b/extensions/job_management/standard/24-051.xml
@@ -0,0 +1,923 @@
+
+
+
+OGC API - Processes - Part 4: Job Management
+http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
+Geolabs
+
+Terradue Srl.
+
+Computer Research Institute of Montréal (CRIM).
+
+Gérald Fenoy
+
+Open Geospatial Consortium
+OGC1.0en
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

+
+
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

+
+
The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.

+
+
The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to …​

+
+
The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

+
+
This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.

+draft2019
+Open Geospatial Consortium
+OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogccolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)
ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-op
ats_jm_deploy_post-op/conf/jm/create/post-op
TOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
+
+
+
+Copyright notice
+
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visit

+
+
+
+Note
+
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

+
+
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

+
+
+
+
+
+
+License Agreement
+
Use of this document is subject to the license agreement at 

+
+
+
+
+
+
+Notice for Drafts
+
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+
+
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+
+
+
+
+
+
+
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 

+
+
+Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

+
+
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

+
+
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

+
+
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to …​

+
+
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

+
+
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

+
+Security Considerations
+
See OGC API — Processes — Part 1: Core, Clause 10.4.

+
+
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.

+
+
Users making modifications to job resources need to:

+
+
  1. Be authenticated,
    
+
    2. 
+
  2. Have “modification privileges” on the jobs offered through the API,
    
+
    3. 
+
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
+
    4. 
+

+
+
The API definition, as defined in Clause 7.3 from , must reflect this in the resource paths and their available methods.

+
+Submitters
+
All questions regarding this submission should be directed to the editors or the submitters:

+
+
+
+
+
+
+
+
+
+
+
+
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.

+
+
+
+Scope
+
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.

+
+
Specifically, the Processes Part 4 Standard specifies:

+
+
  • How to manage job.
    
+
    • 
+
  • How to handle provenenance information associated with a job.
    
+
    • 
+

+
+
+
+Conformance
+
The OGC API — Processes — Part 4 Standard defines the following requirements classes.

+
+
The main requirements class is:

+
+
  • Job Management.
    
+
    • 
+

+
+
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.

+
+
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:

+
+
  • OGC API — Processes — Workflow Execute Request
    
+
    • 
+
  • OpenEO Process Graph
    
+
    • 
+

+
+
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.

+
+
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.

+
+
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.

+
+
The standardization target for all Conformance class defined in this Standard is “Web API”.

+
+
Conformance with this Standard shall be checked using all the relevant tests specified in   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.

+
+
+
+
+
+Terms, definitions and abbreviated terms
No terms and definitions are listed in this document.

+
+
+Terms and definitions
+
See , Clause 4.1.

+
+
+
+Abbreviated terms
+
See , Clause 4.2.

+
+
+
+Conventions and background
+
See , Clause 5.

+
+
+
+Requirements Class “Job Management”
+
+Overview
+ Web APIOGC API — Processes — Part 1: Core, Conformance Class ‘core’RFC 2616 (HTTP/1.1)label
+
+
+
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

+
+
The HTTP POST method on the /jobs path is used on to create new jobs.

+
+
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

+
+
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

+
+
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

+
+
  • OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
    
+
    • 
+
  • OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
    
+
    • 
+

+
+
+HTTP status codes
+
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

+
+
The Status Codes listed in  are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in  are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

+
+
+Typical HTTP status codes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

+
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.

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

+
+ label/per/job-management/additional-status-codes
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in .

+
+
+
+
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

+
+
+
+Cross-origin requests
+
See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).

+
+
+
+
+Creating a new job
+
+Sequence diagram
+
The following diagram illustrates the sequence diagram for deploying a new process to the API:

+
+Client                                                        Server
+  |                                                             |
+  |  POST /jobs   HTTP/1.1                                      |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 201 Created                                       |
+  |  Location: /jobs/{jobId}                                    |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/create-post-op
The server SHALL support the HTTP POST operation at the path /jobs.

+
+
+
+
+
+Request body
+
+Overview
+ label/req/job-management/create-body
The body of the POST request SHALL be in JSON format.

+
+
+
+ label/per/job-management/create-body
A server MAY support any encoding in the body of a HTTP POST operation.

+
+
+
+ label/req/job-management/create-content-type
The Content-Type header SHALL be used to declare the media type of the request.

+
+
+
+
See section 3.1.1.5 of RFC 7231 for details.

+
+ label/per/job-management/create-content-schema
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

+
+
+
+
+
+OGC API — Processes — Workflow Execute Request body
+ label/rec/job-management/create-body-ogcapi-processes
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+
+
+
+
+
+OpenEO Process Graph body
+ label/rec/job-management/create-body-openeo
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

+
+
+
+
+
+
+Response
+ label/req/job-management/create-response-jobid
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

+
+
+
+ label/req/job-management/create-response-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

+
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

+
+
+
+ label/req/job-management/create-response-body
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

+
The response SHALL contain a created status code and the id property that contains the job identifier.

+
+
+
+
+
+Exceptions
+
See  for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .

+
+ label/req/job-management/create-unsupported-schema
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

+
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-4/1.0/unsupported-schema”.

+
+
+
+
+
+
+Updating an existing job
+
+Sequence diagram
+
The following diagram illustrates the sequence diagram for updating a
+previously created job.  The identifier of the job does not change.
The new job definition replaces the old job definition. Version control is not discussed in this Standard.

+

+
+
+
+Client                                                        Server
+  |                                                             |
+  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
+  |  Content-Type: application/json                             |
+  |                                                             |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/update-patch-op
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

+
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

+
+
+
+
+
+Request body
+
+
+
+Overview
+ label/req/job-management/update-body
The body of a PATCH request SHALL be in JSON format.

+
+
+
+ label/per/job-management/update-body
A server MAY support any encoding in the body of a HTTP PATCH operation.

+
+
+
+ label/req/job-management/update-content-type
As per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

+
+
+
+ label/per/job-management/update-content-schema
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

+
+
+
+
+OGC API — Processes — Workflow Execute Request
+ label/rec/job-management/update-body-ogcapi-processes
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

+
+
+
+
+
+OpenEO Process Graph
+ label/rec/job-management/update-body-openeo
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

+
+
+
+
+
+
+Response
+ label/req/job-management/update-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

+
+
+
+
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

+
+
+
+Exceptions
+
See  for general guidance.

+
+
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .

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

+
+ label/req/job-management/update-response-locked
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

+
The response body 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-4/1.0/locked”.

+
+
+
+
+
+
+Staring a job
+
+Sequence diagram
+
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

+
+Client                                                        Server
+  |                                                             |
+  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
+  |------------------------------------------------------------>|
+  |                                                             |
+  |  HTTP/1.1 200 OK                                            |
+  |<------------------------------------------------------------|
+
+
+
+
+Operation
+ label/req/job-management/start-post-op
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

+
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+
+
+
+
+
+Response
+ label/req/job-management/start-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
A response SHALL be a document that conforms to statusInfo.yaml.

+
+
+
+
+
+Exceptions
+
See HTTP status codes for general guidance.

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

+
+
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from .

+
+
+
+
+Job definition
+
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

+
+
+Operation
+ label/req/job-management/definition-get-op
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

+
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

+
+
+
+
+
+Response
+
+Overview
+ label/req/job-management/definition-response-success
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

+
+
+
+ label/req/job-management/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

+
+
+
+
+
+
+Exceptions
+
See HTTP status codes for general guidance.

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

+
+
+
+
+
+Requirements Class “OGC API — Process — Workflow Execute Request”
+
+Overview
+ Web APIOGC API — Processes — Part 1: CoreOGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
+
+
+
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

+
+
+
+OGC API — Processes — Workflow Execute Request
+
+Overview
+ label/req/ogcapi-processes/schema
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

+
+
+
+
+
+
+Creating a new job
+
+Request body
+ label/req/ogcapi-processes/create-body
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

+
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

+
+
+
+ label/per/ogcapi-processes/create-content-schema
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+
+
+
+
+
+
+Updating an existing job
+
+Request body
+ label/req/ogcapi-processes/update-body
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

+
+
+
+ label/per/ogcapi-processes/update-content-schema
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

+
+
+
+
+
+
+Job definition
+
+Response content
+ label/req/ogcapi-processes/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

+
+
+
+
+
+
+
+Requirements Class “OpenEO Process Graph”
+
+Overview
+ Web APIhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
+
+
+
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

+
+
+
+OpenEO Process Graph
+
+Overview
+ label/req/openeo/schema
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .

+
+
+
+
+Schema for OpenEO Process Graph
+type: object
+additionalProperties:
+  type: object
+  required: 
+    - process_id
+    - arguments
+  properties:
+    process_id:
+      type: string
+    arguments: {}
+
+
+
+
+
+Creating a new job
+
+Request body
+ label/req/openeo/create-body
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

+
+
+
+ label/per/openeo/create-content-schema
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+
+
+
+
+
+
+Updating an existing job
+
+Request body
+ label/req/openeo/update-body
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

+
+
+
+ label/per/openeo/update-content-schema
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

+
+
+
+
+
+
+Job definition
+
+Response content
+ label/req/openeo/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

+
+
+
+
+
+
+
+Requirements Class “Provenance”
+
+Overview
+
This requirements class defines how to allow client application accessing the provenance of a job run.

+
+ Web APIOGC API — Processes — Part 1: Corelabel
+
+
+
+
+Additional endpoints
+
+Inputs
+
The server MUST provide an endpoint to retrieve the inputs of a job run.

+
+
+Operation
+ label/req/provenance/inputs-get-op
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

+
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

+
+
+
+
+
+Response
+ label/req/provenance/inputs-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

+
+
+
+
+
+
+Prov
+
The server MUST provide an endpoint to retrieve the provenance of a job.

+
+
+Operation
+ label/req/provenance/prov-get-op
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

+
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

+
+
+
+ label/per/provenance/run-content-negotiation
Content negotiation MAY be supported to provide alternate representations of the response.

+
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

+
The server MAY support the following additional content type: application/xml for PROV-XML

+
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

+
+
+
+
+
+Response
+ label/req/provenance/prov-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

+
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

+
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

+
+
+
+
+
+
+
+
+OpenAPI 3.0
+
See , Clause 9.

+
+
+
+Media Types
+
See , Clause 13.

+
+
+
+
+
+
+
+
+
+
+Abstract Test Suite
+
+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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

+
+
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

+
+
+
+Conformance Class Job Management
+
+Job Managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementTarget TypeWeb API /conf/dru/deploy/post-op
+
+
+
+
+Create operation
+ /conf/jm/create/post-optarget/req/job-management/create-post-op
Validate that the server support HTTP POST operation at the path /jobs/

+
  1. Construct a path for the {root}/jobs path.
    
+
    2. 
+
  2. Issue an HTTP POST request for each path.
    
+
    3. 
+
  3. Validate that the response header does not contain 405 Method not allowed
    
+
    4. 
+

+
+
+
+
+
+Revision History
+
+
+
+
+
+
+
+
+
+
+
+
+
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

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

+
+
+  2024-11-14
+  
+OGC API
+
+  
+Processes
+
+  
+Part 1: Core
+
+  
+OGC API — Processes — Part 1: Core
+
+  http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0
+  https://docs.ogc.org/is/18-062r2/18-062r2.html
+  18-062r2
+  
+    2021-12-20
+  
+  
+    
+    
+      
+          Benjamin Pross       
+
+    
+  
+  
+    
+    
+      
+          Panagiotis (Peter) A. Vretanos       
+
+    
+  
+  
+    
+    
+      
+Open Geospatial Consortium
+
+    
+  
+  2
+  en
+  
+  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.
+  
+
+Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-04420-044
+Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-00921-009
+
+  2024-11-14
+  
+OGC API
+
+  
+Features
+
+  
+Part 1: Core
+
+  
+OGC API — Features — Part 1: Core
+
+  http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0
+  https://docs.ogc.org/is/17-069r3/17-069r3.html
+  17-069r3
+  
+    2019-10-07
+  
+  
+    
+    
+      
+          Clemens Portele       
+
+    
+  
+  
+    
+    
+      
+          Panagiotis (Peter) A. Vretanos       
+
+    
+  
+  
+    
+    
+      
+          Charles Heazel       
+
+    
+  
+  
+    
+    
+      
+Open Geospatial Consortium
+
+    
+  
+  3
+  en
+  
+  OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
+
+The OGC API family of standards is organized by resource type. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term ‘feature’ for things in the real world that are of interest.
+  
+
+
+Bibliography
+  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
+.
+  OpenAPI Specification 3.0.2
+  3.0.2
+
+  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. 
+  [2]
+
+  OpenEO: OpenEO Developers API Reference / Process Graphs. 
+  [3]
+
+
+
+
+
+
diff --git a/extensions/job_management/standard/recommendations/provenance/run/PER_content-negotiation.adoc b/extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc
similarity index 100%
rename from extensions/job_management/standard/recommendations/provenance/run/PER_content-negotiation.adoc
rename to extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc
diff --git a/extensions/job_management/standard/requirements/provenance/prov/REQ_get-op.adoc b/extensions/job_management/standard/requirements/provenance/prov/REQ_get-op.adoc
new file mode 100644
index 00000000..2e06e8a6
--- /dev/null
+++ b/extensions/job_management/standard/requirements/provenance/prov/REQ_get-op.adoc
@@ -0,0 +1,8 @@
+[[req_job-provenance_prov_get-op]]
+[requirement]
+====
+[%metadata]
+label:: /req/provenance/prov-get-op
+part:: For every created jobs (path: `/jobs/{jobId}/prov`), the server SHALL support the HTTP GET operation.
+part:: The parameter `{jobId}` is each `id` property in the job list response (JSONPath: `$.jobs[*].id`).
+====
diff --git a/extensions/job_management/standard/requirements/provenance/run/REQ_response.adoc b/extensions/job_management/standard/requirements/provenance/prov/REQ_response.adoc
similarity index 86%
rename from extensions/job_management/standard/requirements/provenance/run/REQ_response.adoc
rename to extensions/job_management/standard/requirements/provenance/prov/REQ_response.adoc
index f31d4963..2a6edc47 100644
--- a/extensions/job_management/standard/requirements/provenance/run/REQ_response.adoc
+++ b/extensions/job_management/standard/requirements/provenance/prov/REQ_response.adoc
@@ -1,8 +1,8 @@
-[[req_provenance_run_response]]
+[[req_provenance_prov_response]]
 [requirement]
 ====
 [%metadata]
-label:: /req/provenance/run-response
+label:: /req/provenance/prov-response
 part:: A successful execution of the operation SHALL be reported as a response with a HTTP status code '200'.
 part:: Per default, the response SHALL contains a JSON document that conforms to the https://www.w3.org/submissions/prov-json/schema[schema for PROV-JSON].
 part:: In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.
diff --git a/extensions/job_management/standard/requirements/provenance/run/REQ_get-op.adoc b/extensions/job_management/standard/requirements/provenance/run/REQ_get-op.adoc
deleted file mode 100644
index a2ca4da7..00000000
--- a/extensions/job_management/standard/requirements/provenance/run/REQ_get-op.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-[[req_job-provenance_run_get-op]]
-[requirement]
-====
-[%metadata]
-label:: /req/provenance/run-get-op
-part:: For every created jobs (path: `/jobs/{jobId}/run`), the server SHALL support the HTTP GET operation.
-part:: The parameter `{jobId}` is each `id` property in the job list response (JSONPath: `$.jobs[*].id`).
-====
diff --git a/extensions/job_management/standard/sections/clause_9_provenance.adoc b/extensions/job_management/standard/sections/clause_9_provenance.adoc
index ab3d4e1a..cc881207 100644
--- a/extensions/job_management/standard/sections/clause_9_provenance.adoc
+++ b/extensions/job_management/standard/sections/clause_9_provenance.adoc
@@ -21,18 +21,18 @@ include::../requirements/provenance/inputs/REQ_get-op.adoc[]
 
 include::../requirements/provenance/inputs/REQ_response.adoc[]
 
-==== Run
+==== Prov
 
-The server MUST provide an endpoint to retrieve the run of a job.
+The server MUST provide an endpoint to retrieve the provenance of a job.
 
 ===== Operation
 
-include::../requirements/provenance/run/REQ_get-op.adoc[]
+include::../requirements/provenance/prov/REQ_get-op.adoc[]
 
-include::../recommendations/provenance/run/PER_content-negotiation.adoc[]
+include::../recommendations/provenance/prov/PER_content-negotiation.adoc[]
 
 ===== Response
 
-include::../requirements/provenance/run/REQ_response.adoc[]
+include::../requirements/provenance/prov/REQ_response.adoc[]
 
 
diff --git a/openapi/paths/processes-dru/pDeploy.yaml b/openapi/paths/processes-dru/pDeploy.yaml
index e84843e8..0947c156 100644
--- a/openapi/paths/processes-dru/pDeploy.yaml
+++ b/openapi/paths/processes-dru/pDeploy.yaml
@@ -29,6 +29,8 @@ post:
    responses:
      201:
        $ref: "../../schemas/processes-core/processSummary.yaml"
+     400:
+       $ref: "../../responses/processes-dru/rWorkflowNotFound.yaml"
      403:
        $ref: "../../responses/processes-dru/rImmutableProcess.yaml"
      409:
diff --git a/openapi/paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml b/openapi/paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml
index 76020cc2..4a40d3f1 100644
--- a/openapi/paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml
+++ b/openapi/paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml
@@ -48,6 +48,8 @@ put:
    responses:
      204:
        $ref: "../../responses/processes-core/rEmpty.yaml"
+     400:
+       $ref: "../../responses/processes-dru/rWorkflowNotFound.yaml"
      403:
        $ref: "../../responses/processes-dru/rImmutableProcess.yaml"
      404:
diff --git a/openapi/paths/processes-dru/pProcessListDeploy.yaml b/openapi/paths/processes-dru/pProcessListDeploy.yaml
index 8b9cfb38..c5c0fadd 100644
--- a/openapi/paths/processes-dru/pProcessListDeploy.yaml
+++ b/openapi/paths/processes-dru/pProcessListDeploy.yaml
@@ -41,6 +41,8 @@ post:
    responses:
      201:
        $ref: "../../schemas/processes-core/processSummary.yaml"
+     400:
+       $ref: "../../responses/processes-dru/rWorkflowNotFound.yaml"
      403:
        $ref: "../../responses/processes-dru/rImmutableProcess.yaml"
      409:
diff --git a/openapi/paths/processes-dru/pReplace.yaml b/openapi/paths/processes-dru/pReplace.yaml
index 36adc337..3c049db8 100644
--- a/openapi/paths/processes-dru/pReplace.yaml
+++ b/openapi/paths/processes-dru/pReplace.yaml
@@ -29,6 +29,8 @@ put:
    responses:
      204:
        $ref: "../../responses/processes-core/rEmpty.yaml"
+     400:
+       $ref: "../../responses/processes-dru/rWorkflowNotFound.yaml"
      403:
        $ref: "../../responses/processes-dru/rImmutableProcess.yaml"
      404:
diff --git a/openapi/schemas/processes-job-management/headers.yaml b/openapi/schemas/processes-job-management/headers.yaml
new file mode 100644
index 00000000..c1ed337f
--- /dev/null
+++ b/openapi/schemas/processes-job-management/headers.yaml
@@ -0,0 +1,3 @@
+type: object
+additionalProperties:
+  type: string
\ No newline at end of file
diff --git a/openapi/schemas/processes-job-management/inputs.yaml b/openapi/schemas/processes-job-management/inputs.yaml
index 88701fe2..245e237f 100644
--- a/openapi/schemas/processes-job-management/inputs.yaml
+++ b/openapi/schemas/processes-job-management/inputs.yaml
@@ -19,3 +19,7 @@ properties:
     type: array
     items:
       $ref: "../processes-core/metadata.yaml"
+  headers:
+    type: array
+    items:
+      $ref: "headers.yaml"
\ No newline at end of file

From b7041fd26e6529925a525c7adbf076786ab63342 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A9rald=20Fenoy?= 
Date: Thu, 14 Nov 2024 15:54:53 +0100
Subject: [PATCH 2/3] Remove unecessary files, typo

---
 .../job_management/standard/._24-051.html     |  Bin 4096 -> 0 bytes
 .../job_management/standard/24-051.err.html   |  757 ------
 .../job_management/standard/24-051.html       | 2386 -----------------
 .../job_management/standard/24-051.pdf.err    |  241 --
 .../standard/24-051.presentation.xml          | 1800 -------------
 extensions/job_management/standard/24-051.xml |  923 -------
 .../prov/PER_content-negotiation.adoc         |    4 +-
 7 files changed, 2 insertions(+), 6109 deletions(-)
 delete mode 100755 extensions/job_management/standard/._24-051.html
 delete mode 100644 extensions/job_management/standard/24-051.err.html
 delete mode 100644 extensions/job_management/standard/24-051.html
 delete mode 100644 extensions/job_management/standard/24-051.pdf.err
 delete mode 100644 extensions/job_management/standard/24-051.presentation.xml
 delete mode 100644 extensions/job_management/standard/24-051.xml

diff --git a/extensions/job_management/standard/._24-051.html b/extensions/job_management/standard/._24-051.html
deleted file mode 100755
index 972984c4aff1959ab793f1015850656f34fa522c..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 4096
zcmZQz6=P>$Vqox1Ojhs@R)|o50+1L3ClDJkFz{^v(m+1nBL)UWIUt(=a103vf+zv$
zU|0ae0uVl&WCXGn05MQpDmgz_FR`E?Csi*evACqPI5j0Du_RSFAQ+_j#%I%X5G{Lh
ziz2B>oSaI9oYb@ug`}Lsylh}!7^-VXQ>gxjdqsvp
H?*D%Pu^}oY

diff --git a/extensions/job_management/standard/24-051.err.html b/extensions/job_management/standard/24-051.err.html
deleted file mode 100644
index 7516e5aa..00000000
--- a/extensions/job_management/standard/24-051.err.html
+++ /dev/null
@@ -1,757 +0,0 @@
-extensions/job_management/standard/24-051.err.html errors
-
-
-
extensions/job_management/standard/24-051.err.html errors

-
-
AsciiDoc Input

-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
_​referencesno anchor on reference, markup may be malformed: seehttps://​www.​metanorma.org/​author/topics/​sections/​bibliography/ ,https://​www.​metanorma.org/​author/iso/​topics/​markup/​#bibliographies
-: ​ Bryan, P., Nottingham, M.: IETF RFC 6902, ​JavaScript Object Notation (JSON) Patch, 2013 
#<Asciidoctor::List@8460 {context: :ulist, style: "bibliography", items: 5}>
1

-
Relaton

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
--Downloaded index from https://​raw.​githubusercontent.com/​relaton/​relaton-data-ogc/main/​index-v1.zip
3
OGC 17-069r3Found: 17-069r3
3
OGC 18-062Found: 18-062r2
3
OGC 20-044Not found.
3
OGC 21-009Not found.
3
OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2 does not have a recognised prefix
3
OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2 does not have a recognised prefix
3

-
Anchors

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
000066_56b07a2e-6f5d-ebf5-a3bd-15a3e1e35665Crossreference target rc_job-management is undefined
<xref target="rc_job-management">Job Management</xref>
1
000086_86bead28-60b4-0781-cecf-c858aa93826fCrossreference target rc_​provenance is undefined
<xref target="rc_provenance">Provenance</xref>
1
000275rc_job-mangementCrossreference target rfc2616 is undefined
<xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref>
1
000593_d9bc2000-cc20-5230-6108-e910ec6796b9Crossreference target rfc2616 is undefined
<xref target="rfc2616">HTTP 1.1</xref>
1
000773_a35f98ae-79c4-cabf-4b34-7df10f32509eCrossreference target deploy-replace-undeploy-http_​status_codes is undefined
<xref target="deploy-replace-undeploy-http_status_codes">HTTP status codes</xref>
1
000800rc_ogcapi-processesCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref>
1
000904rc_openeoCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref>
1
001168ats_jmCrossreference target rc_job-management is undefined
<xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref>
1

-
Style

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
--Preface is missing!
2
000001_​misccontainer_​anchor_aliasesTable should have title
<table id="_misccontainer_anchor_aliases">
-  <tbody>
-    <tr>
-      <th>ats_jm</th>
-      <td>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</td>
2
000034_d723ae37-c7be-e4a9-a3fc-86ffc4a83cb9Table should have title
<table id="_d723ae37-c7be-e4a9-a3fc-86ffc4a83cb9" unnumbered="true"> <thead> <tr> <th valign="middle" align="left">Name</th>
-<th valign="middle" align="left">Affiliation</th>
-</tr> </thead>
-<tbody> <tr> <td valign="middle" align="left">Gérald Fenoy <em>(editor)</em> </td>
-<td valign="middle" align="left">GeoLabs</td>
2
000260job-managementHanging paragraph in clause
<clause id="job-management" obligation="normative">
-<title>Overview</title>
-<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
-</requirement>
-
2
000569_overview_​2Hanging paragraph in clause
<clause id="_overview_2" obligation="normative">
-<title>Overview</title>
-<requirement id="req_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-body</value> </classification> <component class="part"> <p id="_05adf478-66b0-bb00-4ff1-d41511e77fcf">The body of a PATCH request SHALL be in JSON format.</p>
-</component>
-</requirement>
2
000728job-management-definitionHanging paragraph in clause
<clause id="job-management-definition" obligation="normative">
-<title>Job definition</title>
-<p id="_d7f18ae5-2f90-1fb8-76fe-9621df1a7334">For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.</p>
-
-<clause id="_operation_4" obligation="normative">
2
001029_inputsHanging paragraph in clause
<clause id="_inputs" obligation="normative">
-<title>Inputs</title>
-<p id="_7b70acb8-1919-5d25-4608-cf6095ab5153">The server MUST provide an endpoint to retrieve the inputs of a job run.</p>
-
-<clause id="_operation_5" obligation="normative">
2
001064_provHanging paragraph in clause
<clause id="_prov" obligation="normative">
-<title>Prov</title>
-<p id="_21c472f6-0653-e0a5-bccf-680806aac136">The server MUST provide an endpoint to retrieve the provenance of a job.</p>
-
-<clause id="_operation_6" obligation="normative">
2
001160_​conformance_class_​job_​managementHanging paragraph in clause
<clause id="_conformance_class_job_management" obligation="normative">
-<title>Conformance Class Job Management</title>
-<requirement id="ats_jm" model="ogc" type="conformanceclass">
-<title>Job Management</title> <identifier>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</identifier> <subject> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref> </subject> <classification> <tag>Target Type</tag> <value>Web API</value> </classification> <requirement id="_a86d877f-b639-4c33-aaf0-aafbda999bc2" model="ogc" type="verification"> <identifier>/conf/dru/deploy/post-op</identifier> </requirement>
-
2
001207_1af3e526-b98d-61df-00c5-7c89dc3c51a2Table should have title
<table id="_1af3e526-b98d-61df-00c5-7c89dc3c51a2" unnumbered="true"> <colgroup> <col width="12%"/> <col width="18%"/> <col width="12%"/> <col width="12%"/> <col width="46%"/> </colgroup> <thead> <tr> <th valign="middle" align="left">Date</th>
-<th valign="middle" align="left">Release</th>
-<th valign="middle" align="left">Editor</th>
-<th valign="middle" align="left">Primary clauses modified</th>
-<th valign="middle" align="left">Description</th>
2

-
Requirements

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
000262rc_job-mangementProvision rc_job-mangement points to Prerequisite OGC API — ​Processes — ​Part 1: Core, Conformance Class ‘core’ outside this document
-
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
-</requirement>
2
000262rc_job-mangementProvision rc_job-mangement points to Prerequisite RFC 2616 (HTTP/​1.1) outside this document
-
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
-</requirement>
2
000262rc_job-mangementRequirement class rc_job-mangement has no corresponding Conformance class
-
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
-</requirement>
2
000262rc_job-mangementRequirement class rc_job-mangement has no corresponding Requirement
-
<requirement id="rc_job-mangement" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core, Conformance Class ‘core’</eref> </inherit> <inherit> <xref target="rfc2616">RFC 2616 (HTTP/1.1)</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management"/> </value> </classification>
-</requirement>
2
000350per_job-management_​additional-status-codesRequirement per_job-management_​additional-status-codes has no corresponding Conformance test
-
<permission id="per_job-management_additional-status-codes" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/additional-status-codes</value> </classification> <component class="part"> <p id="_68f9b4b5-98ba-065b-7473-169909f0c800">Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in <xref target="status_codes"/>.</p>
-</component>
-</permission>
2
000390req_job-management_create_​post-opRequirement req_job-management_create_​post-op has no corresponding Conformance test
-
<requirement id="req_job-management_create_post-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-post-op</value> </classification> <component class="part"> <p id="_59b20392-f885-485f-3d60-60874d0e69c5">The server SHALL support the HTTP POST operation at the path <tt>/jobs</tt>.</p>
-</component>
-</requirement>
2
000404req_job-management_create_​bodyRequirement req_job-management_create_​body has no corresponding Conformance test
-
<requirement id="req_job-management_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-body</value> </classification> <component class="part"> <p id="_9eada9e6-11fc-b695-6cab-cd3860462ebb">The body of the POST request SHALL be in JSON format.</p>
-</component>
-</requirement>
2
000413per_job-management_create_​bodyRequirement per_job-management_create_​body has no corresponding Conformance test
-
<permission id="per_job-management_create_body" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/create-body</value> </classification> <component class="part"> <p id="_56fcb431-af59-80f5-2c2b-8557db1c1155">A server MAY support any encoding in the body of a HTTP POST operation.</p>
-</component>
-</permission>
2
000422req_job-management_create_​content-typeRequirement req_job-management_create_​content-type has no corresponding Conformance test
-
<requirement id="req_job-management_create_content-type" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-content-type</value> </classification> <component class="part"> <p id="_9d144068-d98a-2172-3d82-11ea53de687b">The <tt>Content-Type</tt> <link target="https://tools.ietf.org/html/rfc2616#section-14.17">header</link> SHALL be used to declare the media type of the request.</p>
-</component>
-</requirement>
2
000433per_job-management_create_​content-schemaRequirement per_job-management_create_​content-schema has no corresponding Conformance test
-
<permission id="per_job-management_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/create-content-schema</value> </classification> <component class="part"> <p id="_ea06a074-ff10-1347-6037-03ec924d5517">The <tt>Content-Schema</tt> header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.</p>
-</component>
-</permission>
2
000445rec_job-management_create_​body-ogcapi-processesRequirement rec_job-management_create_​body-ogcapi-processes has no corresponding Conformance test
-
<recommendation id="rec_job-management_create_body-ogcapi-processes" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/create-body-ogcapi-processes</value> </classification> <component class="part"> <p id="_21e4c515-b1ec-6e86-8d1e-c9d2bbe0e2da">If the job can be encoded as an <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref>, implementation SHOULD consider supporting the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref> encoding.</p>
-</component>
-</recommendation>
2
000457rec_job-management_create_​body-openeoRequirement rec_job-management_create_​body-openeo has no corresponding Conformance test
-
<recommendation id="rec_job-management_create_body-openeo" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/create-body-openeo</value> </classification> <component class="part"> <p id="_b40d2102-36ca-1186-ee28-472de8b30d16">If the job can be encoded as an <xref target="rc_openeo">OpenEO graph</xref>, implementation SHOULD consider supporting the <xref target="rc_openeo">OpenEO graph</xref> encoding.</p>
-</component>
-</recommendation>
2
000470req_job-management_create_​response-jobidRequirement req_job-management_create_​response-jobid has no corresponding Conformance test
-
<requirement id="req_job-management_create_response-jobid" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-jobid</value> </classification> <component class="part"> <p id="_120716a1-2fcd-aefe-f0e8-260f528fa15c">If the operation completes, the server SHALL generate a job identifier (i.e. <tt>{jobId}</tt>) for the created job.</p>
-</component>
-</requirement>
2
000479req_job-management_create_​response_​successRequirement req_job-management_create_​response_​success has no corresponding Conformance test
-
<requirement id="req_job-management_create_response_success" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-success</value> </classification> <component class="part"> <p id="_217f3c95-ce68-0151-7b40-f5ae2f400e4b">A successful execution of the operation SHALL be reported as a response with a HTTP status code <tt>201</tt>.</p>
-</component> <component class="part"> <p id="_8aefb5a1-d845-7e7f-a696-fc8565fef146">A response with HTTP status code <tt>201</tt> SHALL include a <tt>Location</tt> header with the URI of the deployed processes (path: <tt>/jobs/{jobId}</tt>).</p>
-</component>
-</requirement>
2
000491req_job-management_create_​response-bodyRequirement req_job-management_create_​response-body has no corresponding Conformance test
-
<requirement id="req_job-management_create_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-response-body</value> </classification> <component class="part"> <p id="_a717cdef-e9c0-0893-8e0d-d666c5dc5907">The response SHALL include a body that contains a status information of the created job that conforms to the <link target="https://schemas.opengis.net/ogcapi/processes/part1/1.0/openapi/schemas/statusInfo.yaml">statusInfo.yaml</link> schema.</p>
-</component> <component class="part"> <p id="_9d1820bb-ee5b-fabc-cd9e-80282886dfd2">The response SHALL contain a <tt>created</tt> status code and the <tt>id</tt> property that contains the job identifier.</p>
-</component>
-</requirement>
2
000510req_job-management_create_​unsupported-schemaRequirement req_job-management_create_​unsupported-schema has no corresponding Conformance test
-
<requirement id="req_job-management_create_unsupported-schema" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/create-unsupported-schema</value> </classification> <component class="part"> <p id="_fe235e0b-0a77-20de-482a-ce15ddb12610">If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be <tt>422 Unprocessable Content</tt>.</p>
-</component> <component class="part"> <p id="_ecff7330-b3f6-6298-e8d7-0b81c63d4f1d">The content of that response SHALL be based upon the OpenAPI 3.0 schema  <link target="https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/exception.yaml">exception.yaml</link>.</p>
-</component> <component class="part"> <p id="_58f15e2f-0f8e-04e1-fdc1-79fe389ddd90">The <tt>type</tt> of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.</p>
-</component>
-</requirement>
2
000552req_job-management_update_​patch-opRequirement req_job-management_update_​patch-op has no corresponding Conformance test
-
<requirement id="req_job-management_update_patch-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-patch-op</value> </classification> <component class="part"> <p id="_5765e160-3b4b-f86d-3d8f-d13f8c23e7d9">For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.</p>
-</component> <component class="part"> <p id="_b7d85a9c-dff1-a81c-cbea-6e16b88a44df">The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
-</component>
-</requirement>
2
000571req_job-management_update_​bodyRequirement req_job-management_update_​body has no corresponding Conformance test
-
<requirement id="req_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-body</value> </classification> <component class="part"> <p id="_05adf478-66b0-bb00-4ff1-d41511e77fcf">The body of a PATCH request SHALL be in JSON format.</p>
-</component>
-</requirement>
2
000580per_job-management_update_​bodyRequirement per_job-management_update_​body has no corresponding Conformance test
-
<permission id="per_job-management_update_body" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/update-body</value> </classification> <component class="part"> <p id="_d716a117-40e2-ac55-f5bc-c9af59d8fbe6">A server MAY support any encoding in the body of a HTTP PATCH operation.</p>
-</component>
-</permission>
2
000589req_job-management_update_​content-typeRequirement req_job-management_update_​content-type has no corresponding Conformance test
-
<requirement id="req_job-management_update_content-type" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-content-type</value> </classification> <component class="part"> <p id="_d9bc2000-cc20-5230-6108-e910ec6796b9">As per <xref target="rfc2616">HTTP 1.1</xref> (<link target="https://tools.ietf.org/html/rfc2616#section-14.17"/>) the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.</p>
-</component>
-</requirement>
2
000598per_job-management_update_​content-schemaRequirement per_job-management_update_​content-schema has no corresponding Conformance test
-
<permission id="per_job-management_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/job-management/update-content-schema</value> </classification> <component class="part"> <p id="_16d37cee-0841-4288-ca0d-8cd4672121c9">The <tt>Content-Schema</tt> header MAY be used to indicate the schema of a request body for updating a job.</p>
-</component>
-</permission>
2
000609rec_job-management_update-ogcapi-processesRequirement rec_job-management_update-ogcapi-processes has no corresponding Conformance test
-
<recommendation id="rec_job-management_update-ogcapi-processes" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/update-body-ogcapi-processes</value> </classification> <component class="part"> <p id="_67a207fd-d9a2-a735-bc26-54a4bf15ab28">If a job can be created from an <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref>, implementations SHOULD consider supporting the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow Execute Request</xref> encoding.</p>
-</component>
-</recommendation>
2
000621rec_job-management_update-openeoRequirement rec_job-management_update-openeo has no corresponding Conformance test
-
<recommendation id="rec_job-management_update-openeo" model="ogc"> <classification> <tag>label</tag> <value>/rec/job-management/update-body-openeo</value> </classification> <component class="part"> <p id="_16a2a097-005c-3bef-61a6-62474908c4e4">If a job can be created from an <xref target="rc_openeo">OpenEO Process Graph</xref>, implementations SHOULD consider supporting the <xref target="rc_openeo">OpenEO Process Graph</xref> encoding.</p>
-</component>
-</recommendation>
2
000634req_job-management_update_​responseRequirement req_job-management_update_​response has no corresponding Conformance test
-
<requirement id="req_job-management_update_response" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-response</value> </classification> <component class="part"> <p id="_f4007821-8d26-0559-e45b-b6385e13a710">A successful execution of the operation SHALL be reported as a response with a HTTP status code <tt>200</tt> or <tt>204</tt>.</p>
-</component>
-</requirement>
2
000654req_job-management_update_​response-lockedRequirement req_job-management_update_​response-locked has no corresponding Conformance test
-
<requirement id="req_job-management_update_response-locked" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/update-response-locked</value> </classification> <component class="part"> <p id="_849aaff6-e15c-b002-5fb2-b358cbb7227b">If a job is locked, meaning that it is currently being processed (status set to <tt>accepted</tt> or <tt>running</tt>), the server SHALL respond with HTTP status code <tt>423 Locked</tt>.</p>
-</component> <component class="part"> <p id="_11452159-22bd-60f4-4530-ed85f966408d">The response body SHALL be based upon the OpenAPI 3.0 schema <link target="https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/exception.yaml">exception.yaml</link>.</p>
-</component> <component class="part"> <p id="_18e34c4f-05f1-8950-9559-26a3f570c035">The <tt>type</tt> of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.</p>
-</component>
-</requirement>
2
000690req_job-management_start_​post-opRequirement req_job-management_start_​post-op has no corresponding Conformance test
-
<requirement id="req_job-management_start_post-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/start-post-op</value> </classification> <component class="part"> <p id="_a93fd6ec-bfcc-87d0-2e65-50946f1dfa25">For every created jobs (path: <tt>/jobs/{jobId}/results</tt>), the server SHALL support the HTTP POST operation.</p>
-</component> <component class="part"> <p id="_8436153b-6dc8-bea6-a88a-620e448adf62">The parameter <tt>jobId</tt> is each <tt>jobID</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
-</component>
-</requirement>
2
000705req_job-management_start_​responseRequirement req_job-management_start_​response has no corresponding Conformance test
-
<requirement id="req_job-management_start_response" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/start-response</value> </classification> <component class="part"> <p id="_bfd626f2-403f-eaea-72c4-0cd09f7f4d04">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
-</component> <component class="part"> <p id="_0dc83efb-3525-4df8-e7fa-b5648b3c4609">A response SHALL be a document that conforms to statusInfo.yaml.</p>
-</component>
-</requirement>
2
000734req_job-management_​definition_get-opRequirement req_job-management_​definition_get-op has no corresponding Conformance test
-
<requirement id="req_job-management_definition_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-get-op</value> </classification> <component class="part"> <p id="_f8343c8c-67a6-5853-89bb-4b924e0a0c7c">For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path <tt>/jobs/{jobId}/definition</tt>.</p>
-</component> <component class="part"> <p id="_ac22c114-f460-53f1-0b37-b3ce1437ce56">The parameter <tt>jobId</tt> is each <tt>id</tt> property in the job-list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
-</component>
-</requirement>
2
000751req_job-management_​definition_​response-successRequirement req_job-management_​definition_​response-success has no corresponding Conformance test
-
<requirement id="req_job-management_definition_response-success" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-response-success</value> </classification> <component class="part"> <p id="_a711b14a-7976-bbb2-20e3-d97c7c898cd5">A successful access to the resource SHALL be reported as a response with a HTTP status code <tt>200</tt>.</p>
-</component>
-</requirement>
2
000760req_job-management_​definition_​response-bodyRequirement req_job-management_​definition_​response-body has no corresponding Conformance test
-
<requirement id="req_job-management_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/job-management/definition-response-body</value> </classification> <component class="part"> <p id="_52f35875-3584-1c6c-85f4-6a450ca422bc">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the request body used to create or update the job.</p>
-</component>
-</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite OGC API — ​Processes — ​Part 1: Core outside this document
-
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
-</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite OGC API — ​Processes — ​Part 3: Workflows, Conformance Class ‘nested-processing’ outside this document
-
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
-</requirement>
2
000784rc_ogcapi-processesProvision rc_​ogcapi-processes points to Prerequisite http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​req/job-management outside this document
-
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
-</requirement>
2
000784rc_ogcapi-processesRequirement class rc_​ogcapi-processes has no corresponding Conformance class
-
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
-</requirement>
2
000784rc_ogcapi-processesRequirement class rc_​ogcapi-processes has no corresponding Requirement
-
<requirement id="rc_ogcapi-processes" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <inherit> <eref type="inline" bibitemid="OAProc-3" citeas="OGC 21-009">OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’</eref> </inherit> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes"/> </value> </classification>
-</requirement>
2
000812req_​ogcapi-processes_schemaRequirement req_​ogcapi-processes_schema has no corresponding Conformance test
-
<requirement id="req_ogcapi-processes_schema" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/schema</value> </classification> <component class="part"> <p id="_055e7b96-29a0-5380-0b91-38af56973b63">An <tt>OGC API - Processes - Workflow - Execute Request</tt> document SHALL be based upon the JSON schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflow.yaml</link>.</p>
-</component>
-</requirement>
2
000827req_​ogcapi-processes_create_​bodyRequirement req_​ogcapi-processes_create_​body has no corresponding Conformance test
-
<requirement id="req_ogcapi-processes_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/create-body</value> </classification> <component class="part"> <p id="_75888451-6c79-eddd-65b7-cc780518339b">The body of the POST request SHALL be based upon the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link> </p>
-</component> <component class="part"> <p id="_01239b62-2694-e6b9-5971-dfe78f1037ea">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a processes description encoded as an <xref target="rc_ogcapi-processes">OGC API — Processes</xref>.</p>
-</component>
-</requirement>
2
000839per_​ogcapi-processes_create_​content-schemaRequirement per_​ogcapi-processes_create_​content-schema has no corresponding Conformance test
-
<permission id="per_ogcapi-processes_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/ogcapi-processes/create-content-schema</value> </classification> <component class="part"> <p id="_b7a060ab-25d5-fdcc-67a8-104e19c5bd6d">The <tt>Content-Schema</tt> header MAY be pointing to the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link>.</p>
-</component>
-</permission>
2
000854req_​ogcapi-processes_update__​bodyRequirement req_​ogcapi-processes_update__​body has no corresponding Conformance test
-
<requirement id="req_ogcapi-processes_update__body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/update-body</value> </classification> <component class="part"> <p id="_611bbb8b-c9fa-bbef-e5c6-cef9ae1b9952">The media type <tt>application/ogcapi-processes+json</tt> SHALL be used to indicate that request body contains a job encoded as an <xref target="rc_openeo">OpenEO</xref>.</p>
-</component>
-</requirement>
2
000863per_​ogcapi-processes_update_​content-schemaRequirement per_​ogcapi-processes_update_​content-schema has no corresponding Conformance test
-
<permission id="per_ogcapi-processes_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/ogcapi-processes/update-content-schema</value> </classification> <component class="part"> <p id="_a595adf4-05cf-ff64-7335-c84d8a299ba7">The <tt>Content-Schema</tt> header MAY be pointing to the OpenAPI 3.0 schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-workflows/execute-workflows.yaml">execute-workflows.yaml</link>.</p>
-</component>
-</permission>
2
000878req_​ogcapi-processes_​definition_​response-bodyRequirement req_​ogcapi-processes_​definition_​response-body has no corresponding Conformance test
-
<requirement id="req_ogcapi-processes_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/ogcapi-processes/definition-response-body</value> </classification> <component class="part"> <p id="_5bdd268e-40d8-4c3b-5a25-a54dfb85dea5">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the <xref target="rc_ogcapi-processes">OGC API — Processes — Workflow — Execute Request</xref> to use to deploy the process.</p>
-</component>
-</requirement>
2
000894rc_openeoProvision rc_​openeo points to Prerequisite http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​req/job-management outside this document
-
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
-</requirement>
2
000894rc_openeoRequirement class rc_​openeo has no corresponding Conformance class
-
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
-</requirement>
2
000894rc_openeoRequirement class rc_​openeo has no corresponding Requirement
-
<requirement id="rc_openeo" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management</xref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo"/> </value> </classification>
-</requirement>
2
000916req_​openeo_schemaRequirement req_​openeo_schema has no corresponding Conformance test
-
<requirement id="req_openeo_schema" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/schema</value> </classification> <component class="part"> <p id="_b547b858-02be-9df8-f006-9b81b930fe3c">An <tt>OpenEO Process Graph</tt> document SHALL be based upon the OpenEO Process Graph JSON schema <link target="https://openeo.org/documentation/1.0/developers/api/assets/pg-schema.json"/>.</p>
-</component>
-</requirement>
2
000945req_​openeo_create_​bodyRequirement req_​openeo_create_​body has no corresponding Conformance test
-
<requirement id="req_openeo_create_body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/create-body</value> </classification> <component class="part"> <p id="_c03efe59-3bdd-80dd-8068-f491b4769083">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a processes description encoded as an <xref target="rc_openeo">OpenEO Process Graph</xref>.</p>
-</component>
-</requirement>
2
000954per_​openeo_create_​content-schemaRequirement per_​openeo_create_​content-schema has no corresponding Conformance test
-
<permission id="per_openeo_create_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/openeo/create-content-schema</value> </classification> <component class="part"> <p id="_dd2a38a1-1801-ea40-b40b-9306ffe963f5">The <tt>Content-Schema</tt> header MAY be pointing to <link target="https://raw.githubusercontent.com/Open-EO/openeo-processes/master/meta/subtype-schemas.json#/definitions/process-graph">OpenEO Process Graph schema</link>.</p>
-</component>
-</permission>
2
000969req_​openeo_update__​bodyRequirement req_​openeo_update__​body has no corresponding Conformance test
-
<requirement id="req_openeo_update__body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/update-body</value> </classification> <component class="part"> <p id="_d6d4d725-2e03-023e-6461-60f14e3dad00">The media type <tt>application/json</tt> SHALL be used to indicate that request body contains a job encoded as an <xref target="rc_openeo">OpenEO Process Graph</xref>.</p>
-</component>
-</requirement>
2
000978per_​openeo_update_​content-schemaRequirement per_​openeo_update_​content-schema has no corresponding Conformance test
-
<permission id="per_openeo_update_content-schema" model="ogc"> <classification> <tag>label</tag> <value>/per/openeo/update-content-schema</value> </classification> <component class="part"> <p id="_d50f6b34-5c18-28c4-e3b4-e4bee8fb8ef3">The <tt>Content-Schema</tt> header MAY be pointing to <link target="https://raw.githubusercontent.com/Open-EO/openeo-processes/master/meta/subtype-schemas.json#/definitions/process-graph">OpenEO Process Graph schema</link>.</p>
-</component>
-</permission>
2
000993req_​openeo_​definition_​response-bodyRequirement req_​openeo_​definition_​response-body has no corresponding Conformance test
-
<requirement id="req_openeo_definition_response-body" model="ogc"> <classification> <tag>label</tag> <value>/req/openeo/definition-response-body</value> </classification> <component class="part"> <p id="_e853fc8d-2e27-66d9-4e92-f94a581748c2">A response with HTTP status code <tt>200</tt> SHALL include a body that contains the <xref target="rc_openeo">OpenEO Process Graph</xref> to use to deploy the process.</p>
-</component>
-</requirement>
2
001011rc_cwlProvision rc_cwl points to Prerequisite OGC API — ​Processes — ​Part 1: Core outside this document
-
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
-</requirement>
2
001011rc_cwlRequirement class rc_cwl has no corresponding Conformance class
-
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
-</requirement>
2
001011rc_cwlRequirement class rc_cwl has no corresponding Requirement
-
<requirement id="rc_cwl" model="ogc" type="class" obligation="requirement"> <subject>Web API</subject> <inherit> <eref type="inline" bibitemid="OAProc-1" citeas="OGC 18-062r2">OGC API — Processes — Part 1: Core</eref> </inherit> <classification> <tag>label</tag> <value> <link target="http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance"/> </value> </classification>
-</requirement>
2
001035req_job-provenance_inputs_​get-opRequirement req_job-provenance_inputs_​get-op has no corresponding Conformance test
-
<requirement id="req_job-provenance_inputs_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/inputs-get-op</value> </classification> <component class="part"> <p id="_d27b2f4a-46fe-e7a7-381a-3ef7f6992a3c">For every created jobs (path: <tt>/jobs/{jobId}/inputs</tt>), the server SHALL support the HTTP GET operation.</p>
-</component> <component class="part"> <p id="_a345c40a-d33e-e3cf-3ced-8f913b19061a">The parameter <tt>jobId</tt> is each <tt>jobID</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
-</component>
-</requirement>
2
001050req_​provenance_​inputs_​responseRequirement req_​provenance_​inputs_​response has no corresponding Conformance test
-
<requirement id="req_provenance_inputs_response" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/inputs-response</value> </classification> <component class="part"> <p id="_e9c66c92-5cc7-d756-9380-557ef120ef46">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
-</component> <component class="part"> <p id="_3494a24c-e31d-ae3c-e69f-870d5b2c7b1f">The response SHALL contains a JSON document that conforms to the schema <link target="https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-job-management/inputs.yaml">inputs.yaml</link>.</p>
-</component>
-</requirement>
2
001070req_job-provenance_prov_​get-opRequirement req_job-provenance_prov_​get-op has no corresponding Conformance test
-
<requirement id="req_job-provenance_prov_get-op" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/prov-get-op</value> </classification> <component class="part"> <p id="_05bee4f3-96a3-3cce-7f1f-bd4c27d62d2b">For every created jobs (path: <tt>/jobs/{jobId}/prov</tt>), the server SHALL support the HTTP GET operation.</p>
-</component> <component class="part"> <p id="_739e0c7c-5b29-f5cd-1dee-df8657a543c4">The parameter <tt>{jobId}</tt> is each <tt>id</tt> property in the job list response (JSONPath: <tt>$.jobs[*].id</tt>).</p>
-</component>
-</requirement>
2
001082per_job-provenance_run_​content-negotiationRequirement per_job-provenance_run_​content-negotiation has no corresponding Conformance test
-
<permission id="per_job-provenance_run_content-negotiation" model="ogc"> <classification> <tag>label</tag> <value>/per/provenance/run-content-negotiation</value> </classification> <component class="part"> <p id="_b966ac06-48ee-fd02-42ce-3cf08626284b">Content negotiation MAY be supported to provide alternate representations of the response.</p>
-</component> <component class="part"> <p id="_45871990-3a83-68b4-bfad-9867a122efa5">The server MAY support the following additional content type: <tt>application/ld+json</tt> for PROV-O as JSON-LD</p>
-</component> <component class="part"> <p id="_92f4d43e-d24a-0a26-7955-80f1674a1c99">The server MAY support the following additional content type: <tt>application/xml</tt> for PROV-XML</p>
-</component> <component class="part"> <p id="_a65968fc-deee-e0f6-c8e0-e101f4d89ed4">The server MAY support the following additional content type: <tt>text/provenance-notation; charset="UTF-8"</tt> for PROV-N.</p>
-</component>
2
001103req_​provenance_prov_​responseRequirement req_​provenance_​prov_response has no corresponding Conformance test
-
<requirement id="req_provenance_prov_response" model="ogc"> <classification> <tag>label</tag> <value>/req/provenance/prov-response</value> </classification> <component class="part"> <p id="_ecc83e9d-6eef-d592-a0b2-7608331e339c">A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.</p>
-</component> <component class="part"> <p id="_815d65be-9385-0e4a-4be7-1dcb0d5d41c7">Per default, the response SHALL contains a JSON document that conforms to the <link target="https://www.w3.org/submissions/prov-json/schema">schema for PROV-JSON</link>.</p>
-</component> <component class="part"> <p id="_f8fa4c50-f38c-e314-3262-6ef9c84bb780">In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.</p>
-</component>
-</requirement>
2
001162ats_jmConformance class http://​www.opengis.​net/spec/​ogcapi-processes-4/1.0/​conf/job-management has no corresponding Requirement class
-
<requirement id="ats_jm" model="ogc" type="conformanceclass">
-<title>Job Management</title> <identifier>http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</identifier> <subject> <xref target="rc_job-management">http://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management</xref> </subject> <classification> <tag>Target Type</tag> <value>Web API</value> </classification> <requirement id="_a86d877f-b639-4c33-aaf0-aafbda999bc2" model="ogc" type="verification"> <identifier>/conf/dru/deploy/post-op</identifier> </requirement>
-
-</requirement>
2
001181ats_jm_​deploy_post-opConformance test /conf/jm/​create/​post-op has no corresponding Conformance class
-
<requirement id="ats_jm_deploy_post-op" model="ogc" type="abstracttest"> <identifier>/conf/jm/create/post-op</identifier> <classification> <tag>target</tag> <value> <xref target="req_job-management_create_post-op">/req/job-management/create-post-op</xref> </value> </classification> <component class="test-purpose"> <p id="_cc03f424-278b-0166-2639-4f077846924c">Validate that the server support HTTP POST operation at the path /jobs/</p>
-</component> <component class="test-method"> <ol id="_8869dbb8-db35-c3f4-fc88-7b4faed37dd4" type="arabic"> <li> <p id="_e09e3851-35f0-f0ea-17a8-fddcc8354223">Construct a path for the {root}/jobs path.</p>
-</li>
-<li> <p id="_fc72724e-f13a-c143-3f82-e72502e115b7">Issue an HTTP POST request for each path.</p>
-</li>
2
001181ats_jm_​deploy_post-opConformance test /conf/jm/​create/​post-op has no corresponding Requirement
-
<requirement id="ats_jm_deploy_post-op" model="ogc" type="abstracttest"> <identifier>/conf/jm/create/post-op</identifier> <classification> <tag>target</tag> <value> <xref target="req_job-management_create_post-op">/req/job-management/create-post-op</xref> </value> </classification> <component class="test-purpose"> <p id="_cc03f424-278b-0166-2639-4f077846924c">Validate that the server support HTTP POST operation at the path /jobs/</p>
-</component> <component class="test-method"> <ol id="_8869dbb8-db35-c3f4-fc88-7b4faed37dd4" type="arabic"> <li> <p id="_e09e3851-35f0-f0ea-17a8-fddcc8354223">Construct a path for the {root}/jobs path.</p>
-</li>
-<li> <p id="_fc72724e-f13a-c143-3f82-e72502e115b7">Issue an HTTP POST request for each path.</p>
-</li>
2

-
Document Attributes

-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
--draft is not an allowed status for standard
2

-
Metanorma XML Syntax

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LineIDMessageContextSeverity
XML Line 000005:247character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000005:293character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000005:341character content of element "on" invalid; must be a string matching the regular expression "([\+\-]?​\d{4})((-?)((0[1-9]|1[0-2])((-?)([12]​\d|0[1-9]|3[01]​))?|W([0-4]\d|5[0-2])(-?[1-7])?​|(00[1-9]|0[1-9]\d|[12]​\d{2}|3([0­-5]\d|6[1-6]))))?"
2
XML Line 000015:254element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000019:170element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000021:154element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000023:159element "eref" missing required attributes "bibitemid" and "citeas"
2
XML Line 000025:13element "admonition" missing required attribute "type"
2
XML Line 000028:113text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:121element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:139text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:147element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:162text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:170element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:188text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:196element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:210text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:218element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:235text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:243element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:260text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:268element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:285text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:293element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:307text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:315element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:332text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:340element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:355text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:363element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:379text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:387element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:402text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:410element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:427text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:435element "keyword" incomplete; missing required element "taxon"
2
XML Line 000028:532element "ext" incomplete; missing required element "editorialgroup"
2
XML Line 000028:86text not allowed here; expected element "taxon" or "vocab"
2
XML Line 000028:94element "keyword" incomplete; missing required element "taxon"
2
XML Line 000079:104element "clause" not allowed here; expected element "foreword"
2
XML Line 000096:39element "submitters" not allowed yet; missing required element "foreword"
2
XML Line 000132:131IDREF "rc_job-management" without matching ID
2
XML Line 000150:204IDREF "rc_​provenance" without matching ID
2
XML Line 000162:60element "clause" not allowed here; expected the element end-tag or element "admonition", "amend", "bookmark", "columnbreak", "definitions", "dl", "example", "figure",​ "form", "formula", "hr", "imagemap", "note", "ol", "p", "pagebreak", "passthrough", "permission", "pre", "quote", "recommendation", "requirement", "review",​ "sourcecode", "svgmap",​ "table", "term", "terms", "toc" or "ul"
2
XML Line 000170:15element "definitions" incomplete; missing required element "dl"
2
XML Line 000181:294IDREF "rfc2616" without matching ID
2
XML Line 000181:455element "link" not allowed here; expected the element end-tag or text
2
XML Line 000401:274IDREF "rfc2616" without matching ID
2
XML Line 000519:108IDREF "deploy-replace-undeploy-http_​status_codes" without matching ID
2
XML Line 000530:446IDREF "rc_job-management" without matching ID
2
XML Line 000530:659element "link" not allowed here; expected the element end-tag or text
2
XML Line 000590:148IDREF "rc_job-management" without matching ID
2
XML Line 000590:351element "link" not allowed here; expected the element end-tag or text
2
XML Line 000665:347element "link" not allowed here; expected the element end-tag or text
2
XML Line 000752:167IDREF "rc_job-management" without matching ID
2
XML Line 000758:211element "xref" not allowed here; expected the element end-tag or text
2
XML Line 000835:61attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 000844:72found attribute "format",​ but no attributes allowed here
2
XML Line 000845:72found attribute "format",​ but no attributes allowed here
2
XML Line 000901:61attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 000908:51found attribute "format",​ but no attributes allowed here
2
XML Line 000909:8element "link" missing required attribute "target"
2
XML Line 000913:370element "link" missing required attribute "target"
2
XML Line 000913:51found attribute "format",​ but no attributes allowed here
2
XML Line 000916:116element "link" missing required attribute "target"
2
XML Line 000916:51found attribute "format",​ but no attributes allowed here
2

-
diff --git a/extensions/job_management/standard/24-051.html b/extensions/job_management/standard/24-051.html
deleted file mode 100644
index 71172760..00000000
--- a/extensions/job_management/standard/24-051.html
+++ /dev/null
@@ -1,2386 +0,0 @@
-
-
-OGC API - Processes - Part 4: Job Management
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

-    
Draft

-

-
-

-    
OGC Standard

-

-
-
-
-  
 • 

-
-  

-
-
-  

-    

-
-  

-
-    

-      OGC API - Processes - Part 4: Job Management
-      
-    

-  

-
-  
-
-  
-
-  

-    
-    
-    
-
-    
-    
-    Gérald Fenoy Editor
-    
-    
-  

-
-    

-      Submission Date:  yyyy-mm-dd
-      Approval Date:  yyyy-mm-dd
-      Publication Date:  yyyy-mm-dd
-      External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-processes-4/1.0
-      Internal identifier of this OGC® document: 24-051
-      
-      
-    

-
-    

-      
-      Version:  1.0

-      
-    
-    

-
-  

-
-    

-
-  

-  

-    OGC Standard
-  

-
-  

-    
Draft

-  

-

-
-  

-    

-
-
Notice for Drafts

-
-
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

-
-
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

-

-

- 

-         
-
-
-

-  
-    
-    
-    
-    
-    
-  
Document number:24-051
Document type:OGC Standard
Document subtype:Implementation
Document stage:Draft
Document language:English

-

-
-

-

-  

-
-
Copyright notice

-
-
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visithttps://www.ogc.org/legal

-

-
-
Note

-
-
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

-
-
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

-

-

-

-
-

-

-  

-


-  

-
-
License Agreement

-
-
Use of this document is subject to the license agreement at https://www.ogc.org/license

-

-

-
-
-

-
-

-
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://ogc.standardstracker.org/

-

-

-
-
-

-
-
-
-
-

-


-
-
-
-
-
-
-


I.  Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to …​
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
CAUTION
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

-
II.  Keywords
The following are keywords to be used by search engines and document catalogues.
process, instance, spatial, data, openapi, job, create, update, delete, add, remove, REST, PATCH, POST, DELETE
III.  Security Considerations
See OGC API — Processes — Part 1: Core, Clause 10.4.
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.
Users making modifications to job resources need to:
  1. Be authenticated,
    
-
    2. 
-
  2. Have “modification privileges” on the jobs offered through the API,
    
-
    3. 
-
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
-
    4. 
-
The API definition, as defined in Clause 7.3 from OGC 18-062r2, must reflect this in the resource paths and their available methods.
IV.  Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
  • Geolabs
    • 
-
  • Terradue Srl.
    • 
-
  • Computer Research Institute of Montréal (CRIM).
V.  Submitters
All questions regarding this submission should be directed to the editors or the submitters:
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.
1.  Scope
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [OGC 18-062r2] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.
Specifically, the Processes Part 4 Standard specifies:
  • How to manage job.
    
-
    • 
-
  • How to handle provenenance information associated with a job.
    
-
    • 
-
2.  Conformance
The OGC API — Processes — Part 4 Standard defines the following requirements classes.
The main requirements class is:
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.
The standardization target for all Conformance class defined in this Standard is “Web API”.
Conformance with this Standard shall be checked using all the relevant tests specified in  Annex A 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.
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.

-
-
Benjamin Pross, Panagiotis (Peter) A. Vretanos: OGC 18-062r2, OGC API — Processes — Part 1: Core. Open Geospatial Consortium (2021). http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0.

-
Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, Undeploy

-
Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: Workflows

-
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0.

-
4.  Terms, definitions and abbreviated terms

-
No terms and definitions are listed in this document.

-
-
4.1.  Terms and definitions

-
-
See OGC 18-062r2, Clause 4.1.

-

-
-
4.2.  Abbreviated terms

-
-
See OGC 18-062r2, Clause 4.2.

-
5.  Conventions and background
See OGC 18-062r2, Clause 5.
6.  Requirements Class “Job Management”
6.1.  Overview

-
-
Requirements class 1
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core, Conformance Class ‘core’
RFC 2616 (HTTP/1.1)
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management

-
-
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

-
-
The HTTP POST method on the /jobs path is used on to create new jobs.

-
-
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

-
-
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

-
-
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

-
-

-
-
6.1.1.  HTTP status codes

-
-
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

-
-
The Status Codes listed in Table 1 are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in Table 1 are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

-
-
Table 1 — Typical HTTP status codes
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.
NOTE:    Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

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

-
-
Permission 1
Label/per/job-management/additional-status-codes
A
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in Table 1.

-

-
-
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

-

-
-
-
6.2.  Creating a new job

-
-
6.2.1.  Sequence diagram

-
-
The following diagram illustrates the sequence diagram for deploying a new process to the API:

-
-
 
Client                                                        Server
  |                                                             |
  |  POST /jobs   HTTP/1.1                                      |
  |  Content-Type: application/json                             |
  |                                                             |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 201 Created                                       |
  |  Location: /jobs/{jobId}                                    |
  |<------------------------------------------------------------|
Listing 1

-
-

-
-
6.2.2.  Operation

-
-
Requirement 1
Label/req/job-management/create-post-op
A
The server SHALL support the HTTP POST operation at the path /jobs.

-

-

-
-
6.2.3.  Request body

-
-
6.2.3.1.  Overview

-
-
Requirement 2
Label/req/job-management/create-body
A
The body of the POST request SHALL be in JSON format.

-

-
-
Permission 2
Label/per/job-management/create-body
A
A server MAY support any encoding in the body of a HTTP POST operation.

-

-
-
Requirement 3
Label/req/job-management/create-content-type
A
The Content-Type header SHALL be used to declare the media type of the request.

-

-
-
See section 3.1.1.5 of RFC 7231 for details.

-
-
Permission 3
Label/per/job-management/create-content-schema
A
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

-

-

-
-
6.2.3.2.  OGC API — Processes — Workflow Execute Request body

-
-
Recommendation 1
Label/rec/job-management/create-body-ogcapi-processes
A
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-

-

-
-
6.2.3.3.  OpenEO Process Graph body

-
-
Recommendation 2
Label/rec/job-management/create-body-openeo
A
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

-

-

-

-
-
6.2.4.  Response

-
-
Requirement 4
Label/req/job-management/create-response-jobid
A
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

-

-
-
Requirement 5
Label/req/job-management/create-response-success
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

-
B
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

-

-
-
Requirement 6
Label/req/job-management/create-response-body
A
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

-
B
The response SHALL contain a created status code and the id property that contains the job identifier.

-

-

-
-
6.2.5.  Exceptions

-
-
See Clause 6.1.1 for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

-
-
Requirement 7
Label/req/job-management/create-unsupported-schema
A
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

-
B
The content of that response SHALL be based upon the OpenAPI 3.0 schema  exception.yaml.

-
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.

-

-

-
6.3.  Updating an existing job

-
-
6.3.1.  Sequence diagram

-
-
The following diagram illustrates the sequence diagram for updating a
-previously created job.  The identifier of the job does not change.
NOTE:    The new job definition replaces the old job definition. Version control is not discussed in this Standard.

-
-
-
-
 
Client                                                        Server
  |                                                             |
  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
  |  Content-Type: application/json                             |
  |                                                             |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 200 OK                                            |
  |<------------------------------------------------------------|
Listing 2

-
-

-
-
6.3.2.  Operation

-
-
Requirement 8
Label/req/job-management/update-patch-op
A
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

-
B
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

-

-

-
-
6.3.3.  Request body

-
-

-
-
6.3.4.  Overview

-
-
Requirement 9
Label/req/job-management/update-body
A
The body of a PATCH request SHALL be in JSON format.

-

-
-
Permission 4
Label/per/job-management/update-body
A
A server MAY support any encoding in the body of a HTTP PATCH operation.

-

-
-
Requirement 10
Label/req/job-management/update-content-type
A
As per HTTP 1.1 (https://tools.ietf.org/html/rfc2616#section-14.17) the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

-

-
-
Permission 5
Label/per/job-management/update-content-schema
A
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

-

-
-
6.3.4.1.  OGC API — Processes — Workflow Execute Request

-
-
Recommendation 3
Label/rec/job-management/update-body-ogcapi-processes
A
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-

-

-
-
6.3.4.2.  OpenEO Process Graph

-
-
Recommendation 4
Label/rec/job-management/update-body-openeo
A
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

-

-

-

-
-
6.3.5.  Response

-
-
Requirement 11
Label/req/job-management/update-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

-

-
-
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

-

-
-
6.3.6.  Exceptions

-
-
See Clause 6.1.1 for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-
-
Requirement 12
Label/req/job-management/update-response-locked
A
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

-
B
The response body SHALL be based upon the OpenAPI 3.0 schema exception.yaml.

-
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.

-

-

-
6.4.  Staring a job

-
-
6.4.1.  Sequence diagram

-
-
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

-
-
 
Client                                                        Server
  |                                                             |
  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
  |------------------------------------------------------------>|
  |                                                             |
  |  HTTP/1.1 200 OK                                            |
  |<------------------------------------------------------------|
Listing 3

-
-

-
-
6.4.2.  Operation

-
-
Requirement 13
Label/req/job-management/start-post-op
A
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

-
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-

-

-
-
6.4.3.  Response

-
-
Requirement 14
Label/req/job-management/start-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
A response SHALL be a document that conforms to statusInfo.yaml.

-

-

-
-
6.4.4.  Exceptions

-
-
See HTTP status codes for general guidance.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-
-
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from Clause 6.3.

-

-
6.5.  Job definition

-
-
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

-
-
6.5.1.  Operation

-
-
Requirement 15
Label/req/job-management/definition-get-op
A
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

-
B
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

-

-

-
-
6.5.2.  Response

-
-
6.5.2.1.  Overview

-
-
Requirement 16
Label/req/job-management/definition-response-success
A
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

-

-
-
Requirement 17
Label/req/job-management/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

-

-

-

-
-
6.5.3.  Exceptions

-
-
See HTTP status codes for general guidance.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-

-
7.  Requirements Class “OGC API — Process — Workflow Execute Request”
7.1.  Overview

-
-
Requirements class 2
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core
OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’
http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/ogcapi-processes

-
-
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

-
7.2.  OGC API — Processes — Workflow Execute Request

-
-
7.2.1.  Overview

-
-
Requirement 18
Label/req/ogcapi-processes/schema
A
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

-

-

-
7.3.  Creating a new job

-
-
7.3.1.  Request body

-
-
Requirement 19
Label/req/ogcapi-processes/create-body
A
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

-
B
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

-

-
-
Permission 6
Label/per/ogcapi-processes/create-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-

-

-
7.4.  Updating an existing job

-
-
7.4.1.  Request body

-
-
Requirement 20
Label/req/ogcapi-processes/update-body
A
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

-

-
-
Permission 7
Label/per/ogcapi-processes/update-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-

-

-
7.5.  Job definition

-
-
7.5.1.  Response content

-
-
Requirement 21
Label/req/ogcapi-processes/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

-

-

-
8.  Requirements Class “OpenEO Process Graph”
8.1.  Overview

-
-
Requirements class 3
Obligationrequirement
Target typeWeb API
Prerequisitehttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/openeo

-
-
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

-
8.2.  OpenEO Process Graph

-
-
8.2.1.  Overview

-
-
Requirement 22
Label/req/openeo/schema
A
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema https://openeo.org/documentation/1.0/developers/api/assets/pg-schema.json.

-

-
-
 


type: object
additionalProperties:
  type: object
  required: 
    - process_id
    - arguments
  properties:
    process_id:
      type: string
    arguments: {}
Listing 4 —
-  Schema for OpenEO Process Graph
-

-
-

-
8.3.  Creating a new job

-
-
8.3.1.  Request body

-
-
Requirement 23
Label/req/openeo/create-body
A
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

-

-
-
Permission 8
Label/per/openeo/create-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-

-

-
8.4.  Updating an existing job

-
-
8.4.1.  Request body

-
-
Requirement 24
Label/req/openeo/update-body
A
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

-

-
-
Permission 9
Label/per/openeo/update-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-

-

-
8.5.  Job definition

-
-
8.5.1.  Response content

-
-
Requirement 25
Label/req/openeo/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

-

-

-
9.  Requirements Class “Provenance”
9.1.  Overview

-
-
This requirements class defines how to allow client application accessing the provenance of a job run.

-
-
Requirements class 4
Obligationrequirement
Target typeWeb API
PrerequisiteOGC API — Processes — Part 1: Core
Labelhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/provenance

-
9.2.  Additional endpoints

-
-
9.2.1.  Inputs

-
-
The server MUST provide an endpoint to retrieve the inputs of a job run.

-
-
9.2.1.1.  Operation

-
-
Requirement 26
Label/req/provenance/inputs-get-op
A
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

-
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-

-

-
-
9.2.1.2.  Response

-
-
Requirement 27
Label/req/provenance/inputs-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

-

-

-

-
-
9.2.2.  Prov

-
-
The server MUST provide an endpoint to retrieve the provenance of a job.

-
-
9.2.2.1.  Operation

-
-
Requirement 28
Label/req/provenance/prov-get-op
A
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

-
B
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

-

-
-
Permission 10
Label/per/provenance/run-content-negotiation
A
Content negotiation MAY be supported to provide alternate representations of the response.

-
B
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

-
C
The server MAY support the following additional content type: application/xml for PROV-XML

-
D
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

-

-

-
-
9.2.2.2.  Response

-
-
Requirement 29
Label/req/provenance/prov-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

-
C
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

-

-

-

-

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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

-
-
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

-
A.2.  Conformance Class Job Management

-
-
Conformance class A.1: Job Management
Identifierhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Subjecthttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Target TypeWeb API
Conformance testConformance test A.1-1: /conf/dru/deploy/post-op

-
-
A.2.1.  Create operation

-
-
Abstract test A.1
Identifier/conf/jm/create/post-op
Requirement/req/job-management/create-post-op
Test purpose
Validate that the server support HTTP POST operation at the path /jobs/

-
Test method
  1. Construct a path for the {root}/jobs path.
    
-
    2. 
-
  2. Issue an HTTP POST request for each path.
    
-
    3. 
-
  3. Validate that the response header does not contain 405 Method not allowed
    
-
    4. 
-

-

-

-

Annex B
(informative)
Revision History
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

Bibliography

-
[1]  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
-https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md.
[2]  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. https://w3id.org/cwl/v1.2/
[3]  OpenEO: OpenEO Developers API Reference / Process Graphs. https://openeo.org/documentation/1.0/developers/api/reference.html#section/Processes/Process-Graphs

-
-
-
-

-
-  
-
-  
-
-
-
-
-
-  
-
-
-
-
-
-  
-    
-
-
-
-
-
-
diff --git a/extensions/job_management/standard/24-051.pdf.err b/extensions/job_management/standard/24-051.pdf.err
deleted file mode 100644
index 8ed3c414..00000000
--- a/extensions/job_management/standard/24-051.pdf.err
+++ /dev/null
@@ -1,241 +0,0 @@
-Content overflows the viewport of an fo:block-container in inline-progression direction by 36506 millipoints. (See position 595:3617)
-Page 4: Unresolved ID reference "rc_provenance" found.
-Page 4: Unresolved ID reference "rc_job-management" found.
-Page 12: Unresolved ID reference "rfc2616" found.
-Page 19: Unresolved ID reference "rfc2616" found.
-Page 23: Unresolved ID reference "deploy-replace-undeploy-http_status_codes" found.
-Page 25: Unresolved ID reference "rc_job-management" found.
-Page 29: Unresolved ID reference "rc_job-management" found.
-Page 41: Unresolved ID reference "_a86d877f-b639-4c33-aaf0-aafbda999bc2" found.
-Page 41: Unresolved ID reference "rc_job-management" found.
-5 link targets could not be fully resolved and now points to the top of the page or are dysfunctional.
-PDF isn't valid PDF/UA-1:
-ValidationResult [flavour=ua1, totalAssertions=278311, assertions=[
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[0](800 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[12](799 0 obj PDPage)/annots[3](804 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[20](1138 0 obj PDPage)/annots[1](1140 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[27](1481 0 obj PDPage)/annots[0](1482 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[31](1657 0 obj PDPage)/annots[0](1658 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[33](1746 0 obj PDPage)/annots[2](1750 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[37](1987 0 obj PDPage)/annots[0](1988 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[0](2470 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=1], status=failed,
-message=Links shall be tagged according to ISO 32000-1:2008, 14.8.4.4.2, Link Element,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.5, testNumber=2], status=failed,
-message=Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.18.1, testNumber=2], status=failed,
-message=An annotation (except Widget annotations or hidden annotations, or those having rectangle outside the crop-box) shall have either Contents key or an Alt entry in the enclosing structure element,
-location=Location [level=CosDocument, context=root/document[0]/pages[49](2469 0 obj PDPage)/annots[1](2471 0 obj PDLinkAnnot)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[3](3023 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[5](3025 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[6](3026 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[7](3027 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[8](3028 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[9](3029 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[10](3030 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[11](3031 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[12](3032 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[13](3033 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[14](3034 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[15](3035 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[16](3036 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[17](3037 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[18](3038 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[19](3039 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[20](3040 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[21](3041 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[22](3042 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[23](3043 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[24](3044 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[25](3045 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[26](3046 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[27](3047 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[28](3048 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[29](3049 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[30](3050 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[31](3051 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[32](3052 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[33](3053 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[34](3054 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[35](3055 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[36](3056 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[37](3057 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[38](3058 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[39](3059 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[40](3060 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[41](3061 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[42](3062 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[43](3063 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[44](3064 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[45](3065 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[46](3066 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[47](3067 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[48](3068 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[49](3069 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[50](3070 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[51](3071 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null], 
-TestAssertion [ruleId=RuleId [specification=ISO 14289-1:2014, clause=7.2, testNumber=26], status=failed,
-message=TOCI element should be contained in TOC element,
-location=Location [level=CosDocument, context=root/document[0]/StructTreeRoot[0](2926 0 obj PDStructTreeRoot)/K[0](2928 0 obj SEDocument Document)/K[2](2937 0 obj SEPart Part)/K[0](3009 0 obj SESect Sect)/K[1](3012 0 obj SEDiv Div)/K[0](3014 0 obj SEDiv Div)/K[52](3072 0 obj SETOCI TOCI)], locationContext=null, errorMessage=null]], isCompliant=false]
diff --git a/extensions/job_management/standard/24-051.presentation.xml b/extensions/job_management/standard/24-051.presentation.xml
deleted file mode 100644
index b59f2969..00000000
--- a/extensions/job_management/standard/24-051.presentation.xml
+++ /dev/null
@@ -1,1800 +0,0 @@
-
-
-
-OGC API - Processes - Part 4: Job Management
-http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
-Geolabs
-
-Terradue Srl.
-
-Computer Research Institute of Montréal (CRIM).
-
-Gérald Fenoy
-
-Open Geospatial Consortium
-OGC1.0en
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

-
-
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

-
-
The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.

-
-
The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to …​

-
-
The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

-
-CAUTION
This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.

-draftDraft2019
-Open Geospatial Consortium
-OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogcScopeSymbols and abbreviated termsAbbreviated termsSymbolsContentsIntroductionPrefaceAbstractAcknowledgementsTerms and definitionsTerms, definitions, symbols and abbreviated termsTerms, definitions and symbolsTerms, definitions and abbreviated termsNormative referencesBibliographyPrefaceSectionClauseAnnexAppendixcontinuedNo terms and definitions are listed in this document.
-This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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.
-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.There are no normative references in this document.This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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 terms and definitions given in % additionally apply.
-This document uses the terms defined in https://portal.ogc.org/public_ogc/directives/directives.php[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 (https://portal.opengeospatial.org/files/?artifact_id=34762[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 terms and definitions given in % and the following additionally apply.
-[NO INFORMATION AVAILABLE](%)%1 and %2%1, and %2%1 or %2%1, or %2%1 and %2%1 or %2%1 from %2%1 to %2%1, %2%1 %2spellout-ordinaldigits-ordinalNOTENoteNote % to entryListDefinition ListFigureDiagramFormulaFormulaTableRequirementRecommendationPermissionBox(NO ID)Recommendation testRequirement testPermission testRecommendations classRequirements classPermissions classAbstract testConformance classKeyExampleExamplewherewhereWhole of textdraftinformativenormativemodifiedadaptedDEPRECATEDSOURCEandAll Parts{{ var1 | ordinal_word: '', '' }} editioneditionversionList of FiguresList of TablesList of RecommendationsJanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberObligationDangerWarningCautionImportantSafety PrecautionsEditorial NoteSectionClausePartParagraphChapterPageTableAnnexFigureExampleNoteFormulamfncommonsgdualplpreppartadjadvnounverbdeprecatessupersedesnarrowerbroaderequivalentcomparecontrastseesee alsoClauseClausesAnnexAnnexesAppendixAppendixesNoteNotesNote % to entryNotes % to entryListListsFigureFiguresFormulaFormulasTableTablesRequirementRequirementsRecommendationRecommendationsPermissionPermissionsExampleExamplesPartPartsSectionSectionsParagraphParagraphsChapterChaptersPagePagesALTERNATIVESubmittersContributorsRevision historyListingTable of FiguresNo security considerations have been made for this document.Submission DateApproval DatePublication DateAuthorEditorContributorDraftWork Item DraftCandidate SWG DraftCandidate OAB Review DraftCandidate Public RFC DraftCandidate TC Vote DraftApprovedPublishedDeprecatedRescindedRetiredenLatncolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)Table
ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-op
ats_jm_deploy_post-op/conf/jm/create/post-op
TOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
-
-OGC API - Processes - Part 4: Job Management
-http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
-Geolabs
-
-Terradue Srl.
-
-Computer Research Institute of Montréal (CRIM).
-
-Gérald Fenoy
-
-Open Geospatial Consortium
-OGC1.0enLatnOGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
-
-The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
-
-The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.
-
-The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to …​
-
-The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
-
-This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.
-draft2019
-Open Geospatial Consortium
-OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogccolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-opats_jm_deploy_post-op/conf/jm/create/post-opTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
-
-
-
-Copyright notice
-Copyright © 2019 Open Geospatial Consortium To obtain additional rights of use, visit
-
-
-
-Note
-Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
-
-Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
-
-
-
-
-
-
-License Agreement
-Use of this document is subject to the license agreement at 
-
-
-
-
-
-
-Notice for Drafts
-This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.
-
-Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
-
-
-
-
-
-
-Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 
-
-
-AbstractOGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
-
-The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.
-
-The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.
-
-The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to …​
-
-The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.
-
-This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.
-
-Security Considerations
-See OGC API — Processes — Part 1: Core, Clause 10.4.
-
-Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.
-
-Users making modifications to job resources need to:
-
-Be authenticated,
-
-Have “modification privileges” on the jobs offered through the API,
-
-Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
-
-
-
-The API definition, as defined in Clause 7.3 from , must reflect this in the resource paths and their available methods.
-
-Submitters
-All questions regarding this submission should be directed to the editors or the submitters:
-
-Name
-Affiliation
-
-Gérald Fenoy (editor)
-GeoLabs
-Francis Charette Migneault (editor)
-Centre de Recherche Informatique de Montréal (CRIM)
-Panagiotis (Peter) A. Vretanos
-CubeWerx Inc.
-
-
-
-
-
-Scope
-The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.
-
-Specifically, the Processes Part 4 Standard specifies:
-
-How to manage job.
-
-How to handle provenenance information associated with a job.
-
-
-
-
-
-Conformance
-The OGC API — Processes — Part 4 Standard defines the following requirements classes.
-
-The main requirements class is:
-
-Job Management.
-
-
-
-This class specifies requirements that any Web API implementing Processes Part 4 must conform with.
-
-The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:
-
-OGC API — Processes — Workflow Execute Request
-
-OpenEO Process Graph
-
-
-
-The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.
-
-The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.
-
-The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.
-
-The standardization target for all Conformance class defined in this Standard is “Web API”.
-
-Conformance with this Standard shall be checked using all the relevant tests specified in   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.
-
-
-
-
-
-Terms, definitions and abbreviated termsNo terms and definitions are listed in this document.
-
-
-Terms and definitions
-See , Clause 4.1.
-
-
-
-Abbreviated terms
-See , Clause 4.2.
-
-
-
-Conventions and background
-See , Clause 5.
-
-
-
-Requirements Class “Job Management”
-
-Overview
- Web APIOGC API — Processes — Part 1: Core, Conformance Class ‘core’RFC 2616 (HTTP/1.1)label
-
-
-A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.
-
-The HTTP POST method on the /jobs path is used on to create new jobs.
-
-The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.
-
-Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.
-
-Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:
-
-OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
-
-OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
-
-
-
-
-HTTP status codes
-Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.
-
-The Status Codes listed in  are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in  are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.
-
-
-Typical HTTP status codes
-Status code
-Description
-
-200
-A successful request.
-201
-The server has successfully completed the operation and a new resource has been created.
-202
-The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
-204
-A successful request with no additional content to send in the response.
-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 execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that 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
-Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
-412
-The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
-413
-The server is refusing to process the request because the request content is larger than the server is willing or able to process.
-415
-The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
-422
-The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
-500
-An internal error occurred in the server.
-
-Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.
-
-
-
-
-More specific guidance is provided for each resource, where applicable.
-
- label/per/job-management/additional-status-codesServers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in .
-
-
-
-The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.
-
-
-
-Cross-origin requests
-See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).
-
-
-
-
-Creating a new job
-
-Sequence diagram
-The following diagram illustrates the sequence diagram for deploying a new process to the API:
-
-Client                                                        Server
-  |                                                             |
-  |  POST /jobs   HTTP/1.1                                      |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 201 Created                                       |
-  |  Location: /jobs/{jobId}                                    |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/create-post-opThe server SHALL support the HTTP POST operation at the path /jobs.
-
-
-
-
-
-Request body
-
-Overview
- label/req/job-management/create-bodyThe body of the POST request SHALL be in JSON format.
-
-
-
- label/per/job-management/create-bodyA server MAY support any encoding in the body of a HTTP POST operation.
-
-
-
- label/req/job-management/create-content-typeThe Content-Type header SHALL be used to declare the media type of the request.
-
-
-
-See section 3.1.1.5 of RFC 7231 for details.
-
- label/per/job-management/create-content-schemaThe Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.
-
-
-
-
-
-OGC API — Processes — Workflow Execute Request body
- label/rec/job-management/create-body-ogcapi-processesIf the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.
-
-
-
-
-
-OpenEO Process Graph body
- label/rec/job-management/create-body-openeoIf the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.
-
-
-
-
-
-
-Response
- label/req/job-management/create-response-jobidIf the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.
-
-
-
- label/req/job-management/create-response-successA successful execution of the operation SHALL be reported as a response with a HTTP status code 201.
-A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).
-
-
-
- label/req/job-management/create-response-bodyThe response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.
-The response SHALL contain a created status code and the id property that contains the job identifier.
-
-
-
-
-
-Exceptions
-See  for general guidance.
-
-If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .
-
- label/req/job-management/create-unsupported-schemaIf the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.
-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-4/1.0/unsupported-schema”.
-
-
-
-
-
-
-Updating an existing job
-
-Sequence diagram
-The following diagram illustrates the sequence diagram for updating a
-previously created job.  The identifier of the job does not change.The new job definition replaces the old job definition. Version control is not discussed in this Standard.
-
-
-
-
-Client                                                        Server
-  |                                                             |
-  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/update-patch-opFor every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.
-The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).
-
-
-
-
-
-Request body
-
-
-
-Overview
- label/req/job-management/update-bodyThe body of a PATCH request SHALL be in JSON format.
-
-
-
- label/per/job-management/update-bodyA server MAY support any encoding in the body of a HTTP PATCH operation.
-
-
-
- label/req/job-management/update-content-typeAs per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.
-
-
-
- label/per/job-management/update-content-schemaThe Content-Schema header MAY be used to indicate the schema of a request body for updating a job.
-
-
-
-
-OGC API — Processes — Workflow Execute Request
- label/rec/job-management/update-body-ogcapi-processesIf a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.
-
-
-
-
-
-OpenEO Process Graph
- label/rec/job-management/update-body-openeoIf a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.
-
-
-
-
-
-
-Response
- label/req/job-management/update-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.
-
-
-
-The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).
-
-
-
-Exceptions
-See  for general guidance.
-
-If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .
-
-If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
-
- label/req/job-management/update-response-lockedIf a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.
-The response body 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-4/1.0/locked”.
-
-
-
-
-
-
-Staring a job
-
-Sequence diagram
-The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.
-
-Client                                                        Server
-  |                                                             |
-  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/start-post-opFor every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.
-The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).
-
-
-
-
-
-Response
- label/req/job-management/start-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
-A response SHALL be a document that conforms to statusInfo.yaml.
-
-
-
-
-
-Exceptions
-See HTTP status codes for general guidance.
-
-If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
-
-If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from .
-
-
-
-
-Job definition
-For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.
-
-
-Operation
- label/req/job-management/definition-get-opFor every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.
-The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).
-
-
-
-
-
-Response
-
-Overview
- label/req/job-management/definition-response-successA successful access to the resource SHALL be reported as a response with a HTTP status code 200.
-
-
-
- label/req/job-management/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.
-
-
-
-
-
-
-Exceptions
-See HTTP status codes for general guidance.
-
-If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from .
-
-
-
-
-
-Requirements Class “OGC API — Process — Workflow Execute Request”
-
-Overview
- Web APIOGC API — Processes — Part 1: CoreOGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
-
-
-This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.
-
-
-
-OGC API — Processes — Workflow Execute Request
-
-Overview
- label/req/ogcapi-processes/schemaAn OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.
-
-
-
-
-
-
-Creating a new job
-
-Request body
- label/req/ogcapi-processes/create-bodyThe body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml
-The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.
-
-
-
- label/per/ogcapi-processes/create-content-schemaThe Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.
-
-
-
-
-
-
-Updating an existing job
-
-Request body
- label/req/ogcapi-processes/update-bodyThe media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.
-
-
-
- label/per/ogcapi-processes/update-content-schemaThe Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.
-
-
-
-
-
-
-Job definition
-
-Response content
- label/req/ogcapi-processes/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.
-
-
-
-
-
-
-
-Requirements Class “OpenEO Process Graph”
-
-Overview
- Web APIhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
-
-
-This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.
-
-
-
-OpenEO Process Graph
-
-Overview
- label/req/openeo/schemaAn OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .
-
-
-
-
-Schema for OpenEO Process Graph
-type: object
-additionalProperties:
-  type: object
-  required: 
-    - process_id
-    - arguments
-  properties:
-    process_id:
-      type: string
-    arguments: {}
-
-
-
-
-
-Creating a new job
-
-Request body
- label/req/openeo/create-bodyThe media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.
-
-
-
- label/per/openeo/create-content-schemaThe Content-Schema header MAY be pointing to OpenEO Process Graph schema.
-
-
-
-
-
-
-Updating an existing job
-
-Request body
- label/req/openeo/update-bodyThe media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.
-
-
-
- label/per/openeo/update-content-schemaThe Content-Schema header MAY be pointing to OpenEO Process Graph schema.
-
-
-
-
-
-
-Job definition
-
-Response content
- label/req/openeo/definition-response-bodyA response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.
-
-
-
-
-
-
-
-Requirements Class “Provenance”
-
-Overview
-This requirements class defines how to allow client application accessing the provenance of a job run.
-
- Web APIOGC API — Processes — Part 1: Corelabel
-
-
-
-
-Additional endpoints
-
-Inputs
-The server MUST provide an endpoint to retrieve the inputs of a job run.
-
-
-Operation
- label/req/provenance/inputs-get-opFor every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.
-The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).
-
-
-
-
-
-Response
- label/req/provenance/inputs-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
-The response SHALL contains a JSON document that conforms to the schema inputs.yaml.
-
-
-
-
-
-
-Prov
-The server MUST provide an endpoint to retrieve the provenance of a job.
-
-
-Operation
- label/req/provenance/prov-get-opFor every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.
-The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).
-
-
-
- label/per/provenance/run-content-negotiationContent negotiation MAY be supported to provide alternate representations of the response.
-The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD
-The server MAY support the following additional content type: application/xml for PROV-XML
-The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.
-
-
-
-
-
-Response
- label/req/provenance/prov-responseA successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.
-Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.
-In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.
-
-
-
-
-
-
-
-
-OpenAPI 3.0
-See , Clause 9.
-
-
-
-Media Types
-See , Clause 13.
-
-
-
-
-
-
-
-
-
-
-Abstract Test Suite
-
-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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.
-
-The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.
-
-
-
-Conformance Class Job Management
-
-Job Managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementTarget TypeWeb API /conf/dru/deploy/post-op
-
-
-
-
-Create operation
- /conf/jm/create/post-optarget/req/job-management/create-post-opValidate that the server support HTTP POST operation at the path /jobs/
-Construct a path for the {root}/jobs path.
-
-Issue an HTTP POST request for each path.
-
-Validate that the response header does not contain 405 Method not allowed
-
-
-
-
-
-
-
-Revision History
-Date
-Release
-Editor
-Primary clauses modified
-Description
-
-2024-08-22
-None
-Gérald Fenoy
-all
-Boostraping the document
-
-
-
-Normative referencesThe 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.
-
-
-  2024-11-14
-  
-OGC API
-
-  
-Processes
-
-  
-Part 1: Core
-
-  
-OGC API — Processes — Part 1: Core
-
-  http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0
-  https://docs.ogc.org/is/18-062r2/18-062r2.html
-  OGC 18-062r2
-  
-    2021-12-20
-  
-  
-    
-    
-      
-          Benjamin Pross       
-
-    
-  
-  
-    
-    
-      
-          Panagiotis (Peter) A. Vretanos       
-
-    
-  
-  
-    
-    
-      
-Open Geospatial Consortium
-
-    
-  
-  2
-  en
-  Latn
-  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.
-  
-
-Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-04420-044
-Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-00921-009
-
-  2024-11-14
-  
-OGC API
-
-  
-Features
-
-  
-Part 1: Core
-
-  
-OGC API — Features — Part 1: Core
-
-  http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0
-  https://docs.ogc.org/is/17-069r3/17-069r3.html
-  OGC 17-069r3
-  
-    2019-10-07
-  
-  
-    
-    
-      
-          Clemens Portele       
-
-    
-  
-  
-    
-    
-      
-          Panagiotis (Peter) A. Vretanos       
-
-    
-  
-  
-    
-    
-      
-          Charles Heazel       
-
-    
-  
-  
-    
-    
-      
-Open Geospatial Consortium
-
-    
-  
-  3
-  en
-  Latn
-  OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
-
-The OGC API family of standards is organized by resource type. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term ‘feature’ for things in the real world that are of interest.
-  
-
-
-Bibliography
-  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
-.
-  OpenAPI Specification 3.0.2
-  3.0.2
-
-  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. 
-  [2]
-
-  OpenEO: OpenEO Developers API Reference / Process Graphs. 
-  [3]
-
-
-
-
-
-sourcecode table td { padding: 5px; }
-sourcecode table pre { margin: 0; }
-sourcecode, sourcecode .w {
-  color: #444444;
-}
-sourcecode .cp {
-  color: #CC00A3;
-}
-sourcecode .cs {
-  color: #CC00A3;
-}
-sourcecode .c, sourcecode .ch, sourcecode .cd, sourcecode .cm, sourcecode .cpf, sourcecode .c1 {
-  color: #1E90FF;
-}
-sourcecode .kc {
-  color: #C34E00;
-}
-sourcecode .kd {
-  color: #0000FF;
-}
-sourcecode .kr {
-  color: #007575;
-}
-sourcecode .k, sourcecode .kn, sourcecode .kp, sourcecode .kt, sourcecode .kv {
-  color: #0000FF;
-}
-sourcecode .s, sourcecode .sb, sourcecode .sc, sourcecode .ld, sourcecode .sd, sourcecode .s2, sourcecode .se, sourcecode .sh, sourcecode .si, sourcecode .sx, sourcecode .sr, sourcecode .s1, sourcecode .ss {
-  color: #009C00;
-}
-sourcecode .sa {
-  color: #0000FF;
-}
-sourcecode .nb, sourcecode .bp {
-  color: #C34E00;
-}
-sourcecode .nt {
-  color: #0000FF;
-}
-
-
-
-
-Copyright notice
-
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visit

-
-
-
-Note
-
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

-
-
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

-
-
-
-
-
-
-License Agreement
-
Use of this document is subject to the license agreement at 

-
-
-
-
-
-
-Notice for Drafts
-
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

-
-
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

-
-
-
-
-
-
-
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 

-
-
-Contents
-I.<tab/>Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

-
-
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

-
-
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

-
-
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to …​

-
-
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [OGC 18-062r2] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

-
-CAUTION
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

-
-II.<tab/>Keywords
-
The following are keywords to be used by search engines and document catalogues.

-
process, instance, spatial, data, openapi, job, create, update, delete, add, remove, REST, PATCH, POST, DELETE

-
-III.<tab/>Security Considerations
-
See OGC API — Processes — Part 1: Core, Clause 10.4.

-
-
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.

-
-
Users making modifications to job resources need to:

-
-
  1. Be authenticated,
    
-
    2. 
-
  2. Have “modification privileges” on the jobs offered through the API,
    
-
    3. 
-
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
-
    4. 
-

-
-
The API definition, as defined in Clause 7.3 from OGC 18-062r2, must reflect this in the resource paths and their available methods.

-
-IV.<tab/>Submitting Organizations
-
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

- 
  • Geolabs
    • 
-
  • Terradue Srl.
    • 
-
  • Computer Research Institute of Montréal (CRIM).

- 
-
-V.<tab/>Submitters
-
All questions regarding this submission should be directed to the editors or the submitters:

-
-
-
-
-
-
-
-
-
-
-
-
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.

-
-
-
-1.<tab/>Scope
-
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [OGC 18-062r2] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.

-
-
Specifically, the Processes Part 4 Standard specifies:

-
-
  • How to manage job.
    
-
    • 
-
  • How to handle provenenance information associated with a job.
    
-
    • 
-

-
-
-
-2.<tab/>Conformance
-
The OGC API — Processes — Part 4 Standard defines the following requirements classes.

-
-
The main requirements class is:

-
-
  • Job Management.
    
-
    • 
-

-
-
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.

-
-
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:

-
-
  • OGC API — Processes — Workflow Execute Request
    
-
    • 
-
  • OpenEO Process Graph
    
-
    • 
-

-
-
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.

-
-
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.

-
-
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.

-
-
The standardization target for all Conformance class defined in this Standard is “Web API”.

-
-
Conformance with this Standard shall be checked using all the relevant tests specified in  Annex A 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.

-
-
-
-
-
-4.<tab/>Terms, definitions and abbreviated terms
No terms and definitions are listed in this document.

-
-
-4.1.<tab/>Terms and definitions
-
See OGC 18-062r2, Clause 4.1.

-
-
-
-4.2.<tab/>Abbreviated terms
-
See OGC 18-062r2, Clause 4.2.

-
-
-
-5.<tab/>Conventions and background
-
See OGC 18-062r2, Clause 5.

-
-
-
-6.<tab/>Requirements Class “Job Management”
-
-6.1.<tab/>Overview
-
-
Requirements class 1
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core, Conformance Class ‘core’
RFC 2616 (HTTP/1.1)
Label

-
-
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

-
-
The HTTP POST method on the /jobs path is used on to create new jobs.

-
-
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

-
-
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

-
-
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

-
-
  • OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
    
-
    • 
-
  • OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
    
-
    • 
-

-
-
-6.1.1.<tab/>HTTP status codes
-
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

-
-
The Status Codes listed in Table 1 are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in Table 1 are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

-
-
-Table 1 — Typical HTTP status codes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-NOTE:
Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

-
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.

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

-
-
-
Permission 1
Label/per/job-management/additional-status-codes
A
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in Table 1.

-

-
-
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

-
-
-
-6.1.2.<tab/>Cross-origin requests
-
See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).

-
-
-
-
-6.2.<tab/>Creating a new job
-
-6.2.1.<tab/>Sequence diagram
-
The following diagram illustrates the sequence diagram for deploying a new process to the API:

-
-Listing 1Client                                                        Server
-  |                                                             |
-  |  POST /jobs   HTTP/1.1                                      |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 201 Created                                       |
-  |  Location: /jobs/{jobId}                                    |
-  |<------------------------------------------------------------|
-
-
-
-
-6.2.2.<tab/>Operation
-
-
Requirement 1
Label/req/job-management/create-post-op
A
The server SHALL support the HTTP POST operation at the path /jobs.

-

-
-
-
-6.2.3.<tab/>Request body
-
-6.2.3.1.<tab/>Overview
-
-
Requirement 2
Label/req/job-management/create-body
A
The body of the POST request SHALL be in JSON format.

-

-
-
-
Permission 2
Label/per/job-management/create-body
A
A server MAY support any encoding in the body of a HTTP POST operation.

-

-
-
-
Requirement 3
Label/req/job-management/create-content-type
A
The Content-Type header SHALL be used to declare the media type of the request.

-

-
-
See section 3.1.1.5 of RFC 7231 for details.

-
-
-
Permission 3
Label/per/job-management/create-content-schema
A
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

-

-
-
-
-6.2.3.2.<tab/>OGC API — Processes — Workflow Execute Request body
-
-
Recommendation 1
Label/rec/job-management/create-body-ogcapi-processes
A
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-

-
-
-
-6.2.3.3.<tab/>OpenEO Process Graph body
-
-
Recommendation 2
Label/rec/job-management/create-body-openeo
A
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

-

-
-
-
-
-6.2.4.<tab/>Response
-
-
Requirement 4
Label/req/job-management/create-response-jobid
A
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

-

-
-
-
Requirement 5
Label/req/job-management/create-response-success
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

-
B
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

-

-
-
-
Requirement 6
Label/req/job-management/create-response-body
A
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

-
B
The response SHALL contain a created status code and the id property that contains the job identifier.

-

-
-
-
-6.2.5.<tab/>Exceptions
-
See Clause 6.1.1 for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

-
-
-
Requirement 7
Label/req/job-management/create-unsupported-schema
A
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

-
B
The content of that response SHALL be based upon the OpenAPI 3.0 schema  exception.yaml.

-
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/unsupported-schema”.

-

-
-
-
-
-6.3.<tab/>Updating an existing job
-
-6.3.1.<tab/>Sequence diagram
-
The following diagram illustrates the sequence diagram for updating a
-previously created job.  The identifier of the job does not change.NOTE:
The new job definition replaces the old job definition. Version control is not discussed in this Standard.

-

-
-
-
-Listing 2Client                                                        Server
-  |                                                             |
-  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-6.3.2.<tab/>Operation
-
-
Requirement 8
Label/req/job-management/update-patch-op
A
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

-
B
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

-

-
-
-
-6.3.3.<tab/>Request body
-
-
-
-6.3.4.<tab/>Overview
-
-
Requirement 9
Label/req/job-management/update-body
A
The body of a PATCH request SHALL be in JSON format.

-

-
-
-
Permission 4
Label/per/job-management/update-body
A
A server MAY support any encoding in the body of a HTTP PATCH operation.

-

-
-
-
Requirement 10
Label/req/job-management/update-content-type
A
As per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

-

-
-
-
Permission 5
Label/per/job-management/update-content-schema
A
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

-

-
-
-6.3.4.1.<tab/>OGC API — Processes — Workflow Execute Request
-
-
Recommendation 3
Label/rec/job-management/update-body-ogcapi-processes
A
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-

-
-
-
-6.3.4.2.<tab/>OpenEO Process Graph
-
-
Recommendation 4
Label/rec/job-management/update-body-openeo
A
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

-

-
-
-
-
-6.3.5.<tab/>Response
-
-
Requirement 11
Label/req/job-management/update-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

-

-
-
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

-
-
-
-6.3.6.<tab/>Exceptions
-
See Clause 6.1.1 for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from OGC 20-044.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-
-
-
Requirement 12
Label/req/job-management/update-response-locked
A
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

-
B
The response body SHALL be based upon the OpenAPI 3.0 schema exception.yaml.

-
C
The type of the exception SHALL be “http://www.opengis.net/def/exceptions/ogcapi-processes-4/1.0/locked”.

-

-
-
-
-
-6.4.<tab/>Staring a job
-
-6.4.1.<tab/>Sequence diagram
-
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

-
-Listing 3Client                                                        Server
-  |                                                             |
-  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-6.4.2.<tab/>Operation
-
-
Requirement 13
Label/req/job-management/start-post-op
A
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

-
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-

-
-
-
-6.4.3.<tab/>Response
-
-
Requirement 14
Label/req/job-management/start-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
A response SHALL be a document that conforms to statusInfo.yaml.

-

-
-
-
-6.4.4.<tab/>Exceptions
-
See HTTP status codes for general guidance.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-
-
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from Clause 6.3.

-
-
-
-
-6.5.<tab/>Job definition
-
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

-
-
-6.5.1.<tab/>Operation
-
-
Requirement 15
Label/req/job-management/definition-get-op
A
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

-
B
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

-

-
-
-
-6.5.2.<tab/>Response
-
-6.5.2.1.<tab/>Overview
-
-
Requirement 16
Label/req/job-management/definition-response-success
A
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

-

-
-
-
Requirement 17
Label/req/job-management/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

-

-
-
-
-
-6.5.3.<tab/>Exceptions
-
See HTTP status codes for general guidance.

-
-
If the job with the specified identifier does not exist on the server, see requirement /req/core/job-exception-no-such-job from OGC 18-062r2.

-
-
-
-
-
-7.<tab/>Requirements Class “OGC API — Process — Workflow Execute Request”
-
-7.1.<tab/>Overview
-
-
Requirements class 2
Obligationrequirement
Target typeWeb API
PrerequisitesOGC API — Processes — Part 1: Core
OGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’
http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Label

-
-
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

-
-
-
-7.2.<tab/>OGC API — Processes — Workflow Execute Request
-
-7.2.1.<tab/>Overview
-
-
Requirement 18
Label/req/ogcapi-processes/schema
A
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

-

-
-
-
-
-7.3.<tab/>Creating a new job
-
-7.3.1.<tab/>Request body
-
-
Requirement 19
Label/req/ogcapi-processes/create-body
A
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

-
B
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

-

-
-
-
Permission 6
Label/per/ogcapi-processes/create-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-

-
-
-
-
-7.4.<tab/>Updating an existing job
-
-7.4.1.<tab/>Request body
-
-
Requirement 20
Label/req/ogcapi-processes/update-body
A
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

-

-
-
-
Permission 7
Label/per/ogcapi-processes/update-content-schema
A
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-

-
-
-
-
-7.5.<tab/>Job definition
-
-7.5.1.<tab/>Response content
-
-
Requirement 21
Label/req/ogcapi-processes/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

-

-
-
-
-
-
-8.<tab/>Requirements Class “OpenEO Process Graph”
-
-8.1.<tab/>Overview
-
-
Requirements class 3
Obligationrequirement
Target typeWeb API
Prerequisitehttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-management
Label

-
-
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

-
-
-
-8.2.<tab/>OpenEO Process Graph
-
-8.2.1.<tab/>Overview
-
-
Requirement 22
Label/req/openeo/schema
A
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .

-

-
-Listing 4 — 
-  Schema for OpenEO Process Graph
-
-
-type: object
-additionalProperties:
-  type: object
-  required: 
-    - process_id
-    - arguments
-  properties:
-    process_id:
-      type: string
-    arguments: {}
-
-
-
-
-
-8.3.<tab/>Creating a new job
-
-8.3.1.<tab/>Request body
-
-
Requirement 23
Label/req/openeo/create-body
A
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

-

-
-
-
Permission 8
Label/per/openeo/create-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-

-
-
-
-
-8.4.<tab/>Updating an existing job
-
-8.4.1.<tab/>Request body
-
-
Requirement 24
Label/req/openeo/update-body
A
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

-

-
-
-
Permission 9
Label/per/openeo/update-content-schema
A
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-

-
-
-
-
-8.5.<tab/>Job definition
-
-8.5.1.<tab/>Response content
-
-
Requirement 25
Label/req/openeo/definition-response-body
A
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

-

-
-
-
-
-
-9.<tab/>Requirements Class “Provenance”
-
-9.1.<tab/>Overview
-
This requirements class defines how to allow client application accessing the provenance of a job run.

-
-
-
Requirements class 4
Obligationrequirement
Target typeWeb API
PrerequisiteOGC API — Processes — Part 1: Core
Label

-
-
-
-9.2.<tab/>Additional endpoints
-
-9.2.1.<tab/>Inputs
-
The server MUST provide an endpoint to retrieve the inputs of a job run.

-
-
-9.2.1.1.<tab/>Operation
-
-
Requirement 26
Label/req/provenance/inputs-get-op
A
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

-
B
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-

-
-
-
-9.2.1.2.<tab/>Response
-
-
Requirement 27
Label/req/provenance/inputs-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

-

-
-
-
-
-9.2.2.<tab/>Prov
-
The server MUST provide an endpoint to retrieve the provenance of a job.

-
-
-9.2.2.1.<tab/>Operation
-
-
Requirement 28
Label/req/provenance/prov-get-op
A
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

-
B
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

-

-
-
-
Permission 10
Label/per/provenance/run-content-negotiation
A
Content negotiation MAY be supported to provide alternate representations of the response.

-
B
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

-
C
The server MAY support the following additional content type: application/xml for PROV-XML

-
D
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

-

-
-
-
-9.2.2.2.<tab/>Response
-
-
Requirement 29
Label/req/provenance/prov-response
A
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
B
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

-
C
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

-

-
-
-
-
-
-
-10.<tab/>OpenAPI 3.0
-
See OGC 18-062r2, Clause 9.

-
-
-
-11.<tab/>Media Types
-
See OGC 18-062r2, Clause 13.

-
-
-
-
-
-
-
-
-
-
-3.<tab/>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.

-
-Benjamin Pross, Panagiotis (Peter) A. Vretanos: OGC 18-062r2, OGC API — Processes — Part 1: Core. Open Geospatial Consortium (2021). http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0.http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0https://docs.ogc.org/is/18-062r2/18-062r2.htmlOGC 18-062r2OGC 18-062r2
-Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-044OGC 20-04420-044
-Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-009OGC 21-00921-009
-Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0.http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0https://docs.ogc.org/is/17-069r3/17-069r3.htmlOGC 17-069r3OGC 17-069r3
-
-<strong>Annex A</strong><br/>(normative)<br/><strong>Abstract Test Suite</strong>
-
-A.1.<tab/>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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

-
-
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

-
-
-
-A.2.<tab/>Conformance Class Job Management
-
-
-
-
Conformance class A.1: Job Management
Identifierhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Subjecthttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
Target TypeWeb API
Conformance testConformance test A.1-1: /conf/dru/deploy/post-op

-
-
-A.2.1.<tab/>Create operation
-
-
-
-
Abstract test A.1
Identifier/conf/jm/create/post-op
Requirement/req/job-management/create-post-op
Test purpose
Validate that the server support HTTP POST operation at the path /jobs/

-
Test method
  1. Construct a path for the {root}/jobs path.
    
-
    2. 
-
  2. Issue an HTTP POST request for each path.
    
-
    3. 
-
  3. Validate that the response header does not contain 405 Method not allowed
    
-
    4. 
-

-

-
-
-
-<strong>Annex B</strong><br/>(informative)<br/><strong>Revision History</strong>
-
-
-
-
-
-
-
-
-
-
-
-
-
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

-
-Bibliography
-  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
-.[1]
-  OpenAPI Specification 3.0.2OpenAPI Specification 3.0.2
-  3.0.2
-[1]
-  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. [2]
-  
-[2]
-  OpenEO: OpenEO Developers API Reference / Process Graphs. [3]
-  
-[3]
-
-
-
-
-
diff --git a/extensions/job_management/standard/24-051.xml b/extensions/job_management/standard/24-051.xml
deleted file mode 100644
index 1104fe0a..00000000
--- a/extensions/job_management/standard/24-051.xml
+++ /dev/null
@@ -1,923 +0,0 @@
-
-
-
-OGC API - Processes - Part 4: Job Management
-http://www.opengis.net/doc/IS/ogcapi-processes-4/1.024-05124-051yyyy-mm-ddyyyy-mm-ddyyyy-mm-dd
-Geolabs
-
-Terradue Srl.
-
-Computer Research Institute of Montréal (CRIM).
-
-Gérald Fenoy
-
-Open Geospatial Consortium
-OGC1.0en
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

-
-
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

-
-
The OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API - Processes Standard.

-
-
The OGC API - Processes - Part 3: Workflows draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to …​

-
-
The OGC API - Processes - Part 4: Job Management draft specification extends the core capabilities specified in OGC API - Processes - Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

-
-
This is a DRAFT version of the 4th part of the OGC API - Processes standards. This draft is not complete and there are open issues that are still under discussion.

-draft2019
-Open Geospatial Consortium
-OGCprocessinstancespatialdataopenapijobcreateupdatedeleteaddremoveRESTPATCHPOSTDELETEstandardimplementationogccolor-admonition-cautionrgb(79, 129, 189)color-admonition-editorrgb(79, 129, 189)color-admonition-importantrgb(79, 129, 189)color-admonition-notergb(79, 129, 189)color-admonition-safety-precautionrgb(79, 129, 189)color-admonition-tiprgb(79, 129, 189)color-admonition-todorgb(79, 129, 189)color-admonition-warningrgb(79, 129, 189)color-background-definition-descriptionrgb(242, 251, 255)color-background-definition-termrgb(215, 243, 255)color-background-pagergb(33, 55, 92)color-background-table-headerrgb(33, 55, 92)color-background-table-row-evenrgb(252, 246, 222)color-background-table-row-oddrgb(254, 252, 245)color-background-term-admitted-labelrgb(223, 236, 249)color-background-term-deprecated-labelrgb(237, 237, 238)color-background-term-preferred-labelrgb(249, 235, 187)color-background-text-label-legacyrgb(33, 60, 107)color-secondary-shade-1rgb(237, 193, 35)color-secondary-shade-2rgb(246, 223, 140)color-textrgb(88, 89, 91)color-text-titlergb(33, 55, 92)
ats_jmhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-management
_e4f811aa-f7f8-48f8-bbf1-7c65f9501ef1/conf/dru/deploy/post-op
ats_jm_deploy_post-op/conf/jm/create/post-op
TOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2PDF TOC Heading Levels2
-
-
-
-Copyright notice
-
Copyright © 2019 Open Geospatial Consortium
 To obtain additional rights of use, visit

-
-
-
-Note
-
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

-
-
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

-
-
-
-
-
-
-License Agreement
-
Use of this document is subject to the license agreement at 

-
-
-
-
-
-
-Notice for Drafts
-
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

-
-
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

-
-
-
-
-
-
-
Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: 

-
-
-Abstract
OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

-
-
The OGC API Processes Standard (aka Processes API) defines API building blocks to describe, execute, monitor and retrieve results of Web-accessible processes. OGC API Processes is comprised of multiple parts, each of them is a separate OGC Standard.

-
-
The OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

-
-
The OGC API — Processes — Part 3: Workflows draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to …​

-
-
The OGC API — Processes — Part 4: Job Management draft specification extends the core capabilities specified in OGC API — Processes — Part 1: Core [] with the ability to create, manage and monitor jobs that are associated with processes execution. This part of the standard also defines how to ensure provenance information is preserved and findable.

-
-
This is a DRAFT version of the 4th part of the OGC API — Processes standards. This draft is not complete and there are open issues that are still under discussion.

-
-Security Considerations
-
See OGC API — Processes — Part 1: Core, Clause 10.4.

-
-
Since creating and updating jobs will change the jobs available to a client, servers will — in almost all cases — restrict the access to these operations.

-
-
Users making modifications to job resources need to:

-
-
  1. Be authenticated,
    
-
    2. 
-
  2. Have “modification privileges” on the jobs offered through the API,
    
-
    3. 
-
  3. Have access to one or more of the POST and/or PATCH methods on the jobs /job and /jobs/{jobId} endpoints.
    
-
    4. 
-

-
-
The API definition, as defined in Clause 7.3 from , must reflect this in the resource paths and their available methods.

-
-Submitters
-
All questions regarding this submission should be directed to the editors or the submitters:

-
-
-
-
-
-
-
-
-
-
-
-
NameAffiliation
Gérald Fenoy (editor)GeoLabs
Francis Charette Migneault (editor)Centre de Recherche Informatique de Montréal (CRIM)
Panagiotis (Peter) A. VretanosCubeWerx Inc.

-
-
-
-Scope
-
The OGC API — Processes — Part 4 Standard is an extension to the OGC API – Processes – Part 1: Core Standard [] and defines the behavior of a server that supports the ability to create jobs without implying the process execution starts right away.

-
-
Specifically, the Processes Part 4 Standard specifies:

-
-
  • How to manage job.
    
-
    • 
-
  • How to handle provenenance information associated with a job.
    
-
    • 
-

-
-
-
-Conformance
-
The OGC API — Processes — Part 4 Standard defines the following requirements classes.

-
-
The main requirements class is:

-
-
  • Job Management.
    
-
    • 
-

-
-
This class specifies requirements that any Web API implementing Processes Part 4 must conform with.

-
-
The Job Management class does not mandate a specific encoding for the job definition. However, the Part 4 extension defines the following conformance class:

-
-
  • OGC API — Processes — Workflow Execute Request
    
-
    • 
-
  • OpenEO Process Graph
    
-
    • 
-

-
-
The OGC API - Processes - Workflow Execute Request class defines that jobs can be created from an OGC API — Processes — Workflow Execute Request.

-
-
The OpenEO Process Graph class defines that jobs can be created from an OpenEO Process Graph.

-
-
The provenance information associated with a job is not mandated to be supported by the server. A dedicated requirements class  Provenance is defined for this feature.

-
-
The standardization target for all Conformance class defined in this Standard is “Web API”.

-
-
Conformance with this Standard shall be checked using all the relevant tests specified in   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.

-
-
-
-
-
-Terms, definitions and abbreviated terms
No terms and definitions are listed in this document.

-
-
-Terms and definitions
-
See , Clause 4.1.

-
-
-
-Abbreviated terms
-
See , Clause 4.2.

-
-
-
-Conventions and background
-
See , Clause 5.

-
-
-
-Requirements Class “Job Management”
-
-Overview
- Web APIOGC API — Processes — Part 1: Core, Conformance Class ‘core’RFC 2616 (HTTP/1.1)label
-
-
-
A server that implements the Job Management Requirements Class provides the ability to create, update and start jobs.

-
-
The HTTP POST method on the /jobs path is used on to create new jobs.

-
-
The HTTP PATCH method on the /jobs/{jobId} is used to update the definition of a previously created jobs that are accessible via the Processes API endpoint.

-
-
Finally, the HTTP POST method on the /job/{jobId}/results is used to start a job.

-
-
Creating or updating a job requires that a formal description of the new or updated jobs be provided by the client.  This Standard does not mandate that a specific jobs schema be used. However, this extension defines the following conformance classe:

-
-
  • OGC API — Processes — Wrokflow Execute Request, that enables support for OGC API — Processes — Part 3: Wofklows for jobs definitions.
    
-
    • 
-
  • OpenEO Process Graph, that enables support for OpenEO-encoded jobs definitions.
    
-
    • 
-

-
-
-HTTP status codes
-
Clients implementing the Processes API Part 4 should be prepared to handle any legal HTTP or HTTPS status code.

-
-
The Status Codes listed in  are of particular relevance to implementors of this Standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in  are not mandatory, but are important for the implementation of a well functioning API implementation. Support for these status codes is strongly encouraged for both client and server implementations.

-
-
-Typical HTTP status codes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Status code 422 is not yet an official HTTP status code, but is expected to be added by the draft IETF RFC “HTTP Semantics”.

-
Status codeDescription
200A successful request.
201The server has successfully completed the operation and a new resource has been created.
202The request was accepted for processing, but the processing was not completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
204A successful request with no additional content to send in the response.
400The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.
401The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.
403The server understood the request, but is refusing to execute the request. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but that the client is not authorized to perform the requested operation on the resource.
404The requested resource does not exist on the server. For example, a path parameter had an incorrect value.
405The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.
406Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.
412The status code indicates that one or more conditions given in the request header fields evaluated to false when tested by the server.
413The server is refusing to process the request because the request content is larger than the server is willing or able to process.
415The server is refusing to service the request because the content is in a format not supported by this method on the target resource.
422The server understands the content type of the request content and the syntax of the request content is correct, but was unable to process the contained instructions. For example, the submitted resource does not meet a semantic constraint, e.g. a mandatory property is missing.
500An internal error occurred in the server.

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

-
- label/per/job-management/additional-status-codes
Servers MAY support other HTTP protocol capabilities. Therefore, the server may return other status codes than those listed in .

-
-
-
-
The API Description Document describes the HTTP status codes generated by that API imeplementation instance. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document be limited to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

-
-
-
-Cross-origin requests
-
See OGC API — Features — Part 1: Core, section Support for cross-origin requests, about the importance of supporting cross-origin requests, typically via Cross-origin resource sharing (CORS).

-
-
-
-
-Creating a new job
-
-Sequence diagram
-
The following diagram illustrates the sequence diagram for deploying a new process to the API:

-
-Client                                                        Server
-  |                                                             |
-  |  POST /jobs   HTTP/1.1                                      |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 201 Created                                       |
-  |  Location: /jobs/{jobId}                                    |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/create-post-op
The server SHALL support the HTTP POST operation at the path /jobs.

-
-
-
-
-
-Request body
-
-Overview
- label/req/job-management/create-body
The body of the POST request SHALL be in JSON format.

-
-
-
- label/per/job-management/create-body
A server MAY support any encoding in the body of a HTTP POST operation.

-
-
-
- label/req/job-management/create-content-type
The Content-Type header SHALL be used to declare the media type of the request.

-
-
-
-
See section 3.1.1.5 of RFC 7231 for details.

-
- label/per/job-management/create-content-schema
The Content-Schema header MAY be an URI to a JSON or OpenAPI 3.0 Schema document that describes the structure of the request body.

-
-
-
-
-
-OGC API — Processes — Workflow Execute Request body
- label/rec/job-management/create-body-ogcapi-processes
If the job can be encoded as an OGC API — Processes — Workflow Execute Request, implementation SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-
-
-
-
-
-OpenEO Process Graph body
- label/rec/job-management/create-body-openeo
If the job can be encoded as an OpenEO graph, implementation SHOULD consider supporting the OpenEO graph encoding.

-
-
-
-
-
-
-Response
- label/req/job-management/create-response-jobid
If the operation completes, the server SHALL generate a job identifier (i.e. {jobId}) for the created job.

-
-
-
- label/req/job-management/create-response-success
A successful execution of the operation SHALL be reported as a response with a HTTP status code 201.

-
A response with HTTP status code 201 SHALL include a Location header with the URI of the deployed processes (path: /jobs/{jobId}).

-
-
-
- label/req/job-management/create-response-body
The response SHALL include a body that contains a status information of the created job that conforms to the statusInfo.yaml schema.

-
The response SHALL contain a created status code and the id property that contains the job identifier.

-
-
-
-
-
-Exceptions
-
See  for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .

-
- label/req/job-management/create-unsupported-schema
If the server does not support the Content-Schema header associated with the request body, the code of the response SHALL be 422 Unprocessable Content.

-
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-4/1.0/unsupported-schema”.

-
-
-
-
-
-
-Updating an existing job
-
-Sequence diagram
-
The following diagram illustrates the sequence diagram for updating a
-previously created job.  The identifier of the job does not change.
The new job definition replaces the old job definition. Version control is not discussed in this Standard.

-

-
-
-
-Client                                                        Server
-  |                                                             |
-  |  PATCH /jobs/{jobId}   HTTP/1.1                             |
-  |  Content-Type: application/json                             |
-  |                                                             |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/update-patch-op
For every created jobs (path ‘/jobs/{jobId}’), the server SHALL support the HTTP PATCH operation.

-
The parameter ‘jobId’ is each ‘jobID’ property in the jobs list response (JSONPath: $.jobs[*].id).

-
-
-
-
-
-Request body
-
-
-
-Overview
- label/req/job-management/update-body
The body of a PATCH request SHALL be in JSON format.

-
-
-
- label/per/job-management/update-body
A server MAY support any encoding in the body of a HTTP PATCH operation.

-
-
-
- label/req/job-management/update-content-type
As per HTTP 1.1 () the ‘Content-Type’ header SHALL be used to indicate the media type of a request body.

-
-
-
- label/per/job-management/update-content-schema
The Content-Schema header MAY be used to indicate the schema of a request body for updating a job.

-
-
-
-
-OGC API — Processes — Workflow Execute Request
- label/rec/job-management/update-body-ogcapi-processes
If a job can be created from an OGC API — Processes — Workflow Execute Request, implementations SHOULD consider supporting the OGC API — Processes — Workflow Execute Request encoding.

-
-
-
-
-
-OpenEO Process Graph
- label/rec/job-management/update-body-openeo
If a job can be created from an OpenEO Process Graph, implementations SHOULD consider supporting the OpenEO Process Graph encoding.

-
-
-
-
-
-
-Response
- label/req/job-management/update-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code 200 or 204.

-
-
-
-
The status code depends on the server. If the server has replaced the job, the response is either 200 (if the response includes additional content) or 204 (if the response has no additional content).

-
-
-
-Exceptions
-
See  for general guidance.

-
-
If the request body’s media type is not supported by the server, see requirement /req/deploy-replace-undeploy/deploy/unsupported-media-type from .

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

-
- label/req/job-management/update-response-locked
If a job is locked, meaning that it is currently being processed (status set to accepted or running), the server SHALL respond with HTTP status code 423 Locked.

-
The response body 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-4/1.0/locked”.

-
-
-
-
-
-
-Staring a job
-
-Sequence diagram
-
The following diagram illustrates the sequence diagram for starting the execution of a previously created jobs.

-
-Client                                                        Server
-  |                                                             |
-  |  POST /jobs/{jobId}/results   HTTP/1.1                      |
-  |------------------------------------------------------------>|
-  |                                                             |
-  |  HTTP/1.1 200 OK                                            |
-  |<------------------------------------------------------------|
-
-
-
-
-Operation
- label/req/job-management/start-post-op
For every created jobs (path: /jobs/{jobId}/results), the server SHALL support the HTTP POST operation.

-
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-
-
-
-
-
-Response
- label/req/job-management/start-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
A response SHALL be a document that conforms to statusInfo.yaml.

-
-
-
-
-
-Exceptions
-
See HTTP status codes for general guidance.

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

-
-
If the job with the specified identifier is locked, see requirement /req/job-management/update/response-locked from .

-
-
-
-
-Job definition
-
For every job, it is possible to retrieve its original definition. It corresponds to the request’s body used to create or update the jobs.

-
-
-Operation
- label/req/job-management/definition-get-op
For every jobs (using method: POST on path: /jobs/{jobId}), the server SHALL support the HTTP GET operation at the path /jobs/{jobId}/definition.

-
The parameter jobId is each id property in the job-list response (JSONPath: $.jobs[*].id).

-
-
-
-
-
-Response
-
-Overview
- label/req/job-management/definition-response-success
A successful access to the resource SHALL be reported as a response with a HTTP status code 200.

-
-
-
- label/req/job-management/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the request body used to create or update the job.

-
-
-
-
-
-
-Exceptions
-
See HTTP status codes for general guidance.

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

-
-
-
-
-
-Requirements Class “OGC API — Process — Workflow Execute Request”
-
-Overview
- Web APIOGC API — Processes — Part 1: CoreOGC API — Processes — Part 3: Workflows, Conformance Class ‘nested-processing’http://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
-
-
-
This requirements class defines that the OGC API — Process — Workflow Execute Request is supported as an encoding for job definitions.

-
-
-
-OGC API — Processes — Workflow Execute Request
-
-Overview
- label/req/ogcapi-processes/schema
An OGC API - Processes - Workflow - Execute Request document SHALL be based upon the JSON schema execute-workflow.yaml.

-
-
-
-
-
-
-Creating a new job
-
-Request body
- label/req/ogcapi-processes/create-body
The body of the POST request SHALL be based upon the OpenAPI 3.0 schema execute-workflows.yaml

-
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OGC API — Processes.

-
-
-
- label/per/ogcapi-processes/create-content-schema
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-
-
-
-
-
-
-Updating an existing job
-
-Request body
- label/req/ogcapi-processes/update-body
The media type application/ogcapi-processes+json SHALL be used to indicate that request body contains a job encoded as an OpenEO.

-
-
-
- label/per/ogcapi-processes/update-content-schema
The Content-Schema header MAY be pointing to the OpenAPI 3.0 schema execute-workflows.yaml.

-
-
-
-
-
-
-Job definition
-
-Response content
- label/req/ogcapi-processes/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the OGC API — Processes — Workflow — Execute Request to use to deploy the process.

-
-
-
-
-
-
-
-Requirements Class “OpenEO Process Graph”
-
-Overview
- Web APIhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/req/job-managementlabel
-
-
-
This requirements class defines that the server supports the OpenEO Process Graph as an encoding for job definitions.

-
-
-
-OpenEO Process Graph
-
-Overview
- label/req/openeo/schema
An OpenEO Process Graph document SHALL be based upon the OpenEO Process Graph JSON schema .

-
-
-
-
-Schema for OpenEO Process Graph
-type: object
-additionalProperties:
-  type: object
-  required: 
-    - process_id
-    - arguments
-  properties:
-    process_id:
-      type: string
-    arguments: {}
-
-
-
-
-
-Creating a new job
-
-Request body
- label/req/openeo/create-body
The media type application/json SHALL be used to indicate that request body contains a processes description encoded as an OpenEO Process Graph.

-
-
-
- label/per/openeo/create-content-schema
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-
-
-
-
-
-
-Updating an existing job
-
-Request body
- label/req/openeo/update-body
The media type application/json SHALL be used to indicate that request body contains a job encoded as an OpenEO Process Graph.

-
-
-
- label/per/openeo/update-content-schema
The Content-Schema header MAY be pointing to OpenEO Process Graph schema.

-
-
-
-
-
-
-Job definition
-
-Response content
- label/req/openeo/definition-response-body
A response with HTTP status code 200 SHALL include a body that contains the OpenEO Process Graph to use to deploy the process.

-
-
-
-
-
-
-
-Requirements Class “Provenance”
-
-Overview
-
This requirements class defines how to allow client application accessing the provenance of a job run.

-
- Web APIOGC API — Processes — Part 1: Corelabel
-
-
-
-
-Additional endpoints
-
-Inputs
-
The server MUST provide an endpoint to retrieve the inputs of a job run.

-
-
-Operation
- label/req/provenance/inputs-get-op
For every created jobs (path: /jobs/{jobId}/inputs), the server SHALL support the HTTP GET operation.

-
The parameter jobId is each jobID property in the job list response (JSONPath: $.jobs[*].id).

-
-
-
-
-
-Response
- label/req/provenance/inputs-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
The response SHALL contains a JSON document that conforms to the schema inputs.yaml.

-
-
-
-
-
-
-Prov
-
The server MUST provide an endpoint to retrieve the provenance of a job.

-
-
-Operation
- label/req/provenance/prov-get-op
For every created jobs (path: /jobs/{jobId}/prov), the server SHALL support the HTTP GET operation.

-
The parameter {jobId} is each id property in the job list response (JSONPath: $.jobs[*].id).

-
-
-
- label/per/provenance/run-content-negotiation
Content negotiation MAY be supported to provide alternate representations of the response.

-
The server MAY support the following additional content type: application/ld+json for PROV-O as JSON-LD

-
The server MAY support the following additional content type: application/xml for PROV-XML

-
The server MAY support the following additional content type: text/provenance-notation; charset="UTF-8" for PROV-N.

-
-
-
-
-
-Response
- label/req/provenance/prov-response
A successful execution of the operation SHALL be reported as a response with a HTTP status code ‘200’.

-
Per default, the response SHALL contains a JSON document that conforms to the schema for PROV-JSON.

-
In case content-negotiation is used, the response MAY contain other representations including PROV-O as JSON-LD, PROV-XML or PROV-N.

-
-
-
-
-
-
-
-
-OpenAPI 3.0
-
See , Clause 9.

-
-
-
-Media Types
-
See , Clause 13.

-
-
-
-
-
-
-
-
-
-
-Abstract Test Suite
-
-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 endpoint may expose resources in addition to those defined by the standard. A test engine must be able to traverse an implementation of the API, identify and validate test points, and ignore resource paths which are not to be tested.

-
-
The Web API under test can require authorization. Any Executable Test Suite implementing this test suite should implement the following security schemes supported by OpenAPI 3.0: HTTP Authorization schemes “basic” and “bearer”, API keys, and OAuth2 flow “authorizationCode”.

-
-
-
-Conformance Class Job Management
-
-Job Managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementhttp://www.opengis.net/spec/ogcapi-processes-4/1.0/conf/job-managementTarget TypeWeb API /conf/dru/deploy/post-op
-
-
-
-
-Create operation
- /conf/jm/create/post-optarget/req/job-management/create-post-op
Validate that the server support HTTP POST operation at the path /jobs/

-
  1. Construct a path for the {root}/jobs path.
    
-
    2. 
-
  2. Issue an HTTP POST request for each path.
    
-
    3. 
-
  3. Validate that the response header does not contain 405 Method not allowed
    
-
    4. 
-

-
-
-
-
-
-Revision History
-
-
-
-
-
-
-
-
-
-
-
-
-
DateReleaseEditorPrimary clauses modifiedDescription
2024-08-22NoneGérald FenoyallBoostraping the document

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

-
-
-  2024-11-14
-  
-OGC API
-
-  
-Processes
-
-  
-Part 1: Core
-
-  
-OGC API — Processes — Part 1: Core
-
-  http://www.opengis.net/doc/IS/ogcapi-processes-1/1.0.0
-  https://docs.ogc.org/is/18-062r2/18-062r2.html
-  18-062r2
-  
-    2021-12-20
-  
-  
-    
-    
-      
-          Benjamin Pross       
-
-    
-  
-  
-    
-    
-      
-          Panagiotis (Peter) A. Vretanos       
-
-    
-  
-  
-    
-    
-      
-Open Geospatial Consortium
-
-    
-  
-  2
-  en
-  
-  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.
-  
-
-Fenoy, G.: OGC 20-044, OGC API — Processes — Part 2: Deploy, Replace, UndeployOGC 20-04420-044
-Jacovella-St-Louis J.: OGC 21-009, OGC API — Processes — Part 3: WorkflowsOGC 21-00921-009
-
-  2024-11-14
-  
-OGC API
-
-  
-Features
-
-  
-Part 1: Core
-
-  
-OGC API — Features — Part 1: Core
-
-  http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0
-  https://docs.ogc.org/is/17-069r3/17-069r3.html
-  17-069r3
-  
-    2019-10-07
-  
-  
-    
-    
-      
-          Clemens Portele       
-
-    
-  
-  
-    
-    
-      
-          Panagiotis (Peter) A. Vretanos       
-
-    
-  
-  
-    
-    
-      
-          Charles Heazel       
-
-    
-  
-  
-    
-    
-      
-Open Geospatial Consortium
-
-    
-  
-  3
-  en
-  
-  OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.
-
-The OGC API family of standards is organized by resource type. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term ‘feature’ for things in the real world that are of interest.
-  
-
-
-Bibliography
-  OpenAPI Initiative. OpenAPI Specification 3.0.2. Available at:
-.
-  OpenAPI Specification 3.0.2
-  3.0.2
-
-  Peter Amstutz, Michael R. Crusoe, Nebojša Tijanić (editors), Brad Chapman, John Chilton, Michael Heuer, Andrey Kartashov, Dan Leehr, Hervé Ménager, Maya Nedeljkovich, Matt Scales, Stian Soiland-Reyes, Luka Stojanovic (2020): Common Workflow Language, v1.2. Specification, Common Workflow Language working group. 
-  [2]
-
-  OpenEO: OpenEO Developers API Reference / Process Graphs. 
-  [3]
-
-
-
-
-
-
diff --git a/extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc b/extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc
index 4feb104a..f257518a 100644
--- a/extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc
+++ b/extensions/job_management/standard/recommendations/provenance/prov/PER_content-negotiation.adoc
@@ -1,8 +1,8 @@
-[[per_job-provenance_run_content-negotiation]]
+[[per_job-provenance_prov_content-negotiation]]
 [permission]
 ====
 [%metadata]
-label:: /per/provenance/run-content-negotiation
+label:: /per/provenance/prov-content-negotiation
 part:: Content negotiation MAY be supported to provide alternate representations of the response.
 part:: The server MAY support the following additional content type: `application/ld+json` for PROV-O as JSON-LD
 part:: The server MAY support the following additional content type: `application/xml` for PROV-XML 

From fbbbed4b11d1a8f14ae0afaeb8457f56f6a42146 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A9rald=20Fenoy?= 
Date: Thu, 14 Nov 2024 17:36:38 +0100
Subject: [PATCH 3/3] Fix typo, thanks @fmigneault

---
 openapi/schemas/processes-job-management/inputs.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/openapi/schemas/processes-job-management/inputs.yaml b/openapi/schemas/processes-job-management/inputs.yaml
index 245e237f..79ead9ad 100644
--- a/openapi/schemas/processes-job-management/inputs.yaml
+++ b/openapi/schemas/processes-job-management/inputs.yaml
@@ -20,6 +20,4 @@ properties:
     items:
       $ref: "../processes-core/metadata.yaml"
   headers:
-    type: array
-    items:
-      $ref: "headers.yaml"
\ No newline at end of file
+    $ref: "headers.yaml"
\ No newline at end of file