roy@phri.UUCP (Roy Smith) (06/04/85)
For the past few months, Seth Pinsky at Rockefeller University
and I have been exchanging sequence analysis software and complaining to
each other about the lack of standardization in the programs. We would
like to improve the situation. Towards this end, we are trying to
enlist people who write sequence analysis software to form a standards
committee.
After a bit of asking around, it seems that no such committee or
project already exists; if you are aware of such a body, please let me
know so we don't end up working against each other. Also, if you know
of any large audience which isn't seeing this message (because they are
not on usenet) but should, let me know about that too.
Note that we are primarily interested in talking to programmers
(rather than users). This is intended to save time, not to offend.
Clearly, since scientists are the end-users of the programs us
programmers write, their input is vital towards making intelligent
scientific decisions. However, the issues we intend to discuss are
primarily programming, not scientific problems, and we don't want to get
bogged down in arguing about what a good ribosomal binding site looks
like.
It is also clear that the set of all scientists and the set of
all programmers are not mutually exclusive. Just because you are one of
the former doesn't mean we don't want to talk to you. In fact, the
people we want are probably the intersection of the above two sets. If
you are from any of the established data-base groups (GenBank, EMBL,
NBRF, Bionet, etc.) we are particularly interested in hearing from you.
Both Seth and I work on Unix machines. We don't want to get
into Unix vs. VMS vs. TOPS-20 vs. IBM debates, but initially any
programming efforts will probably be confined to software which runs
under Unix, simply because that is what we are most familiar with.
Eventually, I think our goal is to come up with a comprehensive set of
programs which are portable to other operating systems and to hardware
from various vendors, but this may be more work than we are willing to
expend.
Before we start writing any software, however, we want to come
up with standards for how the software should behave, rather than
actually worrying about specific implementations of algorithms (i.e.
RFC-style documents). Even before that, the first step is to locate a
group of people who can give intelligent input into the whole process.
For more information, contact:
Roy Smith
Public Health Research Institute
455 First Avenue
New York, NY 10016
(212)-578-0822
{allegra, rocky2!cubsvax}!phri!roy
--
allegra!phri!roy (Roy Smith)
System Administrator, Public Health Research Institutedhs@iddic.UUCP (David H. Straayer) (06/05/85)
To: orca!tektronix!uw-beaver!cornell!vax135!timeinc!phri!roy
Subject: Re: Sequence analysis software standards committee forming
Newsgroups: net.bio,net.std
In-Reply-To: <247@phri.UUCP>
Organization: Tektronix, Inc., Beaverton, OR.
Cc:
Bcc:
Hi, I'm Dave Straayer at Tektronix, Inc. I work on American National
Standards Committee X3H3, and its International Standards Organization
counterpart ISO TC97/SC21/WG2. These committees seek to write standards
for the application interface for computer graphics programming. Thus,
there is some similarity, if I understood your posting correctly. Both
the standards I work on and the standards you propose developing have
programmers as their primary intended audience.
There are several different "flavors" of standards, and the route you
choose on your path to "a standard" will affect the time needed, the
potential political entanglements, and perhaps even the ultimate
acceptance of your result by its intended audience. The route we are
taking is committee development. I'm now pretty sure that this route
results in standards taking a lot longer than any of us would have
imagined possible. Also, it exposes the process to significant
political pressure.
Another route is the "canvass process", in which a group of interested
parties goes off and prepares a complete draft, and then submits it to
ANSI for approval as a standard. This is the route that the IGES
CAD/CAM data interchange standard used. Interested parties, in this
case aircraft manufacturers and CAD/CAM system vendors, went off and
wrote a draft. They submitted the draft to ANSC Y14, a technical
committee which operates under the rules and procedures of the American
National Standards Institute, ANSI. This resulted in a pretty timely
adoption of a standard which has served a lot of users.
Another route to use would be to utilize an independent organization
which does not label itself as associated directly with ANSI. IEEE, for
example, has written many standards which receive wide use, and many of
them have subsequently become ANSI standards. ACM is establishing
itself as this kind of standards-making body.
One good reference on standards is:
Standards and Standardization
1983
Charles D. Sullivan
Marcel Dekker, Inc.
New York and Basel
Chuck worked at Tek until his untimely passing a couple of years ago.
This book gives you a good overview of how standards are formulated and
used.
On the topic of software standardization in particular, another
reference is:
Programming Language Standardisation
1980
I.D. Hill and B.L. Meek
Ellis Horwood Limited, Chichester
a division of John Wiley & Sons
Finally a GREAT information source is the ANSC X3 Secretariat. X3
coordinates development of standards relating to computers. The
secretariat and the folks in it constitute a fantastic information
source and support mechanism. The "main person" there is:
Ms. Catherine A. Kachurik
CBEMA - X3 Secretariat
311 First Street NW
Suite 500
Washington, DC 20001
(202) 737-8888
The computer industry is changing, and I believe that standards will
play an increasing role in the maturation of the industry. Users of
computers are growing less tolerant of incompatible hardware and
software. Defacto standards based on market dominance constitute a
valid and useful part of the solution. Formally adopted standards
constitute another important part of the solution.
If you are undertaking to standardize an aspect of computing, I urge you
to begin by gathering some information about the process. Don't be
dismayed by the seeming complexity and confusion. Understand the value
and cost of your work, make a plan, and execute it. Don't be timid! It
is easy to conclude the project isn't worth the pain (and so it may be).
I would like to encourage everybody out there (here) on the net to
support and participate in the general effort to standardize our
computer industry. There are lots of benefits for all of us.