- Finding the right standard for a problem often requires an understanding of what a standard does and how it works. It's a circular problem like trying to find the right spelling for something: How can you look something up in the dictionary if you don't know how to spell it?
- Standards are the end product of a design process. If you haven't been through the design process yourself, understanding why the standard is designed a particular way can be difficult.
- [Good] Standards don't usually tell you how to design an application, rather they tell you what your application needs to do.
Finding the right standard can be difficult. The best way I know to do it is to ask an expert (or better yet, several experts). Fortunately, I happen to know a lot of experts, but that isn't true for others. There are a couple of places where you can find experts on standards. One of these are the IHE implementor Google groups.
For this, Google is your friend, or Bing, or Ask or any other search engine.
The key thing you need to be able to do is find the right set of keywords for your search. A few good ways to find keywords are to use a thesaurus or to find terms from other documents you find in your search. You need to be willing to spend some time searching, at least an hour or two before you give up. The less you know, the more time you need to be willing to spend searching.
Understanding the Standard
Having found a standard (or being appropriately directed to it), the next problem that you may encounter is in understanding it. Reading the content of a standard is different from reading just about anything else you will find. It's often the hardest reading that an engineer will have to do, especially if you've never dealt with the publisher of the specification before. That's because you have to be able to enter the mind set of the standard developer after the fact, rather than participate in the same journey that he or she did in writing the standard. Getting there is more than half the battle, but the standard doesn't describe the path that its developers took to reach the conclusions they did.
There are a few techniques that can be helpful here.
The first it to inform yourself about the particular development process used, and the structure of standards produced by a given SDO. Anyone who is familiar with Internet RFCs or W3C standards should be able to report familiar patterns in these standards. Recognizing these patterns in a standard is an important aspect of being able to understand them. Usually you should be able to find the publishing guidelines for a particular SDO. These can be very helpful in understanding the overall structure of their publications. It will also help by telling you which of the parts of the standard are formulaic (prescribed by the publishing guidelines), vs. which are novel, and what kind of content appears in each section of the document.
Another method is to obtain an understanding the terms AS THEY ARE USED by the SDO or the Standard itself. Most standards will have a definitions section which defines key terms as they are used by the standard. The SDO may also have a glossary defining terms that it uses in several standards. Common terms that you may already understand can readily become confusing when an SDO defines them in a way that is different from what you think you know. Dictionary definitions and SDO definitions are two different things. The dictionary definition tells you all the ways a term can be used and what it means. An SDO definition is meant to provide a precise meaning for a term as it is used in its standards. You may not like a particular definition given by a standard, but that's beside the point. You need to be able to understand the terminology of the SDO in the way it is used. There is some common terminology around conformance terms that are used by many SDOs; for that, familiarize yourself with RFC 2119.
Something else that helps is reading the back story behind a standard. In some cases this can be difficult to find, but in others it is easier. Some SDOs produce other publications before they produce a standard. For example the W3C often develops requirements documents before it develops the standard. These documents will often help explain why the standard works a particular way. In other cases, you can find mailing list archives, wikis or meeting minutes that will explain a particular decision. For example, you can check Google Groups for various IHE committee lists and discussions, or the HL7 web site or wiki for Working Group Minutes and it's mailing lists, or the ANSI/HITSP List Server.
Finally, some SDOs require one or more trial or reference implementations (e.g., OASIS) before making something a standard. Their is huge benefit here because these implementations can be very informative to one who has to implement a standard. A reference implementation can be used as a model for your own implementation, or it can be used directly to implement a particular standard.
Implement vs. Use
One question that you should really ask is if you really need to implement the standard at all. You don't need to implement a standard to use it effectively. In fact, the most effective users often don't implement a standard at all, instead they rely on the work of others (see The Right Tools for an example). One of the very beneficial developments around standards is that you can usually find implementations that have already been written for you. Your job becomes one of finding the best implementation to use, rather than developing the implementation yourself. This is a win scenario for you, because you get to move on to the fun stuff, and your customers get the benefits of your use of the standard.
Thanks Keith! Very succinct description. The mailing list links and reference implementation mention are particularly appreciated.
ReplyDelete