Innovation Harmonization and Standards Life-cycle management

• How does OGC allow for innovation to happen to support technology and market shifts while maintaining existing standards? We have a mature standards baseline that has been braodly implemented, is mandated in numerous policy statements, and (flaws and all) provides a much higher level of interoperability than prior to the work of the OGC. However, there are numerous market forces (business, technical, human, and cultural) that are 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.
• Is there member consensus that harmonization and innovation are accepted principles / goals of the consortium? And the related question:
• How will OGC address externally submitted spatial / location standards that are widely (globally) used and overlap or conflict with the existing OGC baseline?
  • Who maintains the externally developed specifications that then become OGC standards?
  • What are the IPR implications?
• 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? Think about an agile process - learn from the OGC testbed process.

Relations to other topics

Related to TopicStandardsDiversity, since Diversity is what breeds the need for Harmonization.

Related to TopicExternalSubmissions, since the integration of external standards might require allowing diverse approaches.

See TopicStandardsDiversity, discussion merged

-- TrevorTaylor - 27 Aug 2013

Discussion

Comment:

Cameron Shorter: Answers to this question should be translated into business problems in order to answer.

What do OGC sponsors wish to achieve from standards? Do sponsors wish to encourage mass market uptake? Will mass market uptake attract more OGC sponsors and funding to sustain OGC activities? What will attract mass market uptake? Such things as clear documentation, 1 page overviews, etc will increase uptake. Will increased standards uptake from clear documentation justify investment?

Similar business analysis should be applied to question of potentially overlapping standards, or whether to invest in testing frameworks and quality control.

Leadership and recommendations from OGC to members would be of benefit here, and it would be appropriate to draw upon research from specific OGC members.

-- CameronShorter - 02 Jul 2013n

Response:

Ideas Leadership Group Note: Some of this comment will be addressed in the Topic Mass Market. The portion regarding the overlapping standards is dealt with in the Topics Diversity. The leadership group has addressed this by making recommendations that any new standards go through an early evaluation process where these questions are to be addressed.

---

Comment:

On Behalf of PaulaMcLeod

There is a need for a simplistic demonstration of the contribution of specs. Sometimes OGC and their members take that for granted but people are questioning the contribution of some specific specs. Only few specs are widely used apparently, and some others are almost not used. For those that are not used why maintaining them. For what purpose they were developed. Before initiating a new spec, it should be clear for hole it addresses and the importance to develop it. Statistics about the use/implementation of current OGC specs would give an idea about the usefulness and success of the various OGC specs.

-- TrevorTaylor - 15 Aug 2013

Response:

Ideas Leadership Group Note: The submitter of this comment participated with the leadership group and agreed to recommendations in the Topic Diversity that suggested OGC perform regular evaluations of existing standards to determine their effectiveness, use, and uptake. Based on this evaluation, OGC should determine whether existing standards are still relevant or should be retired. TopicSelfAssessment will develop recommendations on specific metrics to address OGC standards, process performance.

---

Comment:

On behalf of Paula McLeod:

Strengthen liaison with ISO to ensure harmonization.

-- TrevorTaylor - 15 Aug 2013

Response:

Ideas Leadership Group Note: The submitter of this comment paticipated in the leadership group recommendation formation process and assisted in making the recommendation for OGC to encourage external harmonization with groups such as ISO.

---

Comment:

On behalf of Paula McLeod:

With respect to implementation issues, and how WMS communicates with data catalogue services, there are poor linkages between data catalogue service vs. how services catalogue data. Need to catalogue things 2 times in different parallel paths leading to duplication. Needs Harmonisation.

-- TrevorTaylor - 15 Aug 2013

Response:

Ideas Leadership Group Note: Although the submitter participated with this leadership group, we did not address this in detail as it should be addressed within a WMS or Catalog SWGs. Recommend a CR be created to document the issue for SWG attention.

---

Comment:

On behalf of Jeff DLB

Suggested Process:

* Draft announcement/press release about new work, to get agreement on high-level details. Don't issue the announcement yet, just agree on the vision. * CHECKPOINT 1: TC vote on whether to form SWG.

* Draft informational documentation for users and implementers. * Prototype software that implements all, and only, what is covered in the documentation. + Keep log of agreements/decisions that will form basis of standard. * Prototype conformance test tools for all functionality. + Keep log of agreements/decisions that will form basis of standard. * Iterate as needed. * Include 6-12 month period of testing, evaluation, and refinement. * CHECKPOINT 2: TC vote on whether to proceed to writing formal Standard.

* Draft Standard based on agreements/decisions. + All functionality must by covered by documentation, reference implementations, and conformance tests -- no more optional pieces for rare Use Cases that nobody implements. * Iterate as needed. * Circulate full package for public comment: draft announcement, documentation, software, specification. * Revise as needed. * CHECKPOINT 3: TC vote to adopt standard.

* PC vote to approve * Issue press release.

Regards, Jeff DLB, NOAA OGC TC/PC representative

-- TrevorTaylor - 27 Aug 2013

Response:

Ideas Leadership Group Note: This suggestion logged on the TC-Discuss list has been strongly supported by membership dialog on the TC-Discuss email list. We are recommending that this issue be further discussed and recommendations formed within TopicSWGCreation and TopicSWGProcedure which are meeting in October November of this year.