this is an essay on some ideas that have been swimming around in my head about "software standards" and the various pervasive myths associated with them, unleashed on this motley crowd for your viewing pleasure or distaste. there is tremendous amount of angst and anguish spent on software standards by designers. I'm going to try to point out some of the ways that software standards are fundamentally different from hardware standards and the implications this has for their use. with a hardware standard, we are talking about "atom configurations". if a given computer is manufactured in a given way, there are zillions of standards that are implicit in the design. there is a standard in the way that cards interface to the bus, in the ways that chips fit in sockets, in screw sizes, component sizes (such as the power supply), etc. obviously it is virtually impossible to refit a component that does not adhere to some "physical configuration standard". if the power supply does not have the right footprint, good luck filing down the edges to the point that it fits. <g> another point to make about physical components is that it is possible to "own" them. in our system, we are even allowed ownership of the abstract standards used to design their atomic configurations; we call these things "patents". however, notice that software standards are sometimes thought of in the same way as hardware standards. I want to make a point about how fundamentally different they really are. == software standards ultimately govern the "configuration of bits". to borrow Negroponte's lovely distinction, bits are far different than atoms. foremost of the difference is what might be called the fundamental "malleability" or "fluidity" of bits in contrast to atoms. atoms are expensive to move around and to manipulate. bits can be moved around and manipulated at such an infinitesmal cost as to be almost free. here is the chief myth that I want to address, and I'm going to borrow web concepts here especially, because the public is misapplying the concepts of hardware and software standards especially in this area. now suppose that Netscape comes up with their own unique HTML "extensions" which they have done. if you want to think of this "standard" in the old paradigm of atoms that are expensive to move around etc., then what netscape has done is pretty outrageous. one might assert, as the press and public tend to do, that Netscape is trying to "own" the standard and "impose" it on the rest of the world, so that they can "control" it. but what is this "imposition"? if they were saying that particular hardware components had to be designed in their way, indeed this would be an onerous and suspicious demand. it would be reminiscent of industry outrages like IBM's "microchannel" architecture. but the fundamental distinction here is that Netscape is *not* designing a standard that refers to atoms, but one that refers to bits. and standards that refer to bits have fundamentally different properties. first of all, if they are good standards, then it should be easy to manipulate the bits between the different standards, and the cost of doing so should be close to negligible. we are only talking about straightforward algorithms easily implemented by even 1st year CS students, typically. when you think about it, the concept that a company can "own" a software standard in the way that hardware configurations are "owned" is pretty obtuse and incongruous. because bits are so readily converted and manipulated, it actually becomes the case that companies that create bit standards are almost doing a public service in devising orderly systems of bit arrangements not previously established. if bits are interchangeable, then the key is to get them into an orderly form first, and then just twiddle them into the format that you want. == all this sounds a bit vague and nebulous but is extremely significant. it demonstrates how radically different the information revolution is from the industrial revolution. in the information realm, "interchangeable parts" takes on a whole new meaning. all that is necessary is that the bits be in some standard form to start, and then they can easily be transformed into some other form. a very important point to make is this: what becomes more valuable with bits i s *not* that everyone pick and agree on *the*same*standard*. this is applying "atom" type prejudice to a new problem. if everyone wants to have compatible hardware, then indeed we need to have the kinds of standards I described. but software (bit) standards work differently. you only want to have *any* kind of a standard that is well designed. you want standards that are not necessarily *universal* as with atoms, but instead are *orderly*. if they are *orderly* or "well designed", then it should be easy to convert any "bit configuration" standard to any other standard on the fly with algorithms. there is tremendous ranting and raving in the Web world about how the HTML standard is fragmenting because of Netscape etc., and there is so much angst about trying to devise a *single* cohesive, unified standard that "everyone" follows. people talk as if Netscape is trying to "hijack" the standard, when in my opinion they are performing a valuable public service of trying to hammer the bits into useful form. everything they have proposed could not be handled by the earlier standards-- and if it could have been, chances are they would have used that standard. a unified standard in software realms is a total fantasy to achieve, and in my opinion the dramatically wrong & specious goal. == instead, I taking into account the above ideas, what we need are a *variety* of different standards, all of them in themselves cohesive and fully functional, which can be *translated* readily between each other. the key goal is not *unified* standards that try to entail "everything", but instead collections of complementary standards that are in themselves nice unified "pieces" of the whole. (somewhat like original Unix design philosophy). the various image formats such as DVI, postscript, TIFF, etc. is an example of this. they all are decent standards for what they attempt to standardize, and it is silly to lament that there isn't a single image standard-- it misses the point. (one tricky thing with bit standards is the goal of trying to go "backward" in converting a very complex format into a simpler format. trying to have text-based web browsers with all the complex images and formatting out there is an example of this.) in other words, some people seem to imagine that in the future some massive HTML language is going to be devised that all browsers support. many web design discussions seem to implicitly talk as if this is the goal. instead what I imagine is that many different substandards will be devised, and will *continue* to be devised-- the point when there is a global, unified "web formatting language" will *never* come and this is an illusionary, impossible, and *unnecessary* goal. what we need are browsers that are extremely flexible and can support on-the-fly translation between different formats, and which try to support the capability that at any time in the future, someone may come up with a new language that could drive browser formatting and display characteristics. the idea of having different layers over the network, such as "conversion servers" which might convert between all the more common formats and requests, is another interesting idea to pursue. netscape 2.0 "plugins" are a first step in this direction. imho, the web of the future is going to have not one but a *zillion* different languages describing all of the data that is out there. the goal should not be unification under a single standard, but of ease of conversion between existing standards that are modular and complete in themselves. in this view, the complementing (not competition) of different formatting languages is glorious and to be encouraged, not something to be dreaded, avoided, and stamped out. the diversity and "complementarity" is the key to the power. == I've been making all my points relative to the Web, but I think the ideas apply equally well to *computer*languages*. there are all kinds of silly holy wars fought over about what are the *best* computer languages, and everyone that designs a new language seems to be implicitly trying to incorporate the features of every other language in existence and then some, i.e. a new "unified" or "complete" or "ultimate" language (I recall a long flamewar out in the newsgroups between Stallman, espousing Lisp, and Wall Perl fanatics). to me this is all ridiculous, because in the future the goal will be the ability to *convert* between languages in automated ways, such that the same problem can be automatically reformulated in another form to gain its particular idiosyncrasies. imho, new computer languages are going to be invented as long as human beings exist-- because what they really are is a "component library". for example, C is very low level but fast-- why can't I just convert my Perl code directly into C whenever I want to? or vice versa? in fact that is exactly what a compiler does, and I am suggesting that the compilers of the future will allow conversions between all kinds of languages, not merely a high level language to machine code. in this sense the idea of fighting over different languages as "ultimate" is ridiculous as the religious wars over who is the "one true god"!! all algorithms are in principle interchangeable, and I believe this theoretical concept will be increasingly applied directly in the future. == anyway, this is my contribution-of-the-moment in trying to dispel some of the "standards myths" that are extremely persistent out there esp. in regard to Web software and language extensions.