update schema of Part 3 field modifiers

[fmigneault]

• add filter-lang and filter-crs for Part 3 field modifiers
• add a basic CQL2-JSON variant for filter
• fix indents of the schema

[jerstlouis]

Thanks @fmigneault .
I can see we could need filter-crs, though this introduces the question of which CRS are supported by a particular implementation and which are required to be supported.

As I mentioned in the other issues, I would not introduce filter-lang, since unlike in the features Filtering exptension, here it comes in as a JSON object or string, so we can easily deduct CQL2-Text vs. CQL2-JSON.

Regarding the CQL2 JSON, I suggest we bring a local copy of the CQL2 JSON schema here and $ref it.

For the derived fields ("properties") and "sortBy", we would need support for extended CQL2, as we have in CartoSym-JSON, where the result of the overall expression is not limited to a boolean predicate.

[fmigneault]

In the long run, I think filter could be simply defined as

filter:
  type: {}

As long as the server knows the filter-lang, anything should be allowed.
For example:

• JFE: https://github.com/tschaub/ogcapi-features/tree/json-array-expression/extensions/cql/jfe
• FES: https://docs.ogc.org/is/09-026r2/09-026r2.html

At that point, depending on string vs array/object to resolve CQL2 Text/JSON won't be sufficient anymore.

Whether the server understands filter-lang and filter-crs, and for any given values, that should be provided in its OpenAPI definition, or using Sortables.

[jerstlouis]

JFE

I strongly dislike the Mapbox JSON expressions ;)

In order to make these workflows re-usable, I was really going to suggest we require support for CQL2-Text and encourage use of that everywhere.

filter-lang, CQL2-JSON, JFE, FES, could all be introduced as custom extensions, but since this is part of the workflow being defined by the end-user which may integrate several different end-points, and we hope for these workflows to be re-usable (and not what is being negotiated between two hops separately from what goes in the workflow), I feel like we should not introduce more options than necessary for the workflow definition itself.

[fmigneault]

We can certainly put CQL2 in the forefront of API specifications to "strongly recommend" their use, but we can't introduce filter-lang and expect everyone to only use CQL2-text. The standard must provide the means for a server that does support other languages to indicate and make use of it.

I do not think filter-lang is big enough to be an extension. It is similar to GeoJSON/GML+XML representations for equivalent "concepts". If a server does not support anything else than CQL2-text, it should 400 the request, just like an unsupported media-type would result in 406.

I think forcing every implementation to use CQL2-text would be limiting use cases.