opengeospatial / opengeospatial/ogcapi-processes

Clarify the use of Content Negotiation and the `f` query expectations

Open
#576 7 comments 0 reactions 1 assignee View on GitHub

@pvretano is already working on this.

Since Apr 27, 2026.

Dominant language
AsciiDoc
Stars
63
Forks
46
Avg merge
2d 1h
Merged PRs (30d)
8

Description

Detail

While browsing the OGC API - Processes - Part 1: Core draft, I noticed that the ?f= query is not that well-defined in terms of expected requirements.

There are some examples using it, such as the 7.2.2. Response - Landing Page Example or 7.10.2. Response - Process List Example 2.
There are also some mentions in the extra note under 7.3.2. Retrieve an API definition - Response and 10. Requirements classes for encodings.

However, beside those, it is not really indicated explicitly (a permission or recommendation) that it may be supported.

Also, there are not many cross-links applied when mentioning "content negotiation" in general in some descriptions, so one as to somewhat land on these notes by chance to be aware of them.

Furthermore, 10. Requirements classes for encodings (which could also be better cross-linked when mentioning "Content Negotiation" across the text) mostly refers to:

Both of these references are mostly referring to Accept, Accept-Encoding, Accept-Language, etc. Therefore, it is still not that obvious that ?f= could apply as well, or that 7.7. Content negotiation by profile might also be involved.

In certain cases, like for 7.3.2. Retrieve an API definition - Response, the plain text "content negotiation" without any cross-reference might actually be misleading since Accept, etc. are not obviously indicated, and the note just after it quickly highlights the (IMO, less-preferred than header) alternatives using a file extension or accept/f queries.

Actions

I recommend:

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.