Dear idea gatherer,

here are a set of ideas that might help improve the working, impact, and standards of OGC. Caveat: I may lack knowledge of some OGC documents/policies which
could contain/contradict ideas below...

1) Distinction 'cross-domain' and 'domain specific' standards

OGC has standards that are specific to a domain (e.g. WaterML) and standards that are cross-domain (e.g. WMS). For domain specific standards,
it seems ok to have a small focused group of people in the SWG to define and finalize the standard. For cross-domain standards, the reviews
and input should come from a much wider audience.

My proposal:
- OGC labels standards as domain-specific or cross-domain (existing and new)
- SWG charters include this labeling upfront. Naming of standards should reflect their labeling type.
- SWG charters for cross-domain standards require a TC e-vote for acceptance of the charter. This ensures/enforces that a majority of TC voters backs the creation of the new standard before the SWG starts with the bulk of the work. The charter should be well written, with a clear purpose and summary and the main working principles (e.g. maintaining strict compatibility with an existing (non-OGC) specification should be part of the charter).
- SWG charters for domain specific standards could be set up as they are now

Other aspects might be stricter for cross-domain standards as well, e.g. the presence of cross-domain implementations, presence of compliance tests, ...

2) Vision and guidance on which standards to use for which purpose should be given by OGC

Government and other users of standards in their systems look to OGC for guidance on what to put in their call for proposals. OGC should give authoritative guidance on this.
E.g. if you want a map being served you should use WMS. If the data is largely static, you are recommended to use WMTS for performance reasons.

Suggestions:
- OGC should, using input from its members, define a clear vision on cross-domain standards. OGC staff should identify the need and requirements for general, cross-domain standards and actively help push them through the process.
- Cross-domain standards should avoid overlap between themselves. OGC must provide clear positioning among general standards. New standards must position themselves wrt. other general standards.
- Standards life-cycles should be better defined. E.g. OGC recommends to retire use of WCS 1.0 by 2016. Obviously this should be with members consent.

OGC standards are successful because they provide interoperability, for which there is a great need in the geospatial world. OGC standards could be even more successful if they were perceived as less complex and easier
to implement in an efficient way. By focusing on key general standards, I think the OGC can take steps towards that goal as well. Then standards would not only be chosen because of interoperability, but also because it is
just the best way provide such geo-functionality. Simpler, overlapping standards that hinder interoperability are in my view not the way forward though.

3) Involve experts by flexible funding of small tasks/reviews.

Often, requests are made on the forums (SWG, DWG) to ask for help on items or to review certain documents. Although often interesting, it is difficult to schedule any effort for this without any funding, if not directly beneficial for the company itself. Probably less of an issue for universities and big companies, but it can make a difference for the involvement of smaller companies.

SESAR JU, the organization arranging research for the Single European Sky initiative, works with a set of registered experts that may be asked to review documents in their domain for a daily fee. This may be useful to ensure
input from experts that may find it difficult to get free time from their company to do such reviews.

4) Help in templates and editing to obtain well readable, consistent standards texts

We notice that a lot of time is spent on formatting and editing of the standards' text. This time is spent by members that are typically the technical experts rather than technical writers or Microsoft word guru's.

Some ideas around this:
- Use DocBook or LaTeX or similar to allow SWGs to focus on content rather than form. This would allow easier web publishing.
- Provide a good template for this. Make sure that all elements (e.g. requirements, term definitions, XML snippets) have a defined style in the template.
- Rewrite an existing standard using the template to show the best practices. Spend enough time to get this right and all new standards will benefit by the example. Some of my people gave IETF RFCs as a good example
of consistent specifications that are quite well readable.
- Change or drop the ModSpec requirements. It takes time from the writers, while the readability of the standard does not seem to improve proportionally.
- OGC should provide professional editing services to improve the texts
- Every standard should have a smashing one pager that provides the essence of the standard. Also here, I'd expect very active participation from OGC staff. This effort can start off the SWG charter.


5) Fewer TC meetings

4 TC meetings per year seems a lot to me, even if one is virtual. I can typically attend one, but for this one the travel is not a big issue.
With 4 meetings, it is harder to meet people across the globe, since most will go to the TC closest to them.

6) Website suggestions

Main standards:
It is hard to find what the most relevant standards are. The list of standards does not discriminate between main standards and extensions/versions, nor does it indicate
which are the most used standards. There are only a dozen or so main standards. The list might be organized as such.

The reference model document includes an overview. This should be more prominent in a web page form. The name did not lead me to think it includes an overview.
Each main standard should have a landing page with an overview and referring to different versions and extensions. The domain pages, accessible from the home page,
should link to the landing pages in their overview of relevant standards.

Statistics about which standards are implemented the most would be useful.

Cookbooks are only found on the 'Implementations' page. They should be on the landing page of the related standard.

Other remarks
- Available implementations should not be referred to as 'reference implementations'. This is confusing. They are compliant implementations available for testing.

-- TrevorTaylor - 15 Jul 2013