OGC Policy and Procedure Issues

Voting Rules

The current voting rules for the adoption of new standards have been criticized as confusing or overly complex.

The current rules for electronic votes could be changed to ensure that a vote reaches a quick conclusion. This proposal would remove the impact of 'no' votes which would no longer stall a vote and would not trigger a comment/response period.

• PRO - this would match the generally shared notion of a vote being a sampling of the positions of the voters
• PRO - this would ensure voting lasts for a fixed duration, simplifying planning
• CON - this would be a huge shift away from the current process which is essentially a consensus based process towards a narrow majority vote, possibly of one vote, a shift which has many consequences.

(note by PeterBaumann: I have set all my comments in italics to make it stand out from staff's initial text.)

well, effectively adoption voting is only the last step, and manifold decisions de facto are being made within a SWG etc where there is a regime of "one member - one vote". So I am not overly concerned, although on top-level voting political aspects tend to have more impact (others may complain that this is not duly taken into account by the SWGs ). So, being only allowed to work, but not to vote (for adoption) I surely would be more happy with having a say in the final voting as well, but it is by far not my toughest concern. (Background: I'm university and can only afford this membership level.)

-- PeterBaumann - 30 Jun 2013

The Specification Model

Current TC rules require that all new specifcations comply with the rules of The Specification Model --- A standard for modular specifications, commonly called the "Mod.Spec.". This rule has been criticized as inhibiting the ability to write new standards, as leading to more complex (or longer standards), and as being hard to understand. Conversely, this rule was adopted to, and has been praised for, making clearer standards that lead to better implementations.

A suggestion has been made to drop the rule.

• PRO - this would remove a rule from the standards writing process.
• PRO - this would acknowledge that the current document cannot be used as written and that therefore the current rules must necessarily be broken for new specifications to be adopted as OGC Standards.
• CON - standards would no longer benefit from being forced to isolate their injunctive language, from making injunctions which clearly target a specific target entity, from only making injuctions which are testable.

An alternative suggestion has been made to keep the rule but fix the document. This has included an extensive analysis of the document as a RFC comment, subsequently complemented by a proposed revision which fully rewrote the document.

• PRO - this would solve both the issue of
• CON - specifications would still be forced to do the hard work required to ensure all their injunctions are clear and testable.
• CON - no action has been taken by the OAB on the RFC or the proposed revision and it will take time first to adopt the revision and second to update the TC rules.

Let me open my mouth, as we (WCS.SWG) were the first ones (and maybe still the only ones) doing a full suite of 17 specs along the mod spec model. It was a hell of a lot of work, but mainly due to the fact that we were the enrepreneurs. Meantime we have a slate of best practices which work out quite well, and these specs are generally appreciated by users (=implementers) as being much more comprehensible and transparent than the previous monolithic version. So I'm all for it.

However, a major issue is that the mod spec model has some conceptual shortcomings - not so much because it would be flawed (I do like the approach in general), but because some core issues just have not been addressed in the mod spec itself. Needs to be corrected, urgently.

Which raises the same issue as with OWS Common: How can OGC let float something that is at the heart of its mission? Bot mod spec and OWS Common WGs have been dissolved following delivery of something that does not have been tested thoroughly; has no reference implementation; has nobody to take care of in a managed process. Breathtaking...

-- PeterBaumann - 30 Jun 2013

Remember what problems the Modular Specification was crafted to fix: - making specifications testable - managing dependencies (at the appropriate level of granularity) while also taking care of 'versions' - allowing implementation of parts of standard - providing clear extensibility mechanisms These issues interact strongly with each other.

The OGC modular specification policy appeared to provide a mechanism to deal with all these issues in a rather elegant way. While it has clearly been hard to swallow for some communities and editors, if the policy is changed, then it is important that all these concerns are still addressed.

-- SimonCox - 25 Jul 2013

Open Process

The OGC has been widely criticised for being too closed. This includes Standards Working Groups with closed meetings, closed mailing lists, and closed wiki spaces that block collaboration even with other groups at the OGC.

One suggestion has been to evaluate the closed design of TC working groups.

• PRO - would clarify if there were any benefit to the current system, and if not, would allow for a new system in which everyone at the OGC could talk openly to everyone else and outside contributions could be used.
• CON - staff time would be used to revisit the complex and ultimately unintersting IPR (Intellectual Property Rights or Imaginary Property Restrictions) issues.
• CON - the value of membership at the OGC might be diluted, which might reduce the revenue the OGC received from memberships.

An issue is: Can we manage IPR concerns adequately to protect standards from infringement? This needs clarification since 'protecting standards from infringement' makes no sense, they are designed to be implemented, and no published OGC standards contain any patent claims so 'protecting those patent claims from infringement' has not yet been an issue.

One suggestion has been to ensure the public comment process includes the public publication of comments and of the responses. This seems to be acceptable to everyone and is in the process of being adopted into the OGC TC Policies and Procedures.

I see and understand the IPR issue. OTOH, this effectively prevents liaising with community, shuts out valuable resources, and may lead to distrust even. So a suitable balance should be found. NB: I am anyway publishing the concepts of specs in scientific conferences before adoption, so there is "prior art" prohibiting quickly filed patents. So, I'm all for open discussion (and have started that already 2 months ago for coverages), of course without delaying the decision process. So nothing like "whenever I will find to read the spec I will surely come up with comments, so stay tuned".

-- PeterBaumann - 30 Jun 2013

HM, I'm not a lawyer, but: doesn't an early publishing constitute "prior art" effectively hindering patents? In patent sues OGC certainly could be heard (with internal support by spec editors) to demonstrate this. [p/] The value proposition issue is a tough one indeed: why should a company pay (and in cases pay a lot). I like the branding scheme with paid conformance certificates - makes sense. Maybe prices could get increased.

-- PeterBaumann - 30 Jun 2013

Specification Format

The current documentation production system, in which documents are edited in Microsoft Word and then published in Portable Document Format (PDF), has been criticised for the focus on one editing tool not a format and for the use of a paper format in this digital age.

A suggestion has been made to publish OGC Standards as HTML documents rather than PDF.

• PRO - The result would be searchable on the web and web accesible.
• CON - The OGC would have to develop complex tooling to make the management of different versions and edits possible, would have to standardize on some particular form of HTML, and would have to modify all its current publication system.

Indeed, MS Word is a nightmare. Unfortunately, with a tool as bad as MS Word and the manifold tweaks people (including myself) have found it is hard to auto-translate into HTML. Some people may think of reStructuresText (reST, not REST) - a tentatively "primitive" format which may make specs more uniform and can be translated into other formats. BTW, IETF publishes its RFCs in flat ASCII...

-- PeterBaumann - 30 Jun 2013

Specification Complexity

OGC Standards are often very complex documents making the standards hard to read and implement.

A suggestion has been made to move to a much simpler form, without the introductory clauses, to make OGC Standards documents easier to read and implement

• PRO - It is suggested that removal of preface, introduction and other 'context' sections would simplify the reading of documents.
• CON - There is no reason to think that OGC standards are any less complex than standards of the IETF, of the W3C, or other standards making bodies, all of whose standards documents are similar in size and difficulty to those of the OGC.

A suggestion has been made to create additional documents that explain the role of the standard in a larger context

• PRO - This might help readers understand the intent of the specifications.
• CON - This would require even more work and documentation for the specifcation process, beyond the document and the press release.
• CON - This is already done as part of the introductory material within the specification.
• CON - More documents potentially cause more confusion and require more maintanence.

I think standards are not easy to understand and implement specially in countries where there are no to much experience in such matters like in South America. It is not easy to understand to the general public the value of those electronic standards too. One idea I think can help the standard adoption is: the standards can have three levels of application, I think any standard must have a simple version for general public use (easy standard form), a second level for commerce and industry (complex but functional) and a third just oriented to science and research (complete).

-- GabrielAsato - 25 Jul 2013

Specification Type

OGC Standards are all required to follow the same requirements but some standards are created from scratch within the OGC and others are adopted from an existing specifciation developed elsewhere.

A suggestion has been made to create a new document type that would have different procedures to faciliate the adoption of externally developed standards as OGC standards.

• PRO - External standards would be more easily adopted.
• CON - OGC standards would be less homogenous and therefore harder to read.
• CON - This would open the door to the adoption of many external standards which differ greatly in quality, in harmonization with existing OGC standards, and in support by the OGC community.

help, not yet another doc type!

-- PeterBaumann - 30 Jun 2013

Specification Name

The names of OGC Standards have not been restricted so far. As more standards arrive, with possibly duplicate roles, the name of the standard should clearly distinguish new standards from existing standards. The name should also provide a strong hint as to the interoperability problem being addressed by the standard.

A suggestion has been made that the naming of new standards should be controlled. The question of how and by whom has not been tackled.

This sounds like overengineering. To me it would be sufficient if an improved OAB (see my comment on this) would perform a reality check on the name during its adoption assessment.

-- PeterBaumann - 30 Jun 2013