Jobs should be its own standard, co-branded with Common

[cportele]

Part 1 should be split into two documents

• OGC API - Jobs - Part 1 / OGC API - Common - Part 6
  • Every GET operation on /jobs and its sub-resources
  • DELETE on /jobs/{jobId}
• OGC API - Processes - Part 1
  • The rest of the current document, depends on Jobs Part 1.

Rationale:

• Other OGC API standards that support async requests are also using the Jobs endpoints without the Processes overhead. In Features, OGC API - Features - Part 10: Queries and and OGC API - Features 11: Atomic and batch transactions are currently using them, but do not have a good dependency to reference. If that would exist, OGC API - Features - Part 4 / OGC API - Common - Part 5: Create, Replace, Update and Delete would reference the Jobs standard, too.
• Because the Jobs resources can be reused in other contexts outside of Processes, it should be co-branded with Common.

[jerstlouis]

cc. @joanma747

[fmigneault]

Async execution without a /jobs endpoint makes no sense. Half the requirements of Core are about disambiguating sync/async, inline/job-results responses, and their respective structures, so I don't think it would be wise to separate them. It would create more confusion in an already complex standard. Also, given that Core v1.0 already includes /jobs, Core v2.0 transition with separate Parts would be even harder to adopt by implementers if we move too many things around.

Core defines the minimal stuff needed for aync, while OGC API - Processes - Part 4: Job Management contains the additional elements for advanced job features. I'm interested to hear about what could still be missing in Part 4 though to further extend it if extra capabilities are identified.

In Features, OGC API - Features - Part 10: Queries and and OGC API - Features 11: Atomic and batch transactions are currently using them

How are the jobs submitted in these cases?
In Processes Core, POST /processes/{processID}/execution is used. In Part 4, POST /jobs with more variants is available. If Part 4 adjusts the Processes Core prerequisite (which I believe is not actually required), that could be the reference employed by Features/Common/others.

[jerstlouis]

@fmigneault The Jobs - Part 1 would be the definition of the /jobs endpoint.

The submission part would not be described in this Part 1, but by the standards referencing it (Processes - Part 1, Processes - Part 4, Features - Part 11, Coverages, etc.).

[cportele]

@fmigneault

How are the jobs submitted in these cases?

For queries, e.g., by a POST to /query; for transactions by a POST to /transactions. The jobs that are created should be available under /jobs.

[fmigneault]

I'm not against trying out a "Commons: Part X - Jobs", but this is opening a huge can of worms. Core v2 took ~5 years of work, and there is still many open requests to extend it further. Other Parts (workflows, jobs, provenance) are in high demand with ongoing OGC initiatives. I really don't think we should delay Core again for many years. We should focus instead on refining other Parts that have already been pending for too long.

I think Part 4 could instead define a bridge "Core-compatible" GET /jobs and GET /jobs/{jobId} conformance class, without direct dependency to Core, and achieve essentially the same goal.

[bpross-52n]

SWG Meeting from 2026-08-31: We will add a note to the standard saying that in a future version the Jobs-Section will become a separate standard.