The former State Government CIO of Massachusetts (a state in USA) Louis Gutierrez has a worthwhile interview in Computerworld this week. What I like about the article in particular is that he seems clear that the role of govenment is not just to passively accept standards, but to pragmatically assess the suitability and impact and processes of each one. ISO makes “voluntary standards” not laws.
Gutierrez says the obvious: that there is a marked difference in the feature set between ODF and OpenXML (”straightforward simplicity” versus “feature-rich but very idiosyncratic diversty”): he does not trivialize the difference in coverage or scope between the two. More interestingly, though he is obviously not a pluralist at heart he does acknowledge that there may be legitimate benefits in plurality (especially if we take the strategic view where we are trying to set up the pre-conditions for full-function office standards, to benefit users rather than hungry vendors.)
…The trouble with people who say “You are ignoring the elephants in the room” (i.e. that the utterly dominant thing is the corporate and political machinations) is that the room actually contains more than elephants…at the end of the day, when the elephants have left, some poor schmuck has to clean up. The hard technical issues cannot be ignored: which applications work?, can the format carry the information we need? for each area, what is the allowed trade-off between fidelity and interoperability? What validation is being performed? Which version of the standard is being required? Which profile? Which test suite? What encouragement is being given to Open Source developers (e.g. KDE)?
Here’s some quotes on ODF and OpenXML from late in the article:
Do you have an opinion on which way you’d like to see that battle go? I have an idealistic opinion that I am not putting a lot of odds on. It would be great to see a merging of standards over time — to see the straightforward simplicity of ODF married to the enormously feature-rich but very idiosyncratic diversity of Open XML, and to have the world come to a place where it says, “Look, we can enhance the one and simplify the other and come to a real standard place.”
One XML? One core XML, with possible embellishments that are put in by competitors. That’s kind of the idealistic wishes of someone who likes less rather than more.
Do you see any reason for there to be two standards? If you were starting blank-slate, there certainly would not be value to creating two separate standards. Over time, it has sometimes been useful to have the competition of two standards to keep both sides honest. But I don’t see particular value in the long-term co-existence of two separate standards.
Did you get any indication that the current administration is going to change the ODF policy? No. Although I can’t in any way speak on their behalf or pretend to speak on their behalf, the things I'’ve heard are the things that are most encouraging. They are going through the standards processes. “Let’s take a look at Open XML. Let’s evaluate it against the things we wanted in a standard.” I think the new administration, they’re very good government people.
Nice. I concur on the quality of the interview. I also like your list of all the things that have to be worked out when the elephants have gone. There needs to be a lot more visibility on that all around.
There is an ongoing and never resolved debate in technical circles about overspecification and underspecification of standards. Yet the clear pattern is that when a new specification is offered, its supporters make the claim that the specification they seek to oust is 'overspecified' or 'overdesigned' or 'too hard too implement' or just ugly.
The supporters of the older specification claim exactly the opposite.
In debating Kurt Cagle recently on these pages, I noted that the 27-page triumph is by *separately published appendices* now quite a bit larger than the parent even if more successful. So the slow walk to complexity as a market winner never changes. It always comes down to costs. That is the real elephant in the room because the rest of those arguments are simply Spy Vs Spy.
This goes on everywhere. Here is a quote from a disingenuous speech given at a recent virtual worlds conference by Raph Koster who is attempting to leverage his success with Ultima to launch his own company with its own standards:
"Raph: Closed formats suck. [Applause.] Need I elaborate? It's true everywhere. If you want to try to leverage other peopel's workk, you have to be able to share the damn stuff. The fact is that other than, the reason why SL went with what they did was that they were inspired by older formats that were intended to be easier to use, so it owul dbe easier to build stuff, but oibviously there were tradeoffs. Honestly, the standard in gamespace *is* to use standard formats. It's not unusual to upgrade models over time, migrate platforms, etc. They wouldn't be able to work if they had to build custom objects every time. The difference is in the sharing, not in the formats.
Audience Q: Mentions VRML, polycount too high, how do you get around the rendering problem?
Raph: Particularly for this kind of networked VW application, VRML didn't contribute hugely to the kind of spaces we're talking about today. It was insanely heavy, over-designed in a lot of ways. There are virtues to having to do things for commercial reasons: You have to get shit done quickly and cheaply and small, otherwise you lose your money. The commercial formats ended up being the good ones. But even in the commercial world it's a constant struggle against artists that want to use millions of polygons."
Note the tensions here and the arguments offered are precisely the same. The game never changes. Costs change.
I'm not sure that my arguments boil down to overspecification vs. underspecification of standards. These are complex applications - it stands to reason that the specifications for them will be complex as well, and the page count issue to me has always struck me as something of a red herring.
My primary argument against OOXML is that as a standard it has too many interdependencies upon other core Microsoft-specific technologies, many of which are not themselves under any standards body. Many years ago, about the time that SVG was still being hammered out, I was rather delighted to discover that Microsoft had an XML language for describing vector graphics (VML). When I went to save some Visio images in VML, however, I found that the resulting VML files consisted of a thin veneer of XML and the meat of the graphics were instead object tag references against binary resources. This was, admittedly, some time ago, but it also was to me a telling indicator of how Microsoft approached publishing content to XML.
VRML failed to work for a fairly large number of reasons that had little to do with overspecificity. It was too early, being released before there was enough technical innovation in sufficiently wide-spread use to provide benchmarks for standardization - rather than codifying best practices, it tried to predict them, something that I think SVG also suffers from.
The use-cases for VRML envisioned a "Snow Crash" like view of the world, rather than recognizing that a critical role for such standardization had to include interoperability of model formats. It also failed to provide an adequate extensibility mechanism, something that I think any standard should address.
Finally, it assumed that the primary consumers of VRML would be a generalized public, while to anyone outside of the 3D space modeling space, 3D is a fairly complex and daunting arena. I'm not really sure that I see how these directly play in the OOXML vs. ODF debate.
Microsoft's concerns here are obvious - they have enjoyed a monopoly in the office space that begins to erode pretty quickly if the rest of the industry standardizes on something that they have relatively little control over. This monopoly has existed in great part because Microsoft also controlled the primary distribution platform, meaning that they could in general insure that new Office products would generally be able to make use of features that would only appear much later in the development cycle to other vendors, and was then perpetuated by licensing structures that generally made it very difficult to consider alternative solutions.
So long as Microsoft was in fact innovating better than the rest of the industry, this was not in fact perceived as a problem. Now, however, it can be argued that most of the significant innovations taking place in the industry are occurring outside of the Microsoft sphere (a statement I make with no apologies to those who are significantly pro-Microsoft in these forums).
Now let me say another thing here - I think the release of OOXML is fantastic. It provides a vehicle for me to integrate Microsoft office products into my XML pipelines, even if that process is fairly complex, and in many ways is I think one of the most significantly beneficial things that Microsoft could have done for their bottom line.
However, that does not mean that I feel that OOXML should in fact be considered an ISO standard ... ECMA, sure - such standardization insures that there will be no new surprises that will render OOXML obsolete with "the next version" of Office - but not ISO. The specification would have to jettison a significant amount of the ancillary technology that it uses to do so, and in the end I suspect would likely not that much different from the ODF standard ... at which point the question being raised should be why there is a need for two such standards.
There's an either/or situation here that I think OOXML proponents fail to realize. If you buy into OOXML, you also buy into all of the ancillary technologies that do the same thing that established standards already do. In short you choose one leg on which to build your application. If you choose ODF you basically end up choosing the other leg of the trousers. You cannot in general have both legs in the same trouser leg - even if they fit, you're basically able to do little more than hop around, and that only until the leg splits at the seams.
If Microsoft really wants to put together a superior product, then it should participate in the ODF standard for a 2.0 version that moves a little closer to its own perceived needs, recognize that their monopoly isn't going to last much longer anyway if they are at a stage where they are losing customers because of their own inability to work with them on something as basic as interoperability, and compete on quality. I don't think anyone - the ODF TC, the ISO standards committees, the customers - would seriously have any problem with that, and it would show that Microsoft recognizes that the world has moved away from where it was in 1997.
I recognize that I am opening up myself to all kinds of flames here, but I think this needed to be said.
Thanks for this post Kurt, it was insightful. Totally agree.
Kurt: You say "My primary argument against OOXML is that as a standard it has too many interdependencies upon other core Microsoft-specific technologies, many of which are not themselves under any standards body."
Which technologies are you thinking about? VML is part of the spec, for example, at s.3.6. There is a good intro from Ecma.
(Incidentally, it seems that VML has been phased out in favour of drawingML and is only included for documentation purposes: it is only used in some residual places in Word, which still generates/accepts decorations such as background pictures and text boxes using it AFAIK. Probably more useful to discuss VML in terms of what the spec says rather than how some product implemented it 7 years ago :-) )
The purpose of OpenXML is to document what MS Office actually does. Saying it should use other technologies is like saying that the TV guide should have better programs...the value in the TV program is that it corresponds to reality warts and all. Remember, just because a technology is described in the standard does not mean that people have to use it or adopt it.
Ok. Flames it is. It seems the people we have to keep honest are us.
1. VRML was too early. The fact that it is still in use and that the tools and content are still working ten years later say a lot about the correctness of the design. Applications such as Snowcrash were talked about but never considered seriously because they are impossible. VRML1.0 is a repackaging of SGI Open Inventor. VRML97 is an extension of that. It was a successful commercial 3D language. So the point of view that it tried to predict rather than codify best practice is misinformed and underresearched.
2. VRML is extensible, in fact, it is extensible in ways that XML is not nor will ever be. Study the language and understand the application of a PROTO. Or go to http://3donthewebcheap.blogspot.com/ to learn about the language and the means of extensibility. It is easy to do.
3. The idea that the general public will build HTML/CSS web pages with full up Javascript is equally bogus. The problem for 3D graphics is not the complexity. If I can do it, anyone can who is willing to learn the language. The problem is talent. Successsful graphics takes more talent than web page design. Always has and always will. That is why game designers make far more money. That talent actually is rare. OTOH, I can build with VRML and it isn't really that hard. See URL above.
I programmed VML as well. The problem there is actually that Microsoft left it as a dead dll in the IE deliverable and did not fix bugs. However, as a basic set of XML tags for including via CSS refs into the HTML tree, it worked very nicely until one hit the bugs in the implementation, particularly bubbling of events. MS needs to fix it and extend it to cover the loss of SVG mindshare.
That MS specifications poised to become standards reference working Microsoft products should surprise no one. To do otherwise would be stupid in terms of business and customer support. As to standards support, I don't blame MS any longer. I watched them submit perfectly good designs to the W3C only to be turned away by the minority AnythingButMicrosoft crowd. As a result, we now have XML Schema instead of a better design. If I am any judge, SVG could be smaller and simpler as well. So could VRML, but it is in its third generation now thanks to having stayed OUT of the W3C quaqmire. It provides multiple encodings, profiles, and even XML if you want it. I'm a long time markup wonk, but even I have to admit that XML is a bad fit to graphics.
As to general public use, do you really really believe that the general public will actually use either of those dcoument standards in day to day work or look at the XML they produce? That is incredibly Quixotic. No admin or tech writer I've ever worked with spends that much time in the export/import format syntax. Programmers and light developers do occasionally. Otherwise it is a button push and a file save for the general public.
But it is a business for me and you. And that is what this Spy vs Spy debate comes down to: one group of programmers and politicians doing the work of the companies that proposed one standard over the needs and purchasing power of the customers of another.
That is a battle you are going to lose.
As to VRML, study it and build with it or quit adding more misinformed punditry that is long on the myths and short on the facts. You disappoint me, Kurt. You are smarter than that and a better engineer. Do your homework. Build some VRML/X3D content but learn how to do it well first. Like any language, it can be done inefficiently as many of us have done, or it can be done well with practice and study.
That is what Raph is being disingenuous about. He wants to sell his own company products as The Standard. Sun wanted their own company product to become a The Standard. Microsoft wants their own company product to become The Standard. That is The Standards Game. We taught them how to play it and now, as the twig was bent so grows the tree.
Who is to blame? We are, Kurt. You, me, Bray, Bosak, Paoli, Berners-Lee and so on down the list. Denying that now is like watching Cheney and Co. tell Scooter Libby how sad it is he is going to jail.