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 , click here
subscribe to the free Consortium Standards Bulletin
It feels to me that there are 2 different markets.
Salesmen need to be able to produce a flashy presentation; after the sales pitch, it can go in the trash. (Like this week’s newspapers get used for wrapping next week’s fish and chips). They like Microsoft PowerPoint, and its underlying ECMA-376 storage format.
Scientists need to be able to produce something which is accessible and modifiable ‘for ever’. They like OpenOffice Impress (or IBM Lotus Symphony Presentations), and its underlying ISO ODF XML storage format.
In between, there’s a spectrum (Scientist, Engineer, Government, Secretary, Salesman) of users.
If you appreciate this, you can sell the right product (or service) to the right person. If you get it wrong, the customer doesn’t want to buy what you are selling, and goes elsewhere.
Now, personally, I don’t think there is any point in ISO issuing a standard for ECMA-376. It doesn’t achieve any interoperability between vendors of ‘sales pitch production’ applications ; and which salesman needs interoperability between his sales pitch and his competitor’s sales pitch, anyway ?
How many times did you ask the salesman for a copy of his presentation? I am doing that all the time.
The salesman needs interoperability with his customer’s office software. If the customer is an engineer or government that want long term preservation, this is the software the salesman needs to use. You will find out that files in formats that have long time presentation properties can be discarded just fine when you need to. I just don’t see the point of multiple standards.
I’m not sure what world you live in, if you think that MS Office documents are essentially only for throwaway purposes, and that people like scientists turn to other solutions (like ODF) for documents which will last longer.
I speak as BOTH a businessman and a scientist. MS Office is used for both throwaway documents and for long-term documents, by both business and scientists. There are only a few major exceptions, e.g., the use of TeX-based documents in the fields of physics and math. The idea that MS Office documents cannot be long-term solutions is a bogus argument, but it is one that some people are concerned about (chiefly ODF proponents). However, it is a concern that has been addressed by the increasing XML support in MS Office over the last ten years, culminating in OOXML.
A couple of points are worth making. The first is that while Microsoft is addressing the preservation issues in part through releasing OOXML, the question remains whether this would have happened but for the ODF challenge. Microsoft says it would have done so, but there is no evidence in that direction of which I am aware to demonstrate this, and I have been told by those that work with Microsoft closely that this would not have happened but for ODF.
The second point is related: if the ODF challenge were to disappear today, what would Microsoft’s behavior be like in the future? Brian Jones, for example, has already said that if Ecma made changes to OOXML that Microsoft did not like, it might not implement them. Would this be more likely or less likely to occur if the challenge presented by ODF were to disappear?
The third and final point I’d make is that I, for one, would like to have choices in the software that I, like most non-technical people, use more than any other software – my office suite. Developing a good office suite takes a huge investment in time and money, and one that no one is likely to make if they are not likely to be able to sell it. Where the market is already locked up – and locked in – by one vendor, we will only ever have the products that this single vendor chooses to offer us, at whatever price it chooses to offer. I believe that OOXML shows much less promise and capability of leading to such competition and choice than does ODF.
– Andy
You ask whether MS would have created OOXML in a world without ODF. That’s a hypothetical question, but worth considering. So here’s my take.
Yes, it would most definitely have done so. If you look at the trajectory of increasing support for XML technologies in MS Office, you will see pretty much a straight line going back a decade. Put another way, MS’s creation of the OOXML file format for Office 2007 was completely predictable, given the past trend.
However, the question of whether it would have immediately submitted it for standardization ny the ECMA and then subsequently by the ISO is the REAL question.
My take is that it would have done it eventually (maybe a couple of years after Office 2007?), but it would have. That schedule would have been in line with the timetable for other MS technologies they have submitted to the standards process (C#, the CLI of .NET, etc.). The specific reason is what has been said elsewhere, by MS as well as others — that governments prefer standardized solutions over proprietary ones, all other things being equal. Governments are an important customer for MS.
Yes, I could see that being a possible schedule and outcome. While comparing to the past, do you think that the ultimate result would have been successful, or aborted (as was the case with C#) if one assumed submission of OOXML in the same form as presented by Ecma, but with the same level of response as C# experienced, as compared to the much wider and more spiritied reponse to OOXML in the current context, following the approval of ODF?
– Andy
Hmmm, you’re adding hypotheticals on top of hypotheticals here. So, I’d better keep my speculation pretty brief. All I can say is that if MS had waited for SP1 or SP2 of Office 2007 to submit OOXML to the ECMA, it would have had a lot more experience with the format under its belt. As a result, once it then emerged after 18 months at ECMA (which is the actual length of time it really took), you would have had a somewhat better standard. Certainly none of the minor irritants that provide so much ammunition for its enenies would have been present. I would expect, however, that the "lively" level of interest would have remained, because it my mind it is driven primarily by competitive reasons and not really by the technical aspects of OOXML.
Anyway, I don’t think I can contribute much more to the hypothetical, non-ODFworld discussion.
By the way, I’m the same anonymous as in the other active subthread. I just haven’t gotten around to registering.
Again, I think this makes sense. I think the only point on which I’d differ is that if ODF didn’t exist, there wouldn’t be anywhere near as much opposition. If ODF didn’t exist, then I think most people would think (like government users) that the world is better off with OOXML being open, visible and available than it was before. But that wouldn’t be because it solved the long term accessibility issue decisively (although it would have incremental value in that department as well).
With ODF already out there, though, *many* more people, and from many other areas, got involved than have perhaps ever gotten involved on a standards issue before. That’s because many people (myself included) think that an ISO/IEC JTC1 adopted OOXML will undercut uptake of ODF, which will undermine solving the accessbility of documents lssue. As I’ve written elsewhere before, I don’t think that opening up OOXML in and of itself isn’t a bad thing.
I think that having ODF out there also changed how IBM, Sun, Google and others reacted. They each have many, many irons in the fire all the time, and allocate their resources in part based on how successful any individual initiative might be. If ODF hadn’t been adopted by Massachusetts, thereby getting lots of publicity, community support, blogger attention and so on, I don’t think you would have seen any of these vendors get on the bandwagon to anywhere near the same extent. It was the greater likelihood of success that spurred them on. So if ODF didn’t exist, how hard would they have opposed OOXML adoption as a standard? I doubt there would have been much of an effort at all.
Thanks again for your thoughts.
– Andy
I am a different anonymous than the parent.
Would Microsoft have created OOXML without ODF pressure? The answer is they did. XML was in their roadmap for a long time and I am sure they needed OOXML to help them build Sharepoint and all the automated workflows this platform supports. The development of Office 2007 was started well before ODF got the traction that came from the Massachusetts open standard policy.
Would Microsoft have submitted OOXML to ECMA or ISO without ODF? the answer is they waited until they were in hot water in Massachusetts and then rushed the standardization process.
Well, indeed, Microsoft Office does get used by scientists and engineers for documents which are intended to be long-lived.
But if you send such a document to a non-Microsoft-Windows system, the recipient will be unable to view it or to collaborate on its revision. And there are plenty of non-Microsoft-Windows systems around; Sony Playstation 3, for example.
That should set off some alarm bells in terms of who is controlling access to the information in the document; and how long it will be before the document crumbles to unreadable ‘digital dust’
ISO26300 would be better for the scientists and engineers.
Hi Andy,
I had an interesting chat with a friend of mine a few weeks ago that went something like this:
He: "We actually use OOXML to save our data, what’s the problem?"
Me: "What do you mean by that? Did you actually write a piece of code that saves your data in the OOXML format and read it back or do you just use Microsoft’s DLL?"
He: "Oh, we use their DDL"
Me: "So you don’t really see the OOXML and you don’t care whether it’s OOXML or anything else, right?"
He: "Yes, I guess that’s true."
Me: "So, for that matter, it could be their old binary format or any other format."
He: "Indeed."
I’m willing to bet a lot of the so called "OOXML implementations" are just like my friend’s. They aren’t really OOXML implementations. They are merely Windows-only applications that use Microsoft’s implementation. In my friend’s case they don’t even use OOXML to exchange data with any other applications, they simply use it as a way to store data because Microsoft made it convenient to do so.
Arnaud Le Hors
Thanks for the useful observation. It would be very interesting indeed if a list could be compiled that gave real insight into what each implementation is really all about. Otherwise, it’s much too easy to just throw numbers around, that in fact mean little at all.
– Andy
A bit of a flaw in the reference to Bluetooth and Wifi though. The roles you say they ended up doing were actually the roles that they were designed for. Wifi was always a wireless networking swap in for ethernet and BT was always intended to be for short range "personal area networking".
My clear recollection of the marketing claims of the time is that the Bluetooth was supposed to have a c. 30 foot reach, and was being promoted in the beginning as the solution for (for example) a wireless home office, with your laptop. printer, computer and so on all wireless linked – the same vision that was promoted for WiFi, before the products actually started to move out into the marketplace and see what people wanted to buy, and how they wanted to use what they bought.
With time, WiFi manufacturers took advantage of a number of differences between the two technologies, including the fact that you could be farther than 30 feet away from your router, while Bluetooth took less advantage of its nominal (or at least originally claimed) reach, and became used mostly for much shorter range communication.
My point is also that the early claims and hype about what a standard can be used for eventually fall to realities. When that happens, it’s interesting to compare the initial claims between competing camps with the wisdom (or at least the choices) of the marketplace.
– Andy
This is essential correct about WiFi and Bluetooth. They have two different design intents, as described. (I am CEO of a company that is making Wi-Fi equipment with a range of 10 to 15 km.)
The real analogy is with OOXML and ODF. MS has always said they have different design intents, and they do.
Let us make the specific analogies Wi-FI <–> OOXML and ODF<–>Bluetooth.
ODF is for people and organizations who want to use or interwork with OpenOffice and a very short list of other open source applications. (That;’s pretty limited, which is why I chose to make it analagous to the very short-range Bluetooth.)
OOXML has a potentially much wider reach (which is why it should be thought of as analogous to Wi-Fi). It is for people for want to do one of several things:
– Use MS Office as a normal user
– Interwork with MS Office (as a set of applications), programatically, using files in OOXML as part of the data interchange. This is the so-called "Line of Business" application approach, and since it is internal to large organizations, you will not hear much about this. (The use of OOXML as an archive format comes in here)
– Create new LOB applications that don’t even touch MS Office, and use OOXML as one of the file interchange formats. (The use of OOXML as an archive format comes in here too)
– Use 3rd party applications, e.g., other office suites, that read and/or write OOXML formats intended to be read at some point by MS Office.
– Use 3rd party applications that use OOXML as a convenient and powerful interchange format for numbers, words, and diagrams.
Note that these are all valid "implementations" of OOXML, which was purposly and explicitly designed so that an application does not need to implement 100% of what’s in the spec to be counted as a conforming application. Also note that the potential use to create a MS Office clone is not listed above. That potential use was thought up only by OOXML opponents (as in the idea that the spec is so complex that only MS could implement it), who then went on to believe the propaganda they had written.
There are a number of things I’d disagree with you on here, but the principle one is that I think that there would be very few people who would agree with you that the principle reason why anyone implements ODF is to interoperate with OpenOffice. I think it would be difficult to substantiate your conclusion, and would be hard pressed to see in the business cases for any of the open source implementations any evidence of that goal. Clearly StarOffice and IBM’s implementation are based on OpenOffice, but I think that it would again be difficult to substantiate that IBM’s implementations are intended primarily to interoperate with OpenOffice, as compared to take more market share away from Office.
– Andy
For "OpenOffice" in my comment, replace with OpenOffice and its clones and derivatives. Sorry about not being more specific.
ODF’s purpose is create a new "ecosystem" (to use MS-speak) centered on OpenOffice and its clones (but including other applications), which will, in ODF supporters’ hopes and minds, take away some market share from MS Office. That’s what I meant, put in more detail. In my opinion, they have no hope of succeeding, for two reasons: 1) Their ecosystem is centered around an office suite that is far less capable than MS Office; and 2) They have decided that they want nothing to do with the market leader MS Office, and so will neither "build bridges" (to use another MS phrase in this war) nor will they cross over any that MS might build. Put another way, they are dooming themselves to irrelevancy by their own self-centered attitudes. To succeed at least a bit, they need to stop their current strategy of trying to get governments to mandate their solution, and instead start listening to their customers (something that the MS Office team does a fairly good job at).
As for your comments that there are lots of other things I wrote that you would disagree with, I’d like to hear them. To me, what I wrote was pretty obvious and in accord with well-known facts.
I fail to see how an open standard adopted by ISO could have the purpose of interoperating with a single one of its implementations not matter how prominent it is. This is neither obvious nor a well known fact. On the contrary the falsity of such a proposition should be obvious and well known.
The purpose of a standard includes among other things to support multiple implementations and make sure the ability to implement it is not under the control of a single vendor. Koffice and Google documents come to mind. Collaborative suites like Lotus Notes and Alfresco also count.
Part of the problems with OOXML is they try to get ISO to rubber stamp a specification whose stated purpose is to interoperate with Microsoft Office without relinquishing the single vendor control (although they pretend to do so). Please do not project this Microsoft thing into ODF. Such a goal in my opinion should be incompatible with ISO standardiZation.
Wow – now I really have a lot to disagree with you on. I’ll try and cover the ground briefly:
You say: ODF’s purpose is create a new "ecosystem" (to use MS-speak) centered on OpenOffice and its clones (but including other applications), which will, in ODF supporters’ hopes and minds, take away some market share from MS Office. That’s what I meant, put in more detail.
>>I’d mostly agree with you this far, with the quibble that this speaks for the vendors, but not for the many individuals that believe that document accessibility, competition, innovation and choice are what this is really all about.
You say: In my opinion, they have no hope of succeeding, for two reasons: 1) Their ecosystem is centered around an office suite that is far less capable than MS Office;
>>Three thoughts for you: first, I’d insert "less capable to date," to underline that with IBM joining OOo this will become less so. And also, ODF compliant products that are Web-based may be superior for certain purposes and users than Office. Third, ODF-compliant products don’t have to replace Office, just be successful. Today there are 6 billion people in the world, and 400 million Office users. The same sort of situation helped Microsoft wipe out Netscape with IE.
I don’t think it’s reasonable to assume that a third world user, or a government agency in Brazil, will find OpenOffice, Star Office, Google or IBM to necessarily be not worth considering for new desktops in particular, given the price differential, ability to work with the code, etc. And remember that MS targets the enterprise, and not the SME or the individual user. That type of user has more of a mind of its/his/her own, and often less need to trade documents with the rest of the world. You’d be surprised at the email I’ve received from SMEs that are already switching over.
You say: and 2) They have decided that they want nothing to do with the market leader MS Office, and so will neither "build bridges" (to use another MS phrase in this war) nor will they cross over any that MS might build. Put another way, they are dooming themselves to irrelevancy by their own self-centered attitudes.
>>Couldn’t disagree with you more. They tried to get Microsoft to join, or even cooperate with the ODF Working Group at OASIS. No dice. They tried to get Microsoft to support ODF. No dice. Have you tried to open an Office document with OpenOffice? Hey, it works great. Have you heard any statements by anyone on the ODF side about merging the two formats? I have – many – they’ve all said "we’re up for it." Microsoft? No dice.
You say: To succeed at least a bit, they need to stop their current strategy of trying to get governments to mandate their solution, and instead start listening to their customers (something that the MS Office team does a fairly good job at).
>>We’re talking about pretty small development teams here, to start with. Second, it seems to me that OpenOffice is a pretty effective clone of Office from a look and feel point of view, so if OOo isn’t listening to the customer, then Microsoft isn’t, either. So so I’m not sure that I take your point.
– Andy
Hi,
I think the questions asked are good starting questions. But we are talking about a standard, not just a file format. Let me first add a couple comments on your post, and then help clarify a bit.
When Gnumeric’s Jody Goldberg claims "support for OOXML", this is an abuse of language. What Jody demonstrates, given Gnumeric’s actual source code (Jody should be commended for letting everyone see it) is that it takes little time to do trivial things. Indeed. It does not support much. At the time of writing, Gnumeric can’t write fonts and other formatting styles. For the reading part, even worse, it does not read the theme part, which is part of every single document created by Office 2007. Add to this that Gnumeric has a ten year work worth start as a project, so it does not tell anything for those vendors starting now from scratch.
For Datawatch, it’s even better. This thing limits itself to numbers. Spreadsheet are more than numbers. I guess Datawatch could just equally claim to support SAP databases, if it limits itself to just extracting numbers, knowing that SAP databases is more than that. So to Datawatch’s Monarch, OOXML is just a CSV file expressed with angle brackets, not a real, instantiated, Office 2007 document.
As for Novell’s support for OOXML, actually you are a bit generous. What Novell’s Michael Meeks did was to bootstrap CleverAge’s doc converter so that it would load Mono instead of .NET. But other than that, the conversion is what the Microsoft sponsored CleverAge has to offer. Which means not that much. We know trivial Word documents won’t convert. We know there is no claim of supporting round-trip scenarios, and so on.
OpenOffice itself is adding some support to OOXML. OpenOffice 3.0 (roadmap : fall 2008) is expected to provide some level of support of OOXML for both reading and writing, but at the speed they are doing it, I am afraid there won’t be any support for any of the new stuff : theming, fancy charting, perhaps even the one million row mode, "custom XML". Any subtantial support may not appear until OpenOffice 4.0 (2010, 2011 ?)
I can go on like this with every single product being listed. In short, technically speaking, there is not much support. Those guys should be embarassed being listed, if they had any kind of ethics. It’s so ironic to see another "open source" guy, Jody Goldberg, join the rank of Microsoft’s best supporters, after Miguel De Microsoft. As if Microsoft was really opening up.
Now if we get into proper standards context, it should be reminded that "supports" does not mean much. If the XML vocabulary is not strictly normative, anyone will be supporting XML stuff with their own interpretation of said stuff. Leading to absolutely no interoperability. In this world of no interoperability, Microsoft thrives thanks to their market forces. To provide interoperability across documents, applications and platforms, there are two ways : 1) real interoperability (actual work) 2) a single document/application/platform in the ecosystem therefore no interoperability problem anymore.
In addition to this, a standards paper defines conformance clauses. ECMA 376 makes it very clear that it does not guarantee any kind of conformance between syntax and semantics. This contradicts what XML is for (agreed-upon syntax and semantics).
What speaks beyond pale about ECMA 376 is that Microsoft can’t actually write a damn standards paper.
-Stephane Rodriguez
Independent software vendor, file format expert
I wrote the "OOXML is defective by design" article
I’m wondering if the following post and it’s parent post are an accurate depiction of OOXML?
http://www.groklaw.net/comment.php?mode=display&sid=20070910110639612&title=OOXML+brittle+for+business+reasons%3F&type=article&order=&hideanonymous=0&pid=625256#c625276
I took someone else’s analogy and ran with it. I haven’t personally looked at the OOXML spec.
I wrote the original analogy and I haven’t read the spec either, so let’s not run with it too fast 🙂
The analogy given at Groklaw seems like a good discussion of the theoretical issues around stream- vs. tree-based formats, but I’ve not seen anyone demonstrate that OOXML has undocumented elements that affect the overall structure of a document. Also, since writing my earlier post, I’ve learnt that ODF isn’t purely tree-based and OOXML isn’t purely stream-based — for example, ODF marks tracked changes as <text:change-start/>…<text:change-end/> and OOXML stores spreadsheets with values nested within columns nested within rows. I certainly agree that a hierarchy helps to contain problems with a document by localising the effect of any given element, and that hierarches are easier to reconstruct because of their redundancy, although until we know what the new formats will be used for, we can’t really say how useful these properties will turn out to be.
Although I’ve not seen anyone demonstrate OOXML having undocumented structural elements, some day there might well be an OOXML 2.0 specification, and it’s worth imagining what that might look like. It strikes me as much easier to extend a specification if features are contained within a sub-tree rather than affecting an arbitrary length of text, because programs that only support version 1 can just ignore sub-trees they don’t recognise. Incidentally, I also worry that OOXML’s reliance on narrow features will be a maintenance nightmare — can you imagine getting 100 delegates together to discuss how many pictures of the globe are sufficient to make art borders truly international?
With respect, it’s kind of unproductive to suggest this is an attempt by Microsoft to obfuscate their format — everyone that hates Microsoft will agree with such a suggestion, everyone that doesn’t will disagree, and the gulf between the two camps will get a little bit wider. If you want to change the minds of people that disagree with you, it’s better to find out what your opponents are saying and take their argument apart. Most minds that are likely to change belong to lurkers attracted to the logic of an argument, even if the argument happens to be made by somebody acting in bad faith. These floating voters therefore tend be swayed more by counter-logic than personal attacks.
In the case of OOXML, Microsoft’s basic argument seems to be that the only way to be certain that OOXML is as compatible as possible with older formats is to make it as similar as possible to older formats. I think their reasoning is that logical arguments are all well and good, but when you want to be really sure, you want to base your work on all the evidence you can get.
– Andrew
[I didn’t realize until a couple of days back that someone had replied. This is why I took so long.]
I think you are failing to recognize (if the description of the majority of OOXML being "stream-based" as compared to ODF is accurate) that regardless of the intentions of Microsoft, there is reason to be wary that such a file format is more brittle. This poses problems for everyone. Further, it is an opportunity waiting for exploitation. In particular, an entity controlling large market share is given the opportunities to fairly indiscreetly thwart would-be competitors. These are weak qualities of the format that exist without even considering who might be playing the role of spoiler. At this point, it would be a further mistake to ignore Microsoft’s past and the fact that OOXML makes it easy for them to hurt the competition. "We weren’t trying to hurt anyone. It’s just that the format is brittle."
So as not to speak about vague theories or hypotheticals, someone should go ahead and do statistical analysis of samples of similar material encoded in the two formats.
Of course, Microsoft likely put OOXML out because they are not going to follow that standard from here on out [here is where I fail miserably to "reach out across the isle" as it were; guilty as charged]. Look at ECMA spec 234 that was published in 1995 just as Microsoft was moving on to "bigger n better" things. I think it makes business sense for Microsoft to prefer that open-spec motivated developers that would otherwise be helping some open spec based competitors instead spend their time working on Microsoft protocols that Microsoft can afford to open because they will no longer depend on these for significant future revenues. The significant revenues would come from the secret sauces not revealed in the specs (their "value add").
(Likewise, apologies for taking a while to reply)
I agree that OOXML’s brittleness is a concern for the future. Microsoft don’t need to act in bad faith to cause everybody problems, they just need to be careless a couple of times and people will go back to the "MS Office is the only way to guarantee compatibility" reasoning that used to make sense in the 90’s. However, that would still be true if they adopted ODF – so long as consumers deal with uncertainty by assuming that Microsoft is always right, they’ll always be the 800lb gorilla.
As to statistics – a statistical argument is a lot of work for little reward. Thinking up a good statistical model takes time, then you publish your results, it gets picked to bits by everyone, and you start again with a new model that takes all the criticisms into account. It would be a great learning experience though, and formal training would only buy you a few less rounds of criticism, so I look forward to telling you all the things wrong with your first model 🙂
– Andrew
>> However, that would still be true if they adopted ODF
An analogy: If you turn on a TV (Openoffice) and get a degraded picture with certain channels (MS Office ODF docs) but you can at least usually make out what is going on, and you can see the other channels well, will you necessarily switch TVs across the board to the alternative (MS Office) that is very very expensive in comparison and that locks you in? Might you not buy a few licenses for the alternative but mostly employ the much cheaper model that gives degraded performance when you view a particular type of channel (MSOffice docs) but works fine in other circumstances?
Now what if the first type of TV could make out nothing of channels that you could not afford to miss completely? Meanwhile the more expensive TV did a reasonable job with all channels. Wouldn’t you likely switch almost entirely to the second type of TV despite higher costs and lock-in?
That is the difference. It’s a matter of degree. It seems to me that OOXML makes it much more likely than ODF to have accidental or intentional errors lead to unusable documents. In that case, you have to go with the one that works. But if you use ODF, you can alocate resources to competing products in order to gain the perceived benefits of both. In other words, OOXML is much more damaging to Microsoft competitors than is ODF no matter how Microsoft employs it. While in the past a little incompatibility was enough to sink a commercial competitor, that has proven to be ineffective against FOSS apps like Openoffice. Microsoft would be in a much better position to hold their monopolies against FOSS if their standard is used instead of ODF.
Even putting Microsoft aside, why pick a standard that increases the chances of serious incompatibilities even among vendors trying to implement the standard faithfully and cooperate?
[This thread reminds me of a tennis match where each return sends the ball higher into the air, taking longer to reach the ground. Maybe I’ll be able to return the next volley before Spring.]
Long time, no see!
I’d assumed this thread went dead when it dropped off the bottom of the front page. I’ll try to make an effort to check it once a week from now on. We’re moving beyond the reaches of my understanding though, so my answers are going to be quite vague.
Firstly, my previous post wasn’t meant to reflect my personal feelings about how the world should work (which I’ve yet to settle on an opinion about), but rather my understanding of the way the world actually works. If we lived in a world where all organisations were competent and willing to dive into a codebase at the first sign of trouble, we’d have bigger issues to discuss than office formats 🙂
For businesses, saying “oops, we misread that document, better luck next time, eh?” to a client is extremely rude, and sends the message that they’re not really interested in providing good service. Moreover, it costs both parties time (and therefore money) if documents have to be manually reformatted whenever they’re moved between organisations. Using two different software packages inside an organisation is even worse, as it incurs all the above problems, plus double the training costs. My point is that the relative costs of different packages go far beyond just licensing costs, and touch on things (like reputation) which matter a great deal more to companies than a healthy computer market.
I certainly don’t think these problems are intractable from a technical perspective, but I get the impression that non-technical people measure non-Microsoft software in terms of how compatible it is with the “standard” Microsoft equivalent. However logical the arguments you and I make in this thread about what people ought to do, the industry will always have to dance to Microsoft’s tune so long as that perception is the norm.
– Andrew
It is actually very important that you with OOXML distinguish what exactly in the OOXML that is used, else you end with situations like Gnumetric that are claimed to implement ooxml even while it by no means can consume arbitrary ooxml excel files correctly.
For a application to produce OOXML compatible data is not that difficult. Some bits of ooxml are poorly defined and lots lack proper specification, yet the bulk of the required dataformat is xml and if you don’t have a good test suite you can claim you implemention it correct after reasonable work.
The opposite is not true for the application when it should read OOXML data. To read OOXML output from a application that only uses the recomended xml format is pretty straightforward since it is the reverse processed used to create file. Unfortunately Microsoft Office is not such application that only use these defined parts. OOXML allow adding deprecated data into the file and does explicitly avoid explaining how this data is to be read or give any legal protection for somebody that reverse engineer the dataformat to work around this flaw.
What this all boils down to that applications can both support every required part of OOXML and still be unable to open any document produced my microsoft office since microsoft with the ooxml standard are allowed to, and probably will continue to, keep the legacy data inside the ooxml file.
The correct questions to ask to anyone claiming to be compatible with OOXML are:
*Does your application support reading and writing all the required parts of OOXML?
*Does your application generate data that is depracted but allow by the OOXML standard?
*Can your application correctly handle legacy data (things that deprecated) that legally can exist in the OOXML file?
If the answer is no to any of these questions the application is pretty worthless as evidence since it does not include the parts that are critical for the user.
The sooner OOXML gets a standard suite of test cases to check compliance the better. Then it can be presented to each application that claims support and we can see how many tests work, or fail, and get a percentage compliance figure for the application, rather then simply trusting the vendor. How does this sort of thing get written? – giafly
The issues with Test suites are several, and include:
– Who’s going to pay to create it (up to $1 million in development fees)
– Who’s going to run the tests – the ISV, for his own benefit? A third party, for greater creditility?
For Microsoft, this wouldn’t be a big deal, as they clearly could pay for it. For most standards bodies, its more of a problem. You can read a lot more about certification programs, branding, and paying the bills at this section of the site.
– Andy