Identifier Syntax for API Common

[cmheazel]

This issue was originally discussed in API-Coverages.

"In several places we use identifiers (such as coverages, collections). We should define admissible names and their representation, such as: char set, encoding, entities for escaping special characters, etc."

API-Coverages SWG identified this as an issue which impacts all OGC API standards.

Suggested resolution is to take the following from OGC API - Features" ?

"This document does not restrict the lexical space of URIs used in the API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of RFC 3986 for details."

[cmheazel]

@ghobona recommended to the OGC NA that "any restrictions on identifiers or paths to resources be designed and applied by the individual OGC API standards." (see Naming Authority Issue 55). This position was accepted by the OGC NA.

The OGC Naming of OGC API Standards, Repositories & Specification Elements policy reflects this decision through its' lack of any restrictions on URI or URI Template components beyond those imposed by the governing IETF RFCs..

@ghobona also recommended in API-Coverages Issue 19 that the following text from API-Features be included in API-Common "This document does not restrict the lexical space of URIs used in the API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of RFC 3986 for details."

This recommended text is identical to the contents of section 6.4 of API-Common Part 1.

The existing contents of API-Common Part 1 is consistent with OGC Policy and the practices of other API SWGs. Recommend that this issue be closed.

[joanma747]

WE agreed on this on 2020/07/27