DocTeam SC Report to TC 94th OGC Technical Committee Barcelona Spain Carl Reed, PhD 12 March 2015 Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Agenda Proposed multi-track standards process Deprecacting OGC standards What is the normative document for an OGC standard: The HTML, the PDF, or both. Copyright © 2015 Open Geospatial Consortium

The Proposed Multi-Standards Track Multiple points for entry Community Specification Provisional Standard Full Standard Requires written justification for review by TC Requires TC approval to progress as CS. Provisional and Full Standards Same process as now! Just different names based on maturity Copyright © 2015 Open Geospatial Consortium

Standards Track: Community Specification Internally or externally developed Requirements do not need to be “formally” stated as in the case of using the OGC Modular Specification Use of OGC document template not mandatory but recommended CITE tests not required Must be widely implemented. There must be evidence!! Promote innovation, engagement, community dialogue without the overhead Possible first step in the OGC standards track Copyright © 2015 Open Geospatial Consortium

Standards Track: Provisional Standard Uses OGC document template Requirements formally stated as per the Modular Spec CITE tests not required May or may not have implementations Good starting point for new standards IPR transferred to the OGC Focus – Promote implementations if there are none (or few), gain community input and engagement, promote collaboration Copyright © 2015 Open Geospatial Consortium

Standards Track: Full OGC Standard Requirements clearly stated. Modular Spec followed. OGC document template used. Strong evidence of implementation CITE Tests Reference implementation(s) Focus – Rigorous, mature standard with all elements completed Copyright © 2015 Open Geospatial Consortium

Standards Track: characteristics SWG Evidence Implem Modular Spec CITE Test OGC Template Public Comment OAB Review IPR to OGC Member Vote Community Specification NR* Strong! Partial Yes Yes (Note) Provisional No Full standard NR – Not required. NOTE: IPT may be shared. Evaluated on a case by case basis Copyright © 2015 Open Geospatial Consortium

Discussion and Recommendations Be clear that all three are official OGC Standards Change name of Community Specification Recommendation that all new standards not submitted as Community Specs start as Provisional standards Hence, two tracks and not three Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Issues Need guidance on what OGC means by “Evidence of Implementation” Need agreed to approach of how to deal with existing OGC standards Recommendation is that all existing standards be initially labeled as Provisional and then evaluate each version of each standard in terms of whether there are CITE tests, whether the standard is broadly implemented, etc. Need easy to understand flow charts of process and relation to other OGC documents Copyright © 2015 Open Geospatial Consortium

Thanks to Clemens Portele for raising the topic and providing input Copyright © 2015 Open Geospatial Consortium

Deprecation of an OGC Standard - Current The TC Policies defines a "Deprecated Document" as: "An official standard of the OGC but no longer maintained. An OGC document shall be deprecated by a vote of the OGC Voting Members, usually as part of a standards adoption vote.“ Not happening and ad-hoc And many older versions of existing standards are still widely used Conflicts with PnP related to Retired OGC standard Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium The Solution When a new version is released, previous versions are NOT automatically deprecated and they are maintained in the sense that at least bug fixes are published Therefore, deprecation of OGC standards should be by an explicit TC vote. Reasons There is evidence that the standard is not be used any longer make it clear to everyone that a certain version should no longer be used, e.g. because of no good evidence of continued support in current software. Taking GML as an example, for me the following versions should not be considered deprecated: 3.3(.0)/3.2(.1), 3.1(.1), and 2.1(.2). All other version should be deprecated. Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Actions Develop PnP language, share with TC/PC and have vote to approve in Boulder Review current standards list and begin to define a set of motions to deprecate specific older versions of standards such as Deprecate GML version 1.0. Will require research and coordination with Editors, SWGs, OSGeo, and broader community. Copyright © 2015 Open Geospatial Consortium

What is the normative OGC standards document? Copyright © 2015 Open Geospatial Consortium

Copyright © 2015 Open Geospatial Consortium Issue If there are inconsistencies between the HTML, PDF, and Word versions as posted, which should be considered the normative document? Inconsistencies between the HTML and the PDF for GeoPackage brought issue to OGC attention. Related question: If these inconsistencies are identified, can OGC staff make corrections once Editor/SWG approve? Years ago, decision on which version of a schema for a standard is normative. Schemas in OGC Schema repository are normative. This decision is captured in the Policy Directives document. Copyright © 2015 Open Geospatial Consortium

Example from IETF HTML version of an RFC Canonical URL:http://www.rfc-editor.org/rfc/rfc7459.txt This document is also available in this non-normative format: PDF. No Consensus in the DocTeam discussion Is such a statement necessry? Should all posted documents be normative? Go back to just PDF Develop our standards in HTML. HTML should be normative. Copyright © 2015 Open Geospatial Consortium