The OGC API process is fast or slow?

[joanma747]

Actually, I'm not sure that accelerating the process of creating standards is a good idea.
In OGC API Common we believe that going too fast in OGC API Features ignoring the possibility to create a common backend where all the other APIS could grow, is creating all sorts of small problems that could be solved by a slowing down for a moment and thing about the big picture.

[fmigneault]

Yet, at the same time, there are things that have been submitted a long time ago for consideration, and are still not integrated by the unifying OGC API Common, slowing down the development of all standards depending on it, and causing a lot of redundant discussions across SWGs.

For example, the x-ogc-* properties (some of those are >1 year old!):

• Schema conformance class for part 2? ogcapi-common#334
• Part 5: Add table of x-ogc- properties ogcapi-features#945
• Part 5: OGC API - Common - Part 2 "Schemas" req.class Syncing ogcapi-features#954
• Fields for schema ogcapi-coverages#173
• Type indications for user interfaces in parameter schemas ogcapi-processes#395
• etc.

I find that, by acting quickly and not waiting too much after Common to "officially" publish definitions, OGC API Features was able to actually propose many parameters that created a common ground for discussion and consideration by other standards. Although definitions do not align "perfectly", they have somewhat of a similar naming, representation and intention, which greatly limits discrepancies between SWG due to many people not talking to each other and coming up with their own custom properties each time.