Wrapping OGC API Features datetime queryable into an OpenSearch description

[ycespb]

The requirement (25D / 25F) /req/core/fc-time-response in OGC 17-069r2 does not allow to wrap an OGC API Features API supporting the datetime queryable in an OSDD URL template consistent with OGC 10-032r8 (Geo-temporal extension of OpenSearch) as the encoding of open-start and open-end imposes (?) the use of ".." (double-dot) while OGC 10-032r8 encodes the "interval" using two distinct parameters representing the start and the end of the time interval..

Even an OSDD URL template containing "datetime={time:start?}/{time:end?}" cannot be used to wrap this query part as the resulting open-end or open-start intervals would not contain".." when the OpenSearch client does not provide a value for {time:start} or {time:end} and thus leaves them empty, but would be encoded (in BNF) as "/" "date-time" or "date-time" "/".

Propose to relax Requirement 25F and make the double-dot optional in the parameter encodng (preserving the slash). Alternatively, OGC 10-032r8 will have to be updated to allow it to be used to wrap also OGC API Feature compliant API, e.g. by allowing ".." to represent a missing "date" or by defining a new OpenSearch queryable "time:datetime" which none of the current server implementations currently support.

[cportele]

This is tricky since the new ISO 8601-1/2 use "" for an unknown start/end and ".." for an open start/end, which is something different.

10-032r8 seems to imply open start/end if the time parameters are not provided.

Maybe we could also allow unknown ("") and state that for the selection of features it should be treated the same as an open interval since the actual value is unknown?

See also #155 (comment).

[ycespb]

Yes. That would cover nicely the case where one of the two dates is unknown. Would this also allow both dates (start and end to be unknown simulteanously, thus the value of "datetime" would be "/" if the (OpenSearch) client does not fill the time:start and time:end which are both optional.. ?

[cportele]

SWG call 2019-08-12: Clemens to create a pull request and merge it. We want to support the OpenSearch time extension and thus we accept the slight "hack" (ISO 8601-1/2 uses "" for an unknown start/end and ".." for an open start/end, which is something different).

Note: "../.." or "/" are then also acceptable values.