Military tacticians often bewail the havoc that the "fog of war" (i.e., the inability to communicate effectively amid the chaos of the battlefield) wreaks on their carefully laid plans. I sometimes feel the same way about the challenge of maintaining a productive dialogue in highly competitive standards situations. When the commercial stakes begin to rise, there too often seems to be a greater desire to exchange verbal salvos than to actually communicate. And it also becomes more tempting to be content with generalizations than to try to get to the bottom of things to figure out what's really going on.
About 10 days ago I tried to do a bit of fog cutting by posing a few questions at Jason Matusow's blog at the end of a post he had titled Independent Implementations of Open XML. Jason does a conscientious job of trying to answer all of the questions that people leave at his blog, including those that are not exactly what you'd call polite. In this case, Jason had listed six implementations of OOXML, supplying the usual links to the sites of the vendors in question.
What I wanted to get to the bottom of in this case was what exactly these implementations were trying to accomplish. ODF advocates like to focus on not only the potential for ODF to be used as the basis for office productivity suite implementations, but on the reality that such suites have actually been produced. They also like to point out that there are no such suites implementing OOXML, other than Office itself, although there are products (such as Novell's OpenOffice implementation) that can save to the OOXML format. And to be fair, Microsoft has consistently said that OOXML and ODF were created for two entirely different purposes. So I was curious to learn to what purposes these implementations were intended.
Does the nature of those purposes really matter? Yes, I think that it does. But before exploring that statement further, let's take a look at the questions that I asked at Jason's blog, and how the thread developed from that point forward.
Jason had opened his post by addressing the questions that have raised about the quality of the OOXML spec, and then moved on to make the point that quality (or at least utility) is in the eye of the beholder – in this case, the marketplace – a point on which I agree. He concluded his post as follows:
So how about those independent implementations? I'm not going to go crazy and try to list them all here. I would recommend checking out the OpenXMLCommunity list of projects and if you are interested in doing some work yourself to build an implementation - check out OpenXMLDeveloper.org. Also, my colleagues in Germany have provided me with this link to more than 160 projects implementing Open XML (but I think it best if you know how to read German for that one).Here are a few:· Monarch from Datawatch· XMLSpy from Altova· iPhone from Apple· Mindmanager from Minjet· Gnumeric from Gnome· Dataviz Documents To Go from Palm· Open XML IIS Analyzer from IntergenAt some point the question needs to be raised about the desire for standards bodies to have work items that represent what is current and valuable in the marketplace. There is still hard work to be done on Open XML within the formalized context of JTC-1, and that is good. But, there is no doubt about the fact that this compelling technology is enjoying an explosion of interest in the marketplace completely separate from the sale of Microsoft Office. That is a very practical measure of the quality of this specification.
Following those links, though, doesn't tell you much about exactly how the products noted actually use OOXML. Are they complete office suite implementations, like OpenOffice or KDE, or do they utilize OOXML only to enable their exchange of information with Office? So I asked the following:
Jason,I think that where the confusion comes in is at two levels: first, when most people say "there are no other implementations," what I think that they mean is that there is no other competing office suite based upon OOXML, although some suites (such as Novell's ODF implementation) will be able to save to OOXML.The second is whether these implementations are stand alone implementations that are using OOXML as a preferred tool, or whether they are implementing it solely because they need to intereact with Microsoft products.When lists are posted of products that implement OOXML without explaining the how and why, I think that it leaves people still puzzled, particularly where products such as the iPhone are mentioned, because it isn't intuitively obvious how this would be done, or why.I think what would be helpful would be if you, or someone else, could explain the how and why. For example, my assumption (which may be all wrong) is that most of the implementations would be to allow other products to interact with Office, making their implementation more in the nature of utilizing an interface standard rather than as a foundation for their product chosen for OOXML's intrinsic merit.If the above list is as good as any to use for this purpose, it would be very interesting to explain, for each product:1. Is this implementation for the purpose of working with Office (for example, in the Datawatch product, is the implementation only in order to allow mining of data saved in Office 2007 databases?)2. If not, how is OOXML being used, and to what purpose?On a different note, It would be interesting to know whether the product could or could not have been based on ODF, and if not, whether the reason is other than because the product needs to work with Office 2007.
In the days that followed, a number of folks from the vendors Jason had linked to logged on to answer these questions, and a variety of other interesting and worthwhile comments were posted as well. I won't try and summarize them here (as of today, there are 35 comments), but they make interesting and informative reading, and I'd suggest you check them out if you're interested in what others are using OOXML for. I posted another comment at Jason's blog with my take-aways from these comments. My observations read in part as follows:
As a non-technical person, what I'm taking away from this thread is the following:1. My initial question is too simplistic. It seems that you can't divide OOXML implementations into just those that are for the purpose of working with Office, or data stored in Office, and those that implement OOXML for their own stand-alone purposes, although that does work for several of the products.It seems that the question does work for Gnumeric and Altova (the answer for each is pretty much, "the former"). In the case of Records for Living, though, OOXML will be used to create documents for use "outside" the application, as it were (that's probably more metaphorically than technically accurate). And for Datawatch (an old client of mine, as it happens, back in the early 1980s, when they were doing TEMPEST technology), the answer is also more complex.2. Andrew and Ben also take the question to a level of technical detail that is beyond my competence; it's hard enough for me to see the forest here, let alone separate the technical hierarchies from the trees (sorry, couldn't help myself there).3. OOXML has some aspects that some find attractive, and preferable to earlier Microsoft technology.4. As between ODF and OOXML, the question is, from a business perspective, somewhat moot, given the minimal market penetration of OOXML to date.5. It doesn't appear that any of these products are "built on" OOXML, in the original sense of my question. That's not too surprising, given that it only came out of Ecma last year, and still isn't final in ISO/IEC JTC1. That makes the question somewhat premature, although given the installed base of Office users and the anticipated level of upgrades, early implementation in the manner described in this thread has obviously been seen to be a smart business move.
Further comments followed. Jason added a new blog entry with his own observations on the implementation question, which you can find here, and this entry is now also collecting comments.
The moral of the story, I think, is that words are cheap, and the market ultimately decides where it finds value, and how. I'd like to see more quality information on exactly who is implementing each format, and how, and for what purpose. If it turns out that most OOXML implementations are solely to interoperate with Office or to extract data from Office, that will mean one thing. On the other hand, if OOXML is also used for entirely different things, it will be quite interesting to see what those things are as well.
It will of course be even more telling to see who is buying or using those implementations. And finally, it will be quite interesting to observe how, in the long run, this market activity feeds back into the further evolution of ODF and OOXML, and how those with the most at stake on the vendor side react to the requests of other stakeholders for such evolution.
Ultimately, I wouldn't be surprised to see happen with ODF and OOXML what happened with the first wireless standards. Early on, we saw WiFi, Bluetooth, HomeRF and some other now-forgotten specifications all competing to enable wireless LANs. After a few years, WiFi won the original battle, becoming pervasive in home and some commercial LAN settings, while Bluetooth became the tool of choice for short-range mobile device to device communication. Five years from now, we may see that OOXML is still only used in one office productivity suite and in other products that need to interact with Office, while ODF is implemented in many full office suites. But we may also see that each format is also popping up in some other surprising places as well.
Which brings us back to the original question of how each format is implemented, and whether in fact the answer to that question matters. You may recall that I said that I thought that it did.
The reason that I think it does is the same reason that I have taken so much interest in document formats. That is because the future accessibility of the documents of the present is dependent upon the broad adoption of the standard (or, less ideally, standards) that is most likely to be supported on as close to a perpetual basis as possible. What we see in the marketplace in the next year or two, rather than what happens in ISO/IEC JTC1 in the next six months, or in the words that we are slinging back and forth today, will ultimately determine which standard - if either – will actually achieve this vital mission.
I'd encourage those of you that are more technically adept than I am to contribute your comments here or at Jason's blog to help flesh out the knowledge base on what implementations of each standard are actually trying to achieve. I, for one, will be very interested to read what you have to say, as well as to see how the list of implementations grows. That's because the best way to ensure that the documents of today can be opened tomorrow is for the largest number of applications possible to actually create documents (of all types) in one format. As the number of such documents explodes, so also will the vested interest and motivation increase of all stakeholders to maintain and use that format forward into the future.
For further blog entries on here , click