Case Sensitivity

[cmheazel]

From the API Hackathon report:
There was a discussion about whether parameters, values and URL bases were case sensitive. This
issue was observed to be applicable to all of the specifications. There was a suggestion that the OGC API - Common specification should specify a rule for case sensitivity and that that rule should be consistent with the relevant standard of the Internet Engineering Task Force (IETF).

[cmheazel]

API-Coverages is using all lower case for URL parameters, etc. See Issue 11. Are there any objections to adopting this convention across all OGC APIs? Are there other case conventions we should adopt?

[hylkevds]

The SensorThings API uses camel case with lowercase for the first letter. For longer parameter names this gives better readability. For example:

orderBy
resultFormat

[cmheazel]

Recommendation: Align with the conventions used in other APIs, validate this approach with the Doc Team and NA, make any necessary updated, close.

[cmheazel]

API-Common currently aligns with API-Features and SensorThing in the use of lower camel case. There is no compelling reason to change this convention.

The OGC Naming Authority (see Issue #153) assigns this decision to the individual SWGs. So a decision by API Common to use lower camel case is not binding on names defined by other API SWGs.

Recommendation: continue using lower camel case and close.

[jerstlouis]

@cmheazel It is not clear from this issue discussion what the sensitivity conclusion is?

I argue that query parameters should remain case-insensitive as they have been in OWS.
Camel case could be a recommendation and the approach used consistently in the specifications.

[m-mohr]

Isn't implementing case-insensitive query parameters a bit of a pain in servers? At least what I'm programming with is case sensitive and thus retrieving the parameters would get annoying. What's the advantage of case insensitivity?

[jerstlouis]

@m-mohr In our server implementation it is rather trivial to do case insensitive string comparison of query parameters.

The main advantage would have been keeping with the OWS convention of query parameters being case-insensitive, which I think could have eased the transition to the OGC API, and people hand-crafting URLs not being bitten by case sensitivity issues.

But I am only realizing now that Features and the OpenAPI approach is requiring case sensitivity, and that not being sensitive to case as we currently do probably breaks requirement query-param-unknown as discussed in #131.

It should be made super clear that query parameters are case sensitive, considering people may come in with assumptions from OWS where the same query parameters were case insensitive (I still had that assumption myself until now).

[m-mohr]

Are there any other APIs out there that do case-insensitive? I feel like it's a bigger burden to implement than it would help. The other thing is that implementing standards should be able to decide to allow only case-sensitive as it would break a lot of implementations that are already out there (looking at Features and STAC). So my vote goes for case-sensitive.

[cportele]

They have to be case-sensitive since this is what the HTTP and URI RFCs require. From RFC 7230:

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.

To specify them as case-insensitive the API definition must define the query parameters so that the parameter name matches all variants. All the existing standards define the parameters in a case-sensitive way, so you must use, for example, datetime, not DATETIME or any other variant.

[jerstlouis]

@cportele and OpenAPI does not define a mechanism by which it can specify case-insensitive query parameters to ignore case?

Today I learn all this :) So really I hope this is clarified in Common. If I search for sensitive in Features (http://docs.opengeospatial.org/is/17-069r3/17-069r3.html) I find nothing relevant.

And people like me may come from OWS (rather than from the OpenAPI world) with assumptions to be broken.

[m-mohr]

OpenAPI does not define a mechanism by which it can specify case-insensitive query parameters to ignore case?

No, OpenAPI clearly says Parameters are case-sensitive. There's no way around it due to the mentioned RFC.
I think the only part that is case-insensitive are HTTP headers.

I actually think Features doesn't need to mention sensitivity at all if it bases on the mentioned RFC. It could mention it for clarity though.

[pomakis]

I'm okay with dictating that query parameter names are case sensitive, as long as it doesn't require the server to reject alternatively-cased parameter names. I believe that requirement 3 (/req/core/query-param-unknown) of "OGC API - Common - Part 1: Core" curently requires this.

  IF the request URI includes a query parameter that is not specified in the API definition
      THEN
  The server SHALL respond with a response containing the status code 400.

This IMHO is way too strict. A server should be allowed to accept

  {landingPage}/collections?LIMIT=10

as being the equivalent of:

{landingPage}/collections?limit=10

This would be vendor-specific behaviour that a client shouldn't rely on, but the server should be allowed to have this vendor-specific behaviour.

See #131.

[jerstlouis]

@pomakis I support your stance on that, but that does go against what is discussed in #131.

[joanma747]

@ghobona has an action on him to track down a resolution coming from the NA that states how case sensitivity should go. NA will check this in a later stage.

[cmheazel]

OGC Naming authority issue 71 proposes use of Kebab-case for query parameters. API-common part 1 has been updated to implement this policy (recommendation 7).

[cmheazel]

February 1 - close - NOTUC