A short paper,Engaging Developers in Standards Development; the Cetis Code Bash Approach by Lorna Campbell and Adam Copper is now available from the Cetis Publications site.
The paper discusses how Cetis Codebash events help to achieve practical interoperability by testing new specifications and standards. Drawing on years of experience includes a checklist for running a successful Code bash, including who to invite and the ground rules to establish.
Abstract
A linear process in which a written standard is created and then implemented in software is liable to fail for many reasons arising both from the difficulty in writing a specification that is sufficiently precise and accurate while also allowing for necessary flexibility in use, and from the intrinsic complexity of the human activities and IT systems in which it will be realised. Engaging software developers in the standards development process has been found to be an effective means to improve the written standards, to enlarge the scope of practical interoperability between software, and to identify and share effective practice. Over a period of years, Cetis developed an approach to this kind of engagement which we called a “Code Bash”. This white paper outlines the motivation, typical outcomes and practicalities of running a Code Bash and is intended to motivate people working in either formal or informal standards-development settings to engage developers in the process and to provide them with some ideas to adapt to their own setting.
http://publications.cetis.ac.uk/2013/871
I think that this paper is sound, insightful, and covers many of the benefits that developers can bring to the standards process.
In addition, I would suggest that developers may contribute in the areas of reuse, security, practice, extensibility and constraints. I’ll try to illustrate this with an example.
In the development of an XML-based standard with narrative elements, there will be discussion about how to specify the rich text markup for descriptive components. It is possible to reuse existing HTML standards, although in practice, you would generally wish to constrain these to a subset of elements that will not compromise security. On the other hand, where your standard provides simple text string element types, you may want to build in future extensibility so that a richer markup could be used in future (perhaps by substitution).
Supposing that organizations may wish to have different “house styles” for standards, they may wish to prohibit certain optional elements or mandate others. They may wish to restrict descriptive markup to a minimum. Developers should be able to anticipate these requirements, and come up with mechanisms that will set rules for a valid subset of the standard, which should have this flexibility built in. For example, a main XML schema that imports a subset of HTML rather than the entire HTML spec (which would also allow future versions of HTML) could be used to validate a restricted “house style”.
Developers should be well aware of the modular possibilities of standards.