You too can write your own ISO standard! Here are the steps:
1) Download the ISO/IEC Directives Part 2 Rules for the structure and drafting of International Standards. These give the general editorial guidelines. Read it all.
2) Download the documentation for the XML schema for ISO Standards, which is in Technical Report 9357-11. A good draft is available from SC34 Website. Read it all.
3) Download the Open Source schemas and stylesheets are available at SourceForge and embody a lot of the rules of the ISO/IEC Directives Part 2. They have been contributed to over the years by such people as Murata Makoto, Martin Byran, Ken Holman and James Clark and used in many standard: I used them for ISO Schematron for example. (If you want to use Word templates or whatever, these are available from ISO, but this is an XML list so it doesn’t deal with that.) Install and configure your production environment to use them.
4) Try to follow these writing guidelines:
- When writing, think about clarity. A good rule of thumb is “Will this sentence be easily translatable into a language that does not have the words “the”, “a” and “it” or which does not have the future or past tense available?” and “Can a recent graduate understand this?” Note in particular that you must use “shall”, “should”, “must” in very particular ways, that you need to use the definitions section as much as possible, that you need to clearly distinguish normative text from informative text (which is not the same as required and optional/discretionary, and different again from the legal “Required Parts”), you need to be clear about different levels of conformance, and that you need to be careful with normative and non-normative references (see the Directives!)
- Download any other standards in a similar domain, and try to re-use the phrasing and declarations from them. When writing, try to use the standard vocabulary that ISO suggests in standards such as IS 2382. If you use terminology that differs from these, make sure it is in your definitions section. Note that there are some trick words that have specialized meanings: so “define” is what you do, but “declare” is how you do it (loosely).
- A standard should only contain verifiable statements. That rules out most adjectives, unless they are defined, and is why standards tend to have Germanic agglomerations of nouns. Where possible, try to specify the requirement in an executable form, such as a schema language, then use the text to fill in the gaps. Where possible, try to specify the requirement using a formalism, such as predicate logic or BNF or UML, especially if there is an unambiguous notation or a standard for these. Where possible use diagrams, however only use them if there is a common or standard diagraming type for which a reference is available.
- When writing, avoid dependencies on other standards. Reference the most general version of other standards possible. Unless there is a good reason, allow the other standards to be maintained without this then making your standard outdated. Avoid specifying or summarizing other standards: completely in normative text, and as little as possible in informative text unless the other standard is not freely available.
5) Write your draft
6) Track down IP issues to the best of your ability. Also, try to have reviewed it for Internationalization, Security and Accessibility issues: the more that these are designed in from the beginning, the smoother things will be downstream. Most importantly, you need to show that there is some market (users) for this standard, that it is not some crackpot technology. One important thing that will influence reviewers is whether there is developer buy-in: is there an open-source implementation, is there some company willing to produce products that use the specification, and so on. If you want commercial buy-in, think about the carrots (an economic case why it would benefit vendors) and sticks (getting regulators or procurement departments to require it.)
7) Decide whether it should be an ISO/IEC International Standard, an ISO/IEC Internation Standard through fast-track, a Publicly Available Specification, an ISO/IEC Technical Report, a National Standard, a Consortium Standard, or just something on your own website. If you decide to take it through ISO you have to find or become a champion: you can go to your local national standards body and get them to propose it (or adopt it as a national standard first), you can find a friendly committee person on the relevant committee and get them to propose it from their Working Group, or you can find some boutique standards body that has liason with ISO (such as OASIS or W3C) and put it through their processes. You need to find an editor who is participating on the committees and can travel to enough meetings (See if your national body offers any travel subsidies; demand that the ISO working group use teleconferecing). You should expect that your draft may be substantially changed, especially if you have not written it according to stage 4). At this stage, remember that you are not alone: there will be other committee people and interested people around the world who can provide advice, only rarely crazy, and you cannot be too proprietorial: some parts of the standard will improve in your eyes, some parts will get worse in your eyes, but that it all OK because it becomes a collective effort. Especially remember that a really stupid comment from someone is undoubtedly a sign that your deathless prose is crap and needs to be fixed. Don’t take criticisms of the draft personally, and learn committee skills: how to challenge clearly, take the stated requirements of others seriously, and acquiesce gracefully—not understanding something or losing an argument does not involve a loss of face, but you have to give face when winning on an issue too. Don’t “play to win”; instead “play to win/win” (I am embarrased to write that!)
8) When a draft is produced, contact the various technical committees around the world to help answer questions. Actually, the ISO committee process itself provides a good forum for this; if you are fast-tracking you may need to do extra work to explain the draft.
9) Ask the committee to ask ISO to get the standard added to ISO’s free list. A standard that is not on the WWW is at a total disadvantage.
10) Assuming the vote on the Final Draft was “yes”, you now have your standard! Congratulations, that has only taken three years or so. Now you have to commit a little time over the next few years to maintain it and fix corrections that come up, and to try to get buy-in from the public. If you have a “grass-roots” standard like ISO DSDL (RELAX NG, Schematron etc) which do not fit into the plans of the military-industrial complex, then your expectations need to be modest and you need to think about how to encourage activity in the Open Source eco-system. Remember a good standard is one that meets its particular user’s needs, not one that takes over the world.
However, your name won’t be in the standard (unlike W3C or OASIS), or in the bibliographic entries. So don’t do it, or participate on committees, if you want to see your name on Amazon.