As part of the "Ideas for OGC" effort, I recommend we consider a new approach toward developing standards. The current focus is too much on writing the actual specification documents, which are often laborious to produce, challenging to fully comprehend prior to voting, difficult to understand and implement from scratch, and not always conducive to seamless interoperability.

We should instead focus first on easy-to-understand documentation and on software that implements and tests the standards, and only later on the precisely-worded normative technical specification for the record.

I know that we already develop some software or documentation within SWGs or testbeds. My suggestion is to make such artifacts a mandatory part of the process.

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