In an ideal world, the answer would be "yes." Around these parts, though, the answer depends on the type of standard, time and circumstances, and your views on economic theory.

I’ve received several emails and seen several articles asking whether any eventual decision by Massachusetts to approve two different document standards (e.g., Microsoft’s XML Reference Schema (XMLRS) as well as the OASIS OpenDocument Format) would be a serious blow to the goal of achieving long-term access to documents. Here are a few examples, each with appended comment threads, if you’re interested: one at at CNET.com’s Blogma page, and this one by David Berlind.

The quick answer is that the “one standard – good, two standards – bad” response is not always the right response, because there are different types of standards that serve different purposes, as well as different situations that have different dynamics. So my purpose in this post will be partially to give my own take on the “one standard or two?” question in the context of ODF vs. XMLRS, but also to help frame out the debate so that others can form their own conclusions with more context to work with.

So here we go. The first distinction that I want to make is between kinds of standards. For current purposes, let’s talk about just two of the most common types:

1. Performance standards: These include things like how many watts or lumens a given bulb is rated for. The intervals between ratings (e.g., 40, 60, 100 and 150 watts) can be arbitrary, since the goal of the standard is simply to give certainty in the energy demands and output of what you’re buying, and to allow for comparison shopping. The same goals could be achieved if the ratings had been set at 35, 55 and so on. And, in fact, if two different sets of standards had for some reason developed, you could still compare bulbs rated at 35 and 40 watts pretty intelligently.

2. Interoperability standards: In information and communication technologies, most standards are of a different kind, and exist for the purpose of allowing diverse programs and devices to “plug and play” with each other. The benefits of these standards are huge, and include the following: the “network effects” that economists like (the more nodes to the network, the more valuable the network); less risk of finding oneself in a legacy situations; comparison shopping and competitive bidding; and so on. Using our light bulb example again, without standard bulb stems, you would have to buy your bulbs from the same manufacturer that made the lamp.

From the above examples, you can see that performance standards are useful, but not essential, while interoperability standards are either essential, from an economic sense (e.g., to avoid great time and expense to constantly jury rig systems and convert data), or in an ultimate sense, since they permit something to be done that otherwise could not otherwise be done at all (e.g., making possible the creation of the Internet and the Web).

The second distinction I’d like to illustrate has to do with time and circumstances. The time element is important, for two reasons. First, where a market has not yet emerged, it’s easier to agree on a standard, because no vendors are heavily invested in any particular solution. These standards are called “anticipatory standards,” and they are often created with less contention. The opposite situation is where many products already exist, and where the eventual standard adopted can often favor one vendor over another.

There exist, as you might expect, many gradations in between, that arise from preexisting alliances and cross-licenses, ease of migration, and so on. As a result, things can get bloody even with anticipatory standards, sometimes just because there is so much at stake. The current HD DVD-BlueRay standards battle is an excellent, and regrettable, example of such a situation.

But the time factor can lead to an interesting and contrary result: sometimes its actually good to have competing standards. Let’s use the first generation of wireless interoperability standards as an example.

Once upon a time, there were groups working not only on creating the Bluetooth standard and the first Wi-Fi standard, but others as well — such as HomeRF. And today, there are additional standards that are in the same general functional area, such as the Near Field Communication standard. Many of these standards were originally touted as being head to head competitors to serve the same purposes.

But setting standards can sometimes be like skeet shooting — you have to swing your shotgun, leading the clay bird, and making your best guess where the trajectories of the bird and the shot will intersect in the future, knowing that a sudden gust of wind can mean a clean miss even if your calculations and your aim were otherwise dead on.

The difficulty of predicting the future when setting anticipatory standards is clearly demonstrated by the example of early wireless data standards development. HomeRF disappeared, Bluetooth found a home in one set of short-range applications, and Wi-Fi predominated for longer distances, while Near Field Communications is filling in application gaps left by both. In each of these cases, there was an overlap of situations where both techniques could be used.

But over time, it became clear which standard was optimally useful within those areas of overlap. If all of these standards hadn’t been launched in anticipatory mode, then large gaps may have been left in the standards landscape (or those gaps may have been addressable only using a standard that offered sub par performance) by the time that hardware and software developments were complete and products were ready to sell.

Note also that while the Bluetooth standard appears to be fairly static, the 802.11 standards development effort within the IEEE that gave the world the extremely successful Wi-Fi standard is going on to provide multiple additional generations of development (e.g., WiMax and WiLan), some of which have spawned internally competing submissions as well.

Let’s take just a moment to look at circumstances, by which I mean the impact of reality on the standard setting process. For better or worse, standards are thrashed out in the trenches, and idealism often yields to pragmatism. So it is that the best standard does not always get adopted, just as the best product does not always win over the hearts and minds of the marketplace. As a result, pursuading the market to implement a particular standard often requires tactics, alliances, and, not atypically, some luck as well.

Here’s one last distinction to take into account when deciding whether one standard is always best: the value of certainty vs. the benefits of competition. There are some economists who strongly argue that two standard are always better than one — and that in some situations we would all be better off with no standard at all. In their view, setting a standard too early in the process stifles innovation, and leads to constraining the technical choices that vendors can make, and therefore the solutions that are available in the marketplace to buy. More to the current point, they also argue thate if there are two standards, the proponents of both alternatives have a greater incentive to further optimize their standard, and to update it to remain current with market demands.

So — what conclusion does that lead me to in the case of ODF and XMLRS? Let’s go through the same distinctions I laid out above, beginning with “what type of standard do we have here, anyway?”

Well, clearly neither ODF nor XMLRS is a performance standard (although in a given situation one of the two formats will have performance advantages over another). Nor are they really interoperability standards, as we usually think of them, although (I assume) each would facilitate interoperability.

What they really are is “accessibility standards,” but not in the same sense that accessibility has been bandied about lately as part of the same debate. More succinctly stated, the unique value that each is intended to provide is to augment the availability of data over time. So in this sense, they are more like performance standards than interoperability standards, because the value of having one as compared to two is relative rather than absolute. To use a comparison, it would be better if we only had to have one set of socket wrenches rather than two (e.g., English and Metric), but as long as we have both, we can still do what we need to do, and life goes on. Stated another way, we’re not by definition in a network situation.

How about time and circumstances? Well, the fact is that there are one whole hell of a lot of Office documents out there, so Microsoft has a justifiable reason to want a good solution for Office users. Also, there really isn’t any reason why one would expect Microsoft to want to make it easy for its competitors to poach any of its customers. That’s just reality, so ODF proponents have to deal with this dynamic strategically and tactically. (Parenthetically speaking, I think that they’re doing a pretty good job of it.) Of course, as I’ve noted often before, its only fair to observe that the same vendors that are promoting ODF would be no more likely to act philanthropically if their own crown (profit) jewels were at stake than is Microsoft.

Finally, what about certainty vs. competition? Well, the goal from a societal perspective is first and foremost to move to a situation where all documents remain available. It would be better if we only had to have, in effect, one set of socket wrenches, but better two than none. Note also that just because we may begin with two sets of tools doesn’t necessarily mean that we will not eventually end up needing only one, either because one format appeals to the marketplace better than the other, or because the two standards ultimately converge (as Alan Yates last week predicted would eventually happen). But whatever ultimately transpires, the certainly today is that because there are two alternatives in the marketplace, the proponents of both ODF and XMLRS will need to compete with each other. And that’s a good thing.

One of the biggest winners from this dynamic will be people with disabilities. To date, Microsoft has mostly responded to accessibility needs when required to do so. But it has not been driven to excell in the delivery of accessibility in order to maximize either its market share or its profits. Instead, market conditions have provided incentives only to meet minimum requirements.

But with two standards in play, there is motivation for competition between both camps to create more and better accessibility solutions — and that’s a very good thing.

So where do I come out?

Well, the older I get the more I tend to adopt a practical rather than a religious attitude towards standards. I certainly do think that it would have been a heck of a lot better for all concerned if Microsoft had taken advantage of its opportunity to be a charter member of the OASIS ODF Technical Committee and fought it out with Sun and others to create one standard that all Oor at least most) of the members of the TC would eventually support, that the entire OASIS membership would adopt, and that would have provided a good solution for existing Office users as well as a tool for increased competition among a greater variety of office productivity software applications. But Microsoft chose not to take that step, and (to understate the obvious) there’s nothing that I can do about that now.

The good news, of course, is that ODF is gaining traction, and now the competition is on. Just because Massachusetts may ultimately approve XMLRS doesn’t mean that it will necessarily use it — that will depend on the products that are available (which will include ODF converters for use with Office documents). Microsoft will still have to convince those that make purchasing decisions that they are better off with XMLRS than with ODF (and, of course, the opposite will equally be true). And a rubber stamp by a standards body – if that’s what it proves to be – won’t make any difference in those decisions. Instead, there will need to be demonstrable value and market confidence that XMLRS will become more, and not less, open as time goes on.

Hopefully, the ODF and XMLRS specifications will merge some day, with the final standard perhaps being better than either of the progenitors. If that happens, our document format toolboxes will only need one set of accessibility wrenches. And if we need two sets for a while, that’s a hell of a lot better than having none at all.

Remember yesterday?

subscribe to the free Consortium Standards Bulletin (and remember to Buy Your Books at Biff’s)