You are here: OGC Public Wiki>Ideas4OGC Web>TopicsTable>TopicSpecInnovation (revision 1)EditAttach

Topic: Specification Innovation

The OGC specifications must obviously evolve to support emergent technologies and shifts in markets. The issue of how this shifts can be promoted and how that promotion takes into account existing standards must be resolved. The OGC has a set of mature standards that have been braodly implemented, have been mandated in numerous legal contexts, and which provide, despite their flaws, a much higher level of interoperability than prior to the work of the OGC. However, there may be numerous market forces (business, technical, human, and cultural) that may be driving requirements for lighter, more agile standards that may conflict with the existing OGC baseline. The OGC members have always been highly innocative and creative. How does the OGC accommodate the installed base using the current OGC/ISO baseline with the requirements of the mobile internet, Internet of Things, AR, and so forth?

There are related questions and issues related to the OGC having standards that have some level of overlapping capability:
  • Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
  • If there is overlapping functionality on one or more OGC standards, we need to consider the cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
  • Can the OGC membership reach any consensus that harmonization and innovation are accepted principles / goals of the consortium?
  • How will OGC address externally submitted spatial / location standards that are widely (globally) used and overlap or conflict with the existing OGC baseline?
  • Who would maintain the externally developed specifications that then become OGC standards, and what are the IPR implications of such a setup?
  • How might the OGC development process be modified to encourage documentation as the last phase of the process, with heavy emphasis on experimentation, testing, validation up front?

These questions relate to an agile process and to the experience gained from the OGC testbed process.

How should the OGC adapt to the rise of mobile devices which has greatly changed the landscape for mass market spatial data infrastuctures?

Relations to other topics

Related to TopicTackleMobile, since mobile is a sub-topic of innovation in general.

Related to TopicIntegratePrograms, since one way to innovate in the OGC Specification Program might be through better integration with the OGC Interoperability Program.

Related to TopicExternalSubmissions, since the integration of external standards might allow innovation.

Possible Actions


I do not see that agility and innovation (both being immensely necessary in this fast-paced domain) necessarily contradict interoperabilty and harmonization. I do see, however, that there is a genuine role for OGC (staff) to ensure this. OAB actually is meant for this, but could improve on fulfilling this role. To put it short, OAB should facilitate, upon spec submission by SWG (at the latest) an open, synchronized assessment process. This is done in a relatively lax way today, and with sometimes extremely time-consiming back-and forth discussion over months and (yes!) sometimes even years. My record is 2 years. Already in 2011 I have proposed that upon spec submission there is a f2f or at least telecon meeting where all stakeholders are engaged: spec writers; OAB; OGC-NA; editors of possibly overlapping specs; OGC staff facilitating; other potentially interested stakeholders (so a public announcement should be made for this session). Unfortunately, this has never happened, although OGC staff confirmed the potential of benefits for timeliness and quality of spec adoption.

-- PeterBaumann - 30 Jun 2013
OGC should seriously evaluate Hypertext As The Engine Of Application State as a guiding principle for OGC standards. This is the core of the foundation of the Web. REST is predicated on agreement over format. The interface is fixed: URI over HTTP. The format is up to you, so long as you don't start messing around with URI parameters, hierarchies, structure etc. You have to think about what the client must understand to interact with your service. If it has to understand how / what to compose in a URI, your service is not communicating state changes via hypertext. You were not that far off with GML, a few adjustments in thinking are needed is all.   The Web is based on web-iness, and that architecture should be reflected in at least some OGC specifications.

-- PeterRushforth - 08 Jul 2013



The Leadership group has not yet discussed this topic.
Edit | Attach | Print version | History: r3 < r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r1 - 26 Jul 2013, AdrianCuster

This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback