Standards and specs: Standards

Learn how to make the most of standards

Introducing a regular column on the specifications and standards affecting people involved in nearly every aspect of Power Architecture technology, Peter Seebach looks at the different kinds of standards in the industry today, as well as how to find out about and make the most effective use of standards in your own work.

Share:

Peter Seebach (crankyuser@seebs.plethora.net), Author, Freelance

Peter SeebachPeter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though.



27 September 2004

Some people don't like to worry too much about standards. As long as the code runs, that's good enough. But tomorrow, you may need to run your code on a different platform, with a different compiler, a different operating system, or just about anything else.

Most people are basically aware that standards are useful in that any two things you buy which comply with a given standard ought to be compatible. Standards, however, are not just a set of buzz words to let you buy something with all the right boxes checked!

Why standards?

If you're a developer building a product, standards give you some idea of which features you can rely on an implementor to offer you. If you're an implementor trying to sell a development system, standards give you a baseline for what people expect. In short, standards let you streamline the process of arguing which features need to be in a system, and they give you a framework for discussing which features are necessary or important to you.

Power Architecture™ technology gives you an environment which presumes some amount of standardization. You can buy a PowerPC® chip from any of several vendors and have reasonable expectations about what the chip will do. You can get a toolkit for designing CPUs which build on the Power Architecture platform and add specific functionality needed for a given task. The standardization of the architecture gives you a head start on development for such a CPU; if you're trying to sell a new CPU, the standard architecture makes your CPU a lot easier (and cheaper!) to target than an entirely new design would be.

The same issues are involved with a programming language. As a vendor selling a development board and host software to target it, you need potential developers to feel that your system won't take too long to learn. Almost no one would expect developers to learn an entirely new language to target a single platform. On the other hand, as a developer reviewing possible development platforms, you want to get as much mileage as you can out of your existing skills and experience.

Hardware standards let everyone share commodity parts. The cost of adapting a system to use an ATX power supply, instead of a custom one, is probably offset by the substantially lower cost of mass-produced, commodity power supplies. Market forces love standardization.

Contracts and compromises

A standard is a lot like a contract between parties. If you sell me a C compiler, you're promising to support the standard language called C, and I'm promising not to whine too much if you don't support a feature that isn't part of the C language, unless you specifically advertised it. A programmer developing in a standardized language is expected to produce valid code in that language; if my code isn't valid, then it's not the vendor's problem that it doesn't do what I want.

Of course, any contract will tend to have some points of compromise. Developers often ask for more rigid specifications of the exact behavior of a language; they also often ask for more and better optimizations. Vendors want more latitude to do things in simpler or more cost-effective ways. A standard offers some kind of compromise.

Often, when people complain about a "bad" standard, it's because they're solidly on one side of the relationship and don't fully appreciate the reasons for the compromise. Vendors may complain loudly and verbosely about the expensive additional requirements; developers may complain just as loudly and just as verbosely about the things that aren't required.

Trying to balance the needs of the various parties to a standard is a lot of work, and it takes a willingness on every part to consider the other people involved. If you don't feel your positions are being considered, you should consider getting involved with the process yourself, as discussed below.


How to get the most use out of standards

The first thing to do is to try to be aware of standards. A standard you don't know about isn't totally useless to you; it still provides you with a more stable marketplace. But that only goes so far; while today, most users benefit from the near-universal compatibility of wireless networks, it wasn't always like that. In the early days of wireless networking, some companies had 11Mbps wireless protocols which were not 802.11b. Some users bought these devices hoping to communicate with other devices and were sadly disappointed. The marketplace eventually killed most of the incompatible competition, but all of the involved parties would have been better off had they taken the trouble to look into whether a standard existed.

Even if your topic ("software interfaces to serial ports") doesn't have a standard, a related standard might exist (perhaps the termios.h part of The Open Group's standard). Larger standards might have parts related to what you're doing, or smaller standards may cover key components of it.

If you're a developer, try to keep track of which standards affect your development platform. If you're writing in C, familiarity with the state of the C standard helps you make informed decisions about possible compilers and development environments.

If you're an implementor, be aware of what standards do and don't require of you. Some standards have the potential for compliance with a subset, or have optional components. In an ideal world, you'd provide optional support for all such components, but in practice, you want to pick carefully based on customer demand. What you shouldn't do is implement something partially or incompatibly. C has some moderately famous quirks which are directly attributable to vendors who implemented something similar to, but incompatible with, some portion of the standard.

Don't forget that a specification need not be endorsed by a formal standards body to function as a standard. Even a de facto standard, widely enough documented and adopted, can save you a lot of time and money. A standard informally adopted by a half-dozen entities may serve you better than a much more visible standard controlled by only one. What's important is that you have a reasonable idea of what the standard is and how stable it is.

Finding them is half the battle

Finding standards can be a bit of an adventure. Standards organizations include ANSI, ISO, IEEE, and IETF (among the more famous ones). There are plenty of informal standards. Start by browsing Web pages and Usenet posts about the topic you're interested in. If you see people referring to compliance or compatibility, you may have found a standard. It's worth looking around and possibly talking to people working in that industry to see whether any relevant standards exist.

Word of mouth helps, too. I was confronted with the fairly common problem of finding the half-dozen different types of serial cables I needed to have to connect all my computers, and I complained to a coworker, who told me about the Yost serial "standard." This simple mechanism solved my problem. Is it a "standard?" A standards body doesn't endorse it, but it's a workable solution. Note that it doesn't matter whether other offices than mine use this standard; it's enough that I use it consistently internally, and it saves me a lot of time and trouble building cables.


Open standards

What exactly is meant by calling a standard open is a little vague sometimes. A standard that is not published is certainly not an open standard in any meaningful sense. Ideally, a standard should be open to participation by interested parties and not controlled by any one entity. A standard which is controlled by a single entity can easily be used as a competitive tool against that entity's competition. When this happens, everyone loses -- developers, consumers, and the competition. In many cases, even the entity abusing the concept of standardization ends up worse off for the experience, because open standards are generally more successful than closed standards.

An open standard will generally provide better compromises than a standard controlled by one party, or run entirely in secret. The more people whose inputs and needs are taken into account, the better. The IETF's policies and practices have exemplified this; for instance, the RFC process has consistently produced workable, well-considered standards.

With rare exceptions, standards which require financial outlay by would-be users are not a good bet. Given that a major purpose of standardization is reducing the cost of participation, adding costs is a bad idea. In some cases, patents or other restrictions might control access to a standard; this is often -- though not always -- a bad thing. In some cases, intellectual property rights can be used to protect standards. For example, Philips has refused to allow discs which violate the Compact Disc specification to use the Compact Disc trademark, because they were not compatible with all devices capable of playing compact discs. On the other hand, some companies have tried to use "sleeper patents" to demand royalties from people who, unaware that the patent existed, started using a proposed standard (a famous example of this is the handling of the LZW patent by Unisys, who began demanding licensing fees for the use of GIF files, after they had been in widespread use for a number of years without any licensing fees).

In general, any indication that a standard has a patent should be a bit of a red flag, unless you have clear permission to use them without fees or additional legal hassle.


Going beyond the standard

It's good to talk up the features you offer which are not yet mandated by a standard, as long as you're clear about them being extensions, so people depending on standardization and compatibility don't get bitten. Even though you're offering an "extra" feature, they might be offended by the lack of warning. If you're a developer or customer, it's often good to seek out products with extra features beyond those promised by a standard. However, be wary; if you commit to development depending on an extension a single vendor offers, not only could you be committing to spend a great deal of time and money reworking your development if you have problems with that vendor, but you might face subtle incompatibilities. Sometimes, the reason an extension isn't in the official standard is that it breaks something else that's important. Look for involvement with standardization, published or open specifications, and other signs that a feature is on its way towards being widely available.

If only one entity supports a given extension, be wary of relying on it. Such extensions can be subject to substantial changes without warning and can also lock you into a single vendor for that product; it generally makes better sense to minimize your dependency on a given vendor so you can take advantage of the wonders of competition.

In some cases, a widespread extension is effectively an additional standard. It can be a formal standard, as in the case of IEEE 754 floating point support in C compilers. On the other hand, some extensions and standards are much less formal; for instance, there's a de-facto standard for serial port headers (not DE9 connectors, just ten-pin ports), which is not mandated by any particular body, but everyone seems to have settled on it.

In some cases, standards aren't all-or-nothing. For instance, the C language standard supports both "freestanding" and "hosted" implementations; many of the C standard library features are required only in hosted implementations, and a vendor who is for some reason unable to provide them all can still produce a conforming compiler; it merely has to be called a freestanding one.

As another example, the C standard calls many things "implementation defined," meaning that, while the language does not specify a design decision, any particular implementation must specify and document the decision made. An example is the size of a char object in bits.


Take part

One option many people don't consider is getting involved with the standardization process. Many standards groups are fairly open; for instance, people in the U. S. who wish to start attending standards meetings can generally pay dues and start showing up. However, some limitations exist. For instance, if you are an employee of a company already represented on a committee, you may not be able to fully participate. But if your company's business is closely tied to a given standard, it could be worth a lot to have someone actively involved in the process. It would be a little odd for a vendor of compilers for a given language not to participate in its standardization.

Developers, too, can benefit from involvement in the standards process; not only is it a great way to develop a much more detailed understanding of a language or environment, but participation gives you a voice in the future evolution of the standard. I got curious about C standardization a few years ago and started going to meetings of the ISO C standards committee. Not many training programs in the world will teach you as much about C in a couple of weeks a year as attending those meetings. Furthermore, I like to imagine that I have, on a couple of occasions, helped the standards process work as designed.

ISO allows observing members -- members who participate in discussions and read the mailings, but don't actually vote. If you have limited resources for participating in meetings, but would like your voice heard in the standards process, this is a great way to be involved.

Charting the course

If standards relate to anything you do (and they probably do), it pays to be aware of them, and possibly be involved with them. For instance, if you're programming, it's a good bet to have someone on staff, or at least a good contact, who can serve as a language lawyer (see Resources). Try to find open standards when possible and comply as much as possible. Don't be afraid to admit that a standard doesn't quite match your project, but be sure to document such decisions carefully. If you're a vendor, make it as easy as possible for people to tell when they're stepping outside the scope of standard behavior and into your extensions.

And don't worry: we're here to help. Every month in this space we will meet the specs and standards which affect developers involved with Power Architecture. Whether you're developing new Power Architecture chips, embedded prototype boards based on them, or a product using one of those boards, we will navigate them all -- and you can influence that, too, if you drop me a line.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Multicore acceleration
ArticleID=32322
ArticleTitle=Standards and specs: Standards
publish-date=09272004