Feedback on 2.0 (CODE SPRINT JAN 2026)

[jerstlouis]

Below is my feedback reading through the candidate standard (up to end of 7-Core -- will create separate issue for Sections 8 Collections+):

Abstract

• The Abstract has tables. I think it would be a better fit to move these to Section 6 Overview which is currently very small. AFAIK the Abstract is intended to be text only / easy to include in a summary description of the document
• I would also suggest not including so much "background context" about WPS in the abstract (other than e.g., one sentence that OGC API - Processes is the modern REST/JSON-based successor to WPS), and focus more on summarizing what this particular standard is. Maybe the more detailed WPS background could be a sub-section of the Overview section
• In table 1, I would call the "Result" resource "Individual output result" to clarify the distinction with "Job results"
• "Additionally, the /jobs endpoint can be used to grant access to a list of jobs." -- I do not understand what this sentence means

Preface

The Standard specified who to “wrap” computational tasks into an executable process that can be invoked by a client application.

How?

Security Section

• It's a bit unusual that the Recommendation 1 is within the Security section rather than within the main body of the document
• Everywhere in the document it seems that there is both Identifier and Label (with identical URIs). I think we should only keep
  Identifier (Label was the pre-metanorma thing).

Acknowledgements

• Please include an acknowledgement section to credit the work done as part of our GeoConnections project using the following exact language below (and other things if appropriate):

Requirements integrated within version 2.0 of this OGC API - Processes Standard was sourced from Part 3: Workflows, whose development was undertaken as part of GeoConnections 2020-2021 and 2025-2027 projects GNS20-21IFP02 (Modular OGC API Workflows) and GNS25-27IFP2 (Advancing and Implementing OGC Standards for GeoDataCubes, DGGSs, Data Stores for Digital Twins and Cartographic Symbology). Financial support provided by GeoConnections, a national collaborative initiative led by Natural Resources Canada. GeoConnections supports the modernization of the Canadian Geospatial Data Infrastructure (CGDI). The CGDI is the collection of geospatial data, standards, policies, applications, and governance that facilitate its access, use, integration, and preservation.

Conformance

• for the resources specified in the Corea (remove the a)
• The Collection Input, Remote Collections, Collection Outout, Local Filtering conformance classes are missing here from both the table and summary.
• I think we also want at least "Derived Properties", and possibly also "Filtering", as separate conformance classes (so that implementations can support Collection Input without forcing them to implement Derived Fields)

Normative References

• WPS 2.0 is included as a normative reference . I don't think that should be? It is not a dependency of any requirement, is it?

• Is OGC API - Common - Part 1 not included on purpose? Is this an intended change from Version 1? It seems that Version 1's Core requirement class had an explicitly dependency on OGC API - Common - Part 1: Core's "Core" requirement class

Terms and Definition

• Collection: could we update this to the latest definition in Part 2:

(in the context of OGC APIs) A set of spatiotemporal data that may be available through one or more access mechanisms defined by OGC API standard(s)

• data access mechanism -- might also synchronize that definition:

(in the context of OGC APIs) mechanism defined by an OGC API Standard to access spatiotemporal data from a collection

• process: Processes that have no process inputs represent value generators that deliver constant or random process outputs.
  I would argue that a process taking no input (from the executing client) can return outputs which are neither constant nor random. e.g., it can be sensing things from the environment or from inputs not coming from the client but from hard-wired connections on the server side (e.g., I can hook up my electric piano via MIDI to an OGC API - Process and serve what I'm playing via a process taking no input from the client)
• 4.1.18. process output (explicitly requested)
  A process output with identifier {outputID} that is explicitly specified in the “outputs” section of an execute request.
  This is confusing here, because it seems to imply that if you omit the outputs completely (defaulting to all output), you will not get a .../results/{outputId} for each output? I don't think that should be the case. I would personally not include 4.1.18. process output (explicitly requested) and 4.1.19. process output (implicitly requested) in the Terms and Definitions, but include those clarifications in the execution / output sections.
• 4.1.20. remote collection -- I would try to use the positive here instead of saying what it is not (local)... e.g., "available from an external OGC API deployment (different from the deployment whose process is being executed)..."

Conventions

• In all the OGC standards that I'm editing now (since OGC API - Maps) we use HTTPS URIs everywhere for everything (including conformance classes), following a request by the OAB to do so. The argument was that several organizations have security policy that prevent them from accessing HTTP URIs completely. I realized that this practice is not being consistently applied across the different OGC standards being published and that's a bit puzzling -- can we apply it here for this standard?

Core

• The URL for accessing status information is delivered in the HTTP header location. -- Please make this HTTP response header and uppercase L: Location
• In Figure 1, the Process resource box has mode, response, subscriber -- are these still a thing? I don't see them in process.yaml or processSummary.yaml or descriptionType.yaml (I do see jobControlOptions, links, version that is missing though). subscriber is for the execution request, but this is the process description, right? Also version is marked as required, is it really necessary to make version required? Forced metadata is a recipe for bad metadata.
• As I mentioned above, the dependency on OGC API - Common - Part 1 was removed -- can we add it back?
• The mapping in Table 9 to Common req. classes is not right, and the req. class URIs use a /2.0 where that should be 1.0. The API Landing Page, API Definition and Conformance is defined in the landing page conformance class -- not core: http://www.opengis.net/spec/ogcapi-common-1/1.0/req/landing-page,
• Recommendation 2 is missing the "Statement" or Part (A, B...)
• The text regarding content negotiation and the following notes are very confusing:

If multiple API definition formats are supported by a server, use content negotiation to select the desired representation.
NOTE: Two common approaches are: (... An additional path for each encoding ... An additional query parameter)

This seems to suggest that the approaches to content negotiation are the suffixes and/or query parameters INSTEAD of the proper HTTP content negotiation via the Accept: request header

• Example — Requirements class response document -- this still has 1.0 example conformance classes listed
• using the profile parameter -- please clarify query parameter to distinguish from path parameter (everywhere)... also for 7.8 limit query parameter below
• 7.7 specified the Link header with rel="profile" in the request headers. -- Is this really a thing including Link header as a request header? I have never seen that before and Link is normally a response header... The Link rel=profile is normally a response header for the server to tell you which profile it actually applied (as stated below). Seems like that is at least one too many/unnecessary ways to do the profile negotiation (I would stick to only the profile query parameter and the Accept-Profile: request header myself)
• 7.10. Retrieve a process list -- implmentation missing an e
• 7.10.1.2 (Query) Parameter limit -- Recommendations 10, 11, 12 about limit seem like they should not be recommendations but describe the basic way how the paging works, with the limit query parameter being required. While I would argue that for the use cases of servers supporting less than 100 processes paging should not be mandatory to be supported and the entire thing should be a recommendation, it does not make sense to me to make these 3 specific things only recommendations. Make the whole thing optional, or make the whole thing (with the exception of the prev link) requirements. It would also help in my opinion to collapse some of these separate statement into multiple parts of the same requirement.
• Recommendations 16 and 19 make recommendations for CLIENTS. Since Section 2 conformance says The standardization targets of all conformance classes are “Web APIs.” (and not clients), then perhaps these recommendations could be changed to an IMPORTANT: note rather than formal recommendations.
• Requirement 30: The content of response body SHALL be the requested process output value in the default output format. (when no Accept: header is used)
  Should this not be the specified output format specified in the execution request, which I think we still have? (is there actually an explicit "default" format specified in the description?)
• Permission 9: has a pre-metanorma left-over saying "part"
• Requirement 39 ( /req/core/job-op ) -- The server SHALL support the HTTP GET operation at the path /jobs/{jobID}. -- This is missing conditions to clarify that this is not required for synchronous execution
• Requirement 40 -- This requirement is not set up properly in metanorma, with Statement appearing multiple times instead of A, B, C... There's a typo inidicate. It's also missing the conditions like req. 39 to be only required for Async.
• Requirements 41, 42, 43, 44, 45 ( /req/core/job-results-op ) are missing conditions about being only required for Async. -- Would it make sense to move all the Async stuff into an Asynchronous Execution / Job management requirements class? That would still not prevent Sync execution still creating a job for servers that want to do that. It would greatly help to keep the Core req. class simpler / smaller.
• Requirement 44: /req/core/job-results-param-outputs-response -- Only the outputs with identifers specified by the optional outputs parameter SHALL be included in the response. -- What is this talking about? Is it talking about the outputs property in the execution request? If so, it would help to clarify this by not using the word parameter here (say property) and mention of the execution request, and also clarifying: "(or all outputs when not specified)".
• Requirement 50 The request is executed on a running job with valid job identifier jobID. -- missing a d

@pvretano @bpross-52n

[fmigneault]

➡️ Process output explicit/implicit

The definitions were added to allow a cross-reference link rather than plain text, which makes it easier to find what they refer to, since the terms were previously only "mentioned as is" and it wasn't clear what they were referring to, since the execution request section is massive.

---

➡️ Recommendations 16 and 19 about Prefer

While the recommendations are described from the client perspective, the equivalent can be done for server / Web APIs, which would be something along the lines of:

"A client that accompanies an execute request with the HTTP Prefer header asserting a XXX preference is allowed to ignore the preference if it deems it inappropriate for the purpose of the processing requirements."

This is by-definition of Prefer, as further explained in #539 (comment)

IMO, the client perspective is better because it warns about the parameter not being a "guarantee", and how implementers will interact with the server. You must validate the response's Preference-Applied to cross-check, or be ready to receive anything. The server perspective is somewhat more ambiguous, but I wouldn't mind such rewording if it is deemed necessary.

---

➡️ Requirement 30 - output format default

This is specifically about the case where the execution request omitted any indication, either via the Accept AND other methods (3rd condition).

It falls back to the process description's output format. For the case where Accept/other format was provided, it is Requirement 29 just above.

---

➡️ Requirement 44: /req/core/job-results-param-outputs-response

It is referring to the outputs query parameter described above (Requirement 33).

What it indicates is that doing GET /jobs/{jobID}/results?outputs=output1,output2 can further filter the outputs listed in the result response.

Adding "query" and a cross-ref to Req33 could make it more explicit to avoid confusion with outputs of the execution body (that is sufficiently described in the execution request section with case-by-case requirements).

[jerstlouis]

@fmigneault

Process output explicit/implicit

I still think that distinction is out of place and unnecessary in the terms and definitions. Whether an output is explicitly or implicitly returned changes very little. Requirement 61 and Permission 13 are the main place that this terminology is used and in both cases it's used in a way that it "doesn't matter" (implicitly or explicitly), highlighting that this distinction is irrelevant. Requirement 27 says that not specifying "outputs" implies all outputs are returned. That's really all that needs to be said.

IMO, the client perspective is better

It's fine to highlight the client perspective, but that should be in an IMPORTANT: admonition block rather than a formal requirement since the target for conformance testing is the server rather than the client.

If additional requirements from the server perspective are needed they could be added as well.

This is specifically about the case where the execution request omitted any indication, either via the Accept AND other methods (3rd condition).

The 3rd condition is not enough in my opinion, because the "outputs": {...} section of the execution request does not really fall into the concept of HTTP "content negotiation". There should be an additional condition clearly saying the output format/media type was not selected in the execution request.

It is referring to the outputs query parameter described above (Requirement 33).

Requirement 33 is not describing a query parameter! It's talking about the outputs property of the execution request.
There is no outputs query parameter -- is there??

[fmigneault]

I agree the requirement should be enough on its own, but even then, we got a lot of previously raised issues/discussions about the ambiguity and expected interpretation of outputs (eg: #412). The problem is always that it is possible someone lands on a certain requirement section without having the full context, and "number of outputs" is easily misunderstood if the request purposely omits outputs.

Maybe the explicit/implicit distinction could be combined into a single element. I agree they do not need to be separate, but I think having the link there helps find the context quickly and highlights that there is a special consideration when reading this text, and not just a figure of style in the writing.

---

It is fine to have the IMPORTANT: block for the client. However, another server Permission entry MUST be introduced for the server, since Prefer MUST be allowed to be ignored. We can't say that Prefer RFC-7240 is used and then require going against literally the first part of its definition: https://www.rfc-editor.org/rfc/rfc7240.html#section-2

It is critical that readers understand that passing Prefer is not a guarantee of behaviour by the server, and a successful response is not an indication in itself that it was respected. Server implementers are allowed to ignore it if they consider it inappropriate.

---

The Req30 3rd condition mentions "No content negotiation has been specified using either HTTP headers or other methods.". The "other methods" simply refers to any other way to resolve it, such as the format that must be passed via the JSON body, or queries for KVP execution, because header-based content-negotiation cannot be applied for specific outputs when N>1. When moving to the N=1 outputs case of Req30, you are still allowed to use the same in-body/query format negotiation.

It really does not matter if it is the execution body, header, query, or some other mean. The important part is just that it was not provided, so the process's description default format is the last resort.

Adding more conditions would just add distractions about this.

---

It is referring to the outputs query parameter described above (Requirement 33).

Requirement 33 is not describing a query parameter!

My bad, I typo'd. I meant 43, as indicated by the "described above" when talking about 44.

[jerstlouis]

Maybe the explicit/implicit distinction could be combined into a single element. I agree they do not need to be separate, but I think having the link there helps find the context quickly and highlights th

I agree that this implicit/explicit output needs to be carefully explained, but the Terms and Definitions is not really the right place -- people are unlikely to even see it there. However, there could be a NOTE: added to the single "output" term definition that summarizes the nuance.

However, another server Permission entry MUST be introduced

Adding a permission would be good.

because header-based content-negotiation cannot be applied for specific outputs when N>1.

Header-based content negotiation still works for N>1 outputs when you request at /results/{resultId}. That was the whole point of that new resource.

Adding more conditions would just add distractions about this.

I really disagree. There are two completely different concepts here:

• A) Content type negotiation is when retrieving results at /results/{outputId}-- the any other method refers to things like a .tiff suffix, a ?f=tiff, or Accept: image/tiff; application=geotiff request header
• B) Output format selection is at the moment of submitting the execution request. That is a format specified in the "outputs" property.

A server may or may not still support transcoding the selected output format at result request time using content negotiation.

But there is the concept of the "selected output format" at execution time, which is either the selected or first output format in the process description.

In the case of synchronous execution with a single output, A) and B) get combined.

So without an additional condition, my interpretation is that the requirement is only talking about A) and not B).

[fmigneault]

NOTE: added to the single "output" term definition that summarizes the nuance.

I'm fine with that if it is link-able. I don't really mind "where" the details are otherwise.
The problem occurs only if it is a note block as-is that gets lost across the requirements, tables, etc.

---

Header-based content negotiation still works for N>1 outputs when you request at /results/{resultId}.

Requesting it there might involve rerunning the big process, depending on the nature of the contents. It is possible that the process handles multiple outputs formats, but not as output<->output conversions, only as branch A/B output formats.

In that sense, it is preferable to pre-select the formats per specific output in the request body.

---

I think "Output format selection" makes sense. Not against having it as extra details/conditions.

I'm only worried it could introduce subtleties that will confuse readers if not properly explained.

The way I saw them is like "overrides".

• If you use Accept/?f=, it overrides anything indicated before in the execute request and the process default.
• Else, if you indicated outputs: {...} with a format for a given output, it overrides any default.
• Else, pick the default since no other choice.

Regardless of sync/async, all apply.
Regardless of one/many outputs, all apply.
The closer you are to the response, (or the farther away from the process->execute->result), the more "override" it becomes.

The only sync/async distinction is that Accept/?f= takes effect "closer" within the same request/response transaction vs async "later" via /results/..., but sync is still allowed to preemptively provide the output formats in the body, or use /results/... after the fact (if job created) to yet again override the output format.

In every single case except sync-one-output, Accept/?f= means the "results content holder".
Only when sync-one-output, Accept/?f= can also mean the output itself (if not profile=ogc-results).
However, that does not disallow it from omitting Accept/?f= and use body output format as in the other cases.

[jerstlouis]

@fmigneault

Requesting it there might involve rerunning the big process,

Requesting it there specifically does NOT involve rerunning the big process.

If the processing engine does not handle output <-> output transcoding, then the server would return 406 Not Acceptable, and the client needs to re-submit a separate execution request if it really wants that output format.

But if the processing DOES handle output <-> output transcoding, then it just happily returns the output as requested as a 200.

I think that is a different interpretation from your "overrides" explanation?

You definitely do not want to force "re-execution" for requests to /results/{outputId} (and modify previous results of a job).

The output-level content negotiation only makes sense if the server supports transcoding from the stored result format (without modifying the job results).

[fmigneault]

Of course, it does not rerun the process unnecessarily if Accept is handled and returns 200. You can safely take advantage of generating that output with any allowed variants the server will support for it.

My point was more toward the fact that, since some processes must preemptively indicate the output format because 406 is obtained otherwise on /results/{outputId}, they cannot rely on that endpoint's content-negotiation. Since "format selection" must be handled for that use case, that means the server must handle "overriding" any desired "format" specifier with both variants, whether passed beforehand in the execution request or after in the results. Since both must be implemented anyway, and using job results content negotiation requires creating the job, it seems easier to me to always support "format selection"/"content negotiation" no matter the execution mode (at least, that's what I do...). It would be more code/condition to ignore them only in particular execution modes.

When in sync, these 2 places resolve the output format only within the same transaction, but can still consider either variant. The pipeline is the same for me, regardless of the execution method or result retrieval. That is why it seems redundant to me to have the extra condition and different concept names just for a specific requirement, but I'm not against it if it claries for you.

[jerstlouis]

@fmigneault

Since "format selection" must be handled for that use case,
Since both must be implemented anyway, and using job results content negotiation requires creating the job,

In my interpretation and original idea, it is optional for the server to support content negotiation at /results/{outputId}, and the server is totally allowed to return 406 if the client is requesting a format different than the one that was selected in the execution request. It should return a 406 instead of "re-executing the job" upon content negotiation (though of course it is technically allowed to re-execute, and that might be fine if the job is not costly resource-wise).

[fmigneault]

You are allowed to always return 406 if you do not (or not want to) support /results/{outputId} conversion when it is misaligned with the execution request. That is a conscious implementation choice of not handling it.

But then, you don't have a choice to support "output selection" via the execution request instead, or else a multi-output process allowing more than one format in the process description is simply impossible.

The "output selection" approach with execution outputs: {...} always works, whether output transcoding is possible/supported or not, or that the process must always rerun from scratch, since the execution knows the desired output in advance. So you have even more incentive to handle "output selection" by outputs: {...} regardless of sync/async single/multi output. Adding the /results/{outputId} content negotiation support is bonus.

Since the outputs: {...} format section must be implemented anyway, this is why I have said since its introduction that Accept for sync-one output's format is an odd case that always brings complexity to the Execution Responses table, contrary to all other cases that use Accept for the "result container" of the outputs and outputs: {...} for their individual formats, rather than hacking Accept for the single output itself (and the ambiguity it created until Profile=ogc-result was added).

In my (much more explicit) Execution Result table, I do not even distinguish sync/async because the pipeline is always the same for me. I describe output formats in terms of Results, not Responses. The Responses aspect is only involved when sync/async is applied, after Accept/outputs: {...} affecting the Results output format was resolved the exact same way, with the same Accept->format->default precedence order mentioned in #538 (comment). Because that output resolution order is always the same for me, this is why I think Req30 conditions are sufficient. I do not treat it as a special case where "content negotiation" means something else.

[jerstlouis]

But then, you don't have a choice to support "output selection" via the execution request instead,

Correct, supporting "output selection" (at execution time) is mandatory.

Post-processing-output-format-negotiation (transcoding the output results without re-running the job) is optional.

Accept for sync-one output's format is an odd case that always brings complexity

That's the case where "output selection" and "output format negotiation" happen within the same POST operation.
In normal circumstances, the client either only uses one or the other mechanism (output format, OR Accept:), or uses both with the same consistent media type. If the client uses two conflicting media types, then one needs to override the other -- I would say Accept: header should override if it specifies a supported format.

[fmigneault]

In normal circumstances, the client either only uses one or the other mechanism (output format, OR Accept:), or uses both with the same consistent media type. If the client uses two conflicting media types, then one needs to override the other -- I would say Accept: header should override if it specifies a supported format.

Yes, that is what I do as well (Accept overrides), though I think if an implementation decided to do 406 in that particular ambiguous case of conflicting output selection, it would be valid as well.