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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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

13. 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

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

15. 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

16. Example from IETF HTML version of an RFC
Canonical URL: 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