Resolve divergences between OGC API common part 1 and OGC API Features. #359
Description
In order to allow OGC API Features to reference OGC API Common part 1 we need to ensure that there are no divergencies or incompatibilites.
This is a OLD list of considerations that @cportele has send to this group as a starting point:
The question of differences between Common Part 1 and Features Part 1 is not easy to answer. While Common Part 1 started with a fork of the contents of Features Part 1 in September 2018, the contents have diverged quite a bit since then. Many sections in Common were changed and it is hard to say, if some of this introduces issues. I have identified some points, but there may be more.
In addition, Features Part 1 has been updated with a significant number of clarifications and fixes since the fork. I think it would be a large effort to synchronize the two documents - for no practical gain, as far as I can see. I see more value in splitting the requirements classes in Features Part 1 1.1 along the lines of Common to simplify reuse by other OGC API standards. It would be better, if Common would simply duplicate requirements classes from approved OGC API standards without changing them - as it was the original idea.
Here are some differences / compatibility issues spotted are:
- Features uses the link relation type "conformance" (for historical reasons), Common uses "http://www.opengis.net/def/rel/ogc/1.0/conformance". Implementations of Features Part 1 1.0 will not conform to Common Part 1 1.0 (unless they provide links with both link relation types).
- Common Part 1 has a normative statement (a recommendation) outside of any requirements class (in 6.3); in Features this recommendation is in the Core requirements class. This is more a ModSpec issue.
- Features is more strict than Common with respect to unspecified query parameters and query parameter values. While Features could prohibit the recommendations in Common (which are mostly not recommendations, but permissions), this makes the provisions unnecessarily complex.
- Common has normative statements that are superfluous as they are specified elsewhere (HTTP, OpenAPI), maybe also in incompatible ways. This applies to everything in section 8.8.
- Common has recommendations that are outside of the scope of Common. E.g., it is an OGC API convention to use kebab case for query parameter names. This should not be a recommendation to API authors, they will have their own style conventions for their own query parameters.
- Common normatively references the HTML5 W3C Rec for HTML, not the HTML standard from the WHATWG.
- Common introduces an additional link relation type (http://www.opengis.net/def/rel/ogc/1.0/data-meta), which is outside of the scope of Common Part 1 and also plays no role in the document.
I hope this helps and explains why I (@cportele ) do not see that Features Part 1 could or should normatively reference Common Part 1. APIs that support both Features Part 1 and Common Part 1 can express that in the Conformance Declaration (ldproxy, for example, does this).