Hey, let’s start talking about the technologies and what kind of solutions we can build!

There were a few interesting articles I saw this week that I wanted to point people at.


"… if government locks in winners and losers, manufacturers will focus on courting government, rather than innovating. The recent technology policy debate in Massachusetts offers a case in point. In September 2005, after lobbying by IBM, Sun Microsystems and others, the state's Information Technology Division (ITD) announced that all government agencies must convert to computer systems that use OpenDocument file formats, an alternative to the Microsoft Office formats."

I thought that was a really interesting read. There aren't a lot of articles looking at the issue from this side. Let's allow people to choose the formats they want. I'm not sure anyone is opposed to choice. I don't know about you guys, but (like I said in the blog title) I'm looking forward to more discussion around the technologies instead of the policies.


"…we will be setting the precedence for a future where instead of fighting for market share with features, we will instead be fighting with favors to politicians, lobbyists, and/or any other source of so called advantage we think we can possibly gain through the legal channels, spending all of our development resources on these same mentioned channels, instead of putting that money into the development of the products themselves.

Whether anyone on the ODF side is willing to admit it or not, this isn't about document formats."

I'm hoping that with communities popping up like OpenXMLDeveloper.org, we'll start to see more and more folks talking about the technologies themselves and the awesome stuff you can do with XML. I want the discussions to be more around building solutions and innovating on top of these formats. I want to hear from folks about what they want to do with the formats. What kind of solutions are people building? Let's start sharing these ideas.


"But when I asked Sun's engineers point blank if they had verified my numbers, they stated that they do not dispute the numbers and immediately proceeded to explain why it was slower than Microsoft's format. The reason Sun explained was that Sun has to use the open standards OASIS compressed XML format while Microsoft used its own proprietary binary file format which was essentially a very efficient memory dump that didn't require a lot of CPU cycles to process (approximately 95 times more cycles based on my tests). But then I pointed out that even when I tested Microsoft Office with its own 2003 XML format plus the time it took to compress the data, it was still approximately 5 times faster than OpenOffice.org. Sun's engineers explained that this was due to the fact that ODF took longer to process than Microsoft's XML format. At this point in the conversation, they've managed to convince me that the OpenDocument format was 5 to 100 times less efficient."

From our point of view, the move to XML formats was actually a scary one since the old binary formats for Excel were so damned fast. That's why we had to look really closely at every aspect of the SpreadsheetML design to see where we could make the load times faster. As I've said before, most end users don't care about XML, they just care about their files working. It was up to us to make sure that we can give the developers out there XML without having a negative impact on the end user.

I'm not sure if it's good blog policy to post on a Friday afternoon. Have a great weekend everyone. I hope you're doing something fun, and aren't stuck reading my blog (at least until Monday)!


Comments (36)

  1. Hi Brian,

    This is a fantastic follow-up!  I agree… this is about what XML can in regards to sharing new ideas, developing new technologies, and enjoying a life full of freedoms instead of mandates.

    One area that I think you might find interesting as it extends directly from the LiveClipboard project, (see: http://www.oreillynet.com/xml/blog/2006/04/msliveclipboard_as_promised_re.html for more information in regards to the community involvement thus far in regards to this project) can be found @ http://dev.extensibleforge.net/wiki/GlobalClip … I am just wrapping up the final interface pieces for the ASP.NET-based demo, of which you can found located @ http://extf.net

    There are some particular areas of interest that I believe you will find of direct relation to your efforts as part of the Office team.  It’s a range of things, but they all stem around the area of sharing content, and ensuring that the proper meta-data in regards to the contents original location, author, licensing terms, etc… comes along for the "LiveClipboard ride" and stays with this content as it passes through any particular document work-flow.  Of particular interest is the people in whom I have been working with in this regards.  However this is something that at present time would need to be discussed in private email for various reasons, none-of-which are of major concern, and more about just being mindful of the privacy of others until such time as they make their own decision to attach themselves publicly to a project.

    One of the folks that I can mention is Bruce D’Arcus [Amazon:http://www.amazon.com/gp/product/0415948738/qid=1147499103/sr=2-1/ref=pd_bbs_b_2_1/103-6286779-4135039?s=books&v=glance&n=283155, Blog:http://netapps.muohio.edu/blogs/darcusb/darcusb/], someone in whom you may already know by name, but if not, can quickly gain access to information regarding why working with Bruce in various areas would allow for many wonderful things to take place.

    In fact, he and I were just chatting about the necessary steps to begin working with the Office team more effectively (his comments are here > http://www.oreillynet.com/xml/blog/2006/05/debunking_the_odf_bunk.html#comment-30377 and my follow-up two comments down… Please ignore my attempt at humor in the last sentence… I promise, I’m completely harmless 😀

    I see there is a contact form linked above.  I will get in touch with Bruce this weekend, and then contact you through this contact areadurring the  first part of next week.

    Thanks again for some GREAT follow-up to the various pieces covering this topic! 😀

  2. Adam says:

    Choice of data formats is a completely different kettle of fish from choice in implementation/encoder/decoder, and IMO, to try to claim that the benfits from choice in one area are applicable to choice in the other is, IMO, either intentionally misleading, or short-sighted and indicative of a lack of though on the subject.

    Who benefitted from the choice between ASCII and EBCDIC? Not customers. They just get files that can be read on one system but not another.

    Who benefitted from the choice between Beta-Max and VHS. Not customers. If they had tapes in one format, they were incapable of playing on another.

    Who benefits from the choice beween PAL and NTSC? Not customers. Their VHS videos don’t play anymore when they cross the atlantic.

    Who benefits from the choice between incompatible network protocols (say, TCP/IP and IPX)? Not customers who just want all their systems to be able to talk to each other. It’s all just a network, right?

    Ditto Blu-Ray/HDDVD.

    Note that with most of these choices, it wouldn’t have actually mattered that much to most people which one actually "won". The important thing, the thing that totally prevents "governments locking in winners and losers" is that anyone – anyone – can implement whichever one does win.

    Anyone can implement a text edtior that works with ASCII or EBCDIC, and many people have. By standardising on one of those formats – by *removing* choice in terms of what formats can be used – a government can ensure that no matter which technology is used to actually create text files, be that Notepad, Visual studio, vi, emacs, jed, ultraedit, etc…, all can read and write any of the data read or written by any of the others. And no-one, *ever*, has to worry about needing to transform their data from one format to another once the choice has been made.

    On top of picking a single standard, ensuring that that standard is clearly-defined, available to everyone, and which *anyone* can implement readers and writers for, without needing to talk to anyone, without needing to get any kind of permission, without needing to make any kind of payment, without needing (god forbid) to worry about any kind of legal action, lowers the barrier to entry for, and therefore *encourages* alternative implementations to spring up. A low barrier to entry and an atmosphere of encouraging alternative implementations just invites people to try new things out – to innovate – in the application space.

    All this gives the governemt, and all the people the government needs to trade information with, a completely open choice of *which* technology/editor to use, and allows them to change their mind at any point in the future if their original vendor goes bust/breaks the law/doesn’t live up to SLAs, without *ever* being locked into a single solution, or being beholden to *anyone*.

    Ditto VHS. VHS is a pretty open standard. If a governemnt sometime in the ’80s felt the need to standardise on VHS as a format for storing videos, they’d have a completely open choice of vendors for recording, editing and playback equipment. By making that choice, instead of needing to have twice as much kit to interoperate with both VHS and BetaMax, and instead of pretty much requiring everyone they do business with to do the same, picking a standard allows everyone to exchange data without needing to worry about what format that data is in, while at the same time encouraging _all_ vendors to work on editors for the same standard, instead of splitting their efforts.

    One of the interesting lessons to learn about the VHS v BetaMax format war is that it often doesn’t matter which format is technically better than the other, provided they both get the basics done. What matters is that you *pick one*. And being more open generally helps here.

    Ditto all the others. Choice in data formats is *not* a good thing. It never helps the people whose data is in *one* of those formats.

    And ditto to office document formats. Standardising on a single, open, document format that *anyone*, including Microsoft, including Richard Stallman, and including everyone in between, can write an editor for and distribute under whatever terms they wish is a good thing. The whole point of an open format is to not lock anyone, *ever*, into any vendor. That means not locking governments into StarOffice/OpenOffice.org as much as it means not locking governments into Microsoft Office. That’s what an open document format can do.

    And that’s why this is *completely* about document formats.

    As for choosing between ODF and MOOX? I’m with ODF.

    MOOX is being fast-tracked through a standardisation process before even a single implementation has reached the market – I don’t think that that will help shake out any issues that might be lurking within.

    ODF is already a standard.

    There are already two independent, interoperable implmentations on the market (StarOffice/OpenOffice.org 2.0 and KOffice 1.5)

    There are many other implmentations already in progress.

    I don’t trust Microsoft.

    You said "I’m not sure anyone is opposed to choice." Well, for me it depends. It depends on the choices I’m given, and on whether the fact that that choice is available in the first place makes things worse than they would be if it didn’t exist.

    In the case of competing document formats, be absolutely sure that at least one person is opposed to choice. Me.

  3. Very interesting post.

    As XML is all about interoperability, I would really like to know how easy it is to convert ODF into MOOX and vice versa. I am sure you must have some idea, as you prob. looked closely at ODF while designing MOOX.

    Do you have any idea if this could be done without loosing any data?

    How difficult would it be for anyone to implement this?

    If this is doable, then someone out there is going to do it. Whoever does it, might even provide this in form of an ODF file format capability for MS Office 2007.

    Maybe even at this point in time, MS is working on implementing ODF for Office 2007 and will whip it out as surprise like the blogging feature. If ODF in Office turns out to be 10 times slower than MOOX and supports only half the features, then we all can have a good laugh and use MOOX.

    Patrick Schmid

  4. Hey David, great to hear from you. I’ll look into those links and will look forward to hearing from you next week. I believe I’ve already had a couple conversations with Bruce via e-mail, and will have to go dig those up again.

    Adam, I’m not sure if you are aware, but there are more than just two document formats out there. RTF, HTML, DocBook, SpreadsheetML from Office XP, WordprocessingML from Office 2003, StarOffice’s XML format, original OpenDocument, OpenDocument from OASIS, Office Open XML, etc. etc. etc.

    I’m suprised to hear you have so much support for government regulation in this area. Which government body do you think should make the call? Local, state, federal? Do you think they should just mandate HTML since that has the most widespread use at this point? I’ve got to tell you, we already tried using HTML to represent Office documents, and it resulted in some pretty ugly HTML since there were so many features that Office supported but weren’t in the HTML standard (and features in HTML that Office didn’t support).

    I don’t mind if you think you’d rather use ODF over Open XML, that’s your call. There were talks earlier this week of an add-in to Office that will support ODF, so it sounds like you can even use Office if you want.


  5. Hey Patrick, I’ve seen a couple different projects out there that are working on doing just that. There was an announcement last week that the OpenDocument fellowship, foundation, or alliance (can’t remember) has built an add-in to Office that will support opening and saving files in ODF. Also, the other way around, the Novell folks have already started experimenting with supporting Open XML in Gnumeric and OpenOffice.

    I don’t think it can be done without losing data unless you extended the format (not sure if pure extensions would work of if modifications would be necessary). ODF for example doesn’t specify how spreadsheet formulas should be represented so that’s an example of where there would need to be an extension.


  6. Adam says:

    RTF has had a history of being poorly documented in the past, and some incompatible implementations have sprung up as a result. Also, it uses Windows-specific codepage encodings instead of unicode for text, which it would be really nice not to have to support many years from now. HTML is unsuitable for modern office applications as it is way too simple, and specifically lacks the ability to embed foreign media, e.g. images directly in the document. XHTML and DocBook might be suitable, as XML namespaces could be used to embed media, such as images, as base-64 (or base-32768 for utf-16 documents) encoded blobs in foreign elements. However, the set of XHTML elements is quite limited, and would almost certainly need extending significantly, so you might as well not bother. On top of that, embedding images in the way I described would not be very space efficient, I’d not really advise that anyway.

    Using Docbook + other objects as separate files in a .jar archive certainly sounds like it might work, but no-one’s suggested it seriously so far, so I guess it probably lacks something. *shrug*.

    If we’re talking about file formats for office applications, specifically word-processing apps, that will be used for long-term interchange, storage and archival purposes, then the two formats that appear to have the most support so far are MOOX and ODF. Yes, there are others, some of which I’ve heard of, and some I almost certainly haven’t, but no-one else is proposing them, and I personally have not made a serious study of them, so I can’t really comment on that too much.

    As for government regulation – that depends on what you mean. If I have implied that I think a government should pass a law mandating that all companies must use a specific format at all times, then that was unintended and I must apologies for being unclear.

    However, for a branch of the government _not_ to consider how it is going to store it’s _own_ data, and not to require others who deal with it to provide data to it in either that format or one that can be converted to that format, would be amazingly unwise.

    So, yes, I believe that goverment departments should "standardise on" – i.e. have a policy for – the document formats that they wish to use, in exactly the same what that a company deparment should also standardise on the tools and formats that it chooses to use. (I use the term "government deparments" above pretty loosely. I’m not sure where I’d draw the lines, but I don’t really know how governments organise things like IT policies. Whereever appropriate lines currently exist, and whereever offices/departments/agencies already have the ability to make their own IT policy, would probably be a good start.)

    And yes, these decisions should take into account as many factors as each group deems relevant. Including things like technical considerations (e.g. doc size, processing required), format control/ownership considerations, format documentation/interoperability, current adoption/marketshare, existence of accessiblity-enabled applications for the format, etc…, etc…, etc…. Some of these factors will undoubtably be more important than others to different groups of people, so I think this will take some time to sort itself out.

    As time goes on though, I expect this choice to become easier. Like EBCDIC and BetaMax before them, some of these technologies will end up losing out, and the people who backed them will have to convert their data across. Hopefully, if the losing formats are documented enough, this will be trivial and almost completely automatable. For those losing formats that are badly/incompletely documented (if at all), well, there might be some rough bumps. But you’d have had that problem with those formats anyway, eventually, and probably should have stayed away from them in the first place.

    We’re in for an interesting few years though. 🙂

    But I look forward to the day when we have a winner, when no-one really needs to give any though about what format they store their documents in, and when almost any device or application, made by any manufacturer or random group of hackers, can read _the document format_, in the same way they can all read plain ASCII text files today.

  7. Sean DALY says:

    Brian – I posted this on May 4th, but it never appeared, so I am reposting it. Thanks.


    The vendor-neutral OpenDocument Format has just been certified as an ISO standard (ISO/IEC 26300), which means that it is now the clear choice for reliable long-term archiving of editable electronic documents.

    Meanwhile, Microsoft seeks to promote its own XML standard as a better alternative.

    Unfortunately, your company has very real credibility problems on this subject:

    * Microsoft continues to refuse to add ODF support to the 73 other formats currently supported by Microsoft Office, although Jason Matusow of Microsoft did go so far as to state that Microsoft would not oppose the use of ODF by any organization. I should hope that such bullying would not be necessary to encourage adoption of your standard. Meanwhile, the number of members of the ODF Alliance has grown to 138 in the two months of its existence. So: When is ODF support coming to Microsoft Office?

    * The presentation made at the ECMA General Assembly at Nice last December 8th clearly identified the problems associated with old-style binary formats, yet Microsoft refuses to publish the specifications of these legacy formats – a step which would do more to unlock the data of "millions of users and their billions of documents" than any new XML format, since anyone could then develop read/write filters – assuming, that is, that Microsoft would not attack non-Microsoft developers for copyright or patent infringement. So: why do these previous formats remain closed? What is to be gained by keeping them secret, except to lock in users to Microsoft products?


    * Previous Microsoft pseudostandards such as RTF (Rich Text Format) and CSV (Comma-Separated Values) have been unstable — changing arbitrarily with each new version of Microsoft Office — and poorly documented — there has never been a Microsoft specification for CSV and it has been formalized as a MIME type only since last October thanks to the dedicated Yakov Shafranovich ( http://www.ietf.org/rfc/rfc4180.txt ). Why has Microsoft been so sloppy these past 15 years concerning the documentation of these two formats? How will the new XML format be any different? In other words, will the format be changed with each new version of Microsoft Office, or will it remain stable? Will it be obsolete 2, 10, 20, 50 years from now?

    * The licensing associated with the new Microsoft XML format is vague concerning the rights of developers to freely use it. Although Microsoft claims that it will renounce royalties and promises not to sue, the format remains encumbered because it is apparently illegal to transfer rights in the manner of the GNU General Public License. Why doesn’t Microsoft simply and explicitly indicate GNU GPL compatability?

    * Microsoft had every opportunity to participate in the OASIS ODF committee and indeed chose not to do so, despite the urgings and encouragements of industry pundits. Why not?

    * The "community" at openxmldeveloper.org is composed of Microsoft Certified Gold Partners, none of whom offer products which run in non-Microsoft environments and one of whom goes as far as saying that the Microsoft format will allow him to more effectively compete with open-source alternatives. Meanwhile, the ECMA TC45 committee work is already benefiting from Free Open Source Software contributors such as Jody Goldberg. When the subject is interoperability, isn’t it quite clear that FOSS is preferable to vendor-specific partners, since FOSS development is standards-based?


    * OpenOffice amongst others has filters to read and write Microsoft legacy binary formats; today, no Microsoft product can read or write ODF. If OpenOffice supports the new Microsoft XML format, doesn’t that mean OOo will offer richer, more flexible file conversion capabilities in comparison to Microsoft Office? And what about the other dozen ODF compliant applications including KOffice, Abiword, DocVert, Writely, etc. available today — does Microsoft really wish to keep Office inadequate in this regard?


    * The OpenDocument Foundation has announced the near-availability of an ODF plugin for Microsoft Word which will allow governments and businesses to easily save and load ODF files. Batch conversions to ODF will come next, easing automation of currently manual data interchange processes since ODF filter development only needs to be done once on each side of an exchange. As document creators regain control of their documents, will Microsoft try to hinder the efficient functioning of third-party ODF tools designed to work with Microsoft Word? Will Microsoft help developers to maintain functionality to the next version of Word, or will Microsoft prefer to try to break compatability in order to further its own XML standard?

    Thank you

    Sean DALY.

  8. Brian,

    I’m excited for what opportunities lay ahead.  I will certainly be in contact first thing Monday morning with extended demo details such as to give you plenty of space to look things through as is convenient to your schedule, and responding once you feel the time is right to do so.

    re: Bruce.  He mentioned in a recent follow-up email that he has been in contact, though no specific details as of yet.  He’s in South America until the first week of June as I have come to find out, so it seems that if we focus our communications around Bruce becoming more directly involved at or around that time (he will have some connection to the internet, and time to follow-up here and there, but from his comments it seems that it will be the first week of June before he will be available on a more consistent basis, and able to begin the management of any community-based development efforts that are synergistic with the internal development efforts around the areas of OpenXML-based extension projects.

    While I have the development experience, the ability to turn specs into their software equivalent, I also tend to be idea driven, and Bruce has both the knowledge of what needs to be done, as well as the ability to manage folks like me who can easily spend their day developing every new idea under the sun, and often do if not for someone like Bruce keeping things focused on the task at hand.

    Thats not to downplay my own abilities, and instead recognize where my proven strengths exists, and where my weaknesses can get in the way of progress if I’m not careful.  As such, Bruce is the man to make magic happen, for sure! 😀

    Thanks for the opportunity you’ve provided with this post, and for the enthusiastic follow-up!  Definitely looking forward to our conversations and moving forward into some exciting areas that hold potential for some exciting things to be made possible because of these efforts.  

  9. Adam,

    Are you a software developer?  My guess is no, but I will leave this question open as it intrigues me to think that someone who has actually sat down and written code before believes that ANY requirements that specifies limitations of expression is something that should be sought after via Government imposed mandates.

    If you would please, at the bottom of a recent > http://www.oreillynet.com/xml/blog/2006/05/maintaining_netneutrality_by_d_1.html < entry I made to my OReillyNet/XML.com blog (different from the ODF entry, this was from a day or two before) you will find both a quote and a link to a video of a recent Senate committee hearing meeting in which Senator Sununu, a Republican Junior Senator for New Hampshire and MIT grad, asks:

    > Do we need this mandate at all?

    The mandate is in regards to the Broadcast flag, of which I’ll assume you know the details about, and if not, are accessible via the same link on the mentioned entry above.

    Its one of the most inspiring segments of Government produced video you will ever watch and hear, although I’ll admit that the bar for inspiring segments from Senate Committee hearing meetings is not all that high to begin with.  So I guess you will need to place some trust in me when I suggest that you if you watch, listen, and truly take in all of the comments Senator Sununu has to state, it holds the potential to change the very foundation of your belief system that Government mandates are a good thing, desirable thing, instead of destructive to the very foundation of technology, extending directly from the core definition, reason for, and purpose of what technology is all about,


    Here’s a teaser:

    “The suggestion is that if we don’t do this, it will stifle creativity. Well…we have now an unprecedented wave of creativity and product and content development…new business models, and new methodologies for distributing this content. The history of government mandates is that it always restricts innovation…why would we think that this one special time, we’re going to impose a statutory government mandate on technology, and it will actually encourage innovation?”

  10. Adam,

    One additional comment regarding your comment that it *IS* about the document format.

    The thing that people seem to look over as if it has no direct significance is that document formats define containers in which to logically store data created by someone sitting in front of a computer, using an application capable of both providing the tools that a user can understand how to use, to then take the input and store it into a given document format that can be understood and rendered at a later date.

    However, the document format doesn’t spontaneously generate the contents of any given document, handing you the copyright as a result.  The copyright belongs to the content creator, not the container which holds this content.  As such, the value of any given document format is not the format itself, but the ability for this format to allow fast, efficient storage and retrieval of the contained content in a way that can logically be accessed, rendered, if necessary (and allowed by the original copyright holder) wriiten to, and then saved to ensure persistence of state.

    While I am a HUGE advocate of extensibility of application, and the ability to store the created content in a way that is specified in such a way that other applications can easily build in read/write support for this format, I really don’t care what the chosen internal format of any given specification might be, as long as I know how to extend from it, and/or read and write this format in such a way that allows other applications, regardless of what they might be, or who might develop them, the ability to read/write this same format, and do so with consistancy such that there is ZERO data loss from one read/write operation to the next.

    Abstraction of interface matters.  What happens underneath that abstraction?  I would rather not know to be honest, as to spend my time trying to read and understand the implementation details of eacg and every document format goes against the nature of progress.  If instead of building and extending from the work of prior years, we are required to understand each and every level of abstraction that takes place from the beginning to end of any given protocol and format stack, lets just all focus on Assembly, as it would be easier to just bite the bullet and get straight to the core, that it would be to make any sort of attempt of understanding every single layered extension that is designed to take away from the complexities underneath.

    I realize this digresses a bit from the focus of document formats, but my point is a simple one:  XML is a wonderful invention to ensure application and platform interoperability as well as took consistency.  This is progress.  My life is ALL about XML, so I assure you when I state that you reach a point in the technology stack where XML is no longer necessary, and in fact gets in the way as if you can’t eventually get down to the binary representation, using this binary representation for as long as this file remains on this machine, I truly both understand this and mean it.  XML is great for the purpose of interop and ease of extensibility.  Past this, XML is a beast of burden that belongs no where near the core of an application stack.

    Of course, the ability to take a binary format, serialize this to an interoperable XML syntax that any application can serialize back into the binary representation that it prefers most, to then serialize back into XML for transport to somewhere else, doing so without any loss in data integrity is what matters. As such, OpenXML and ODF are important formats to both understand and be enabled to implement support for.

    But enforcing upon the world that one format and one format only is how the world must interoperate suggests that its time to go and look up the definition of interoperate and the purpose of things being interoperable.

    Peace 🙂

  11. (note: there are other words mispelled, but ‘took consistency’ should read ‘tool consistency’ — Development tools (as in code editors, etc…) and XML were like two peas in a pod when they first met, and their relationship continues to blossom to this very day…

    I know they state there are no guarentees that ANY relationship will make it through to the end, but if anyone can do it, these two represent the couple with the brightest future and potential for long term persistence like no one else I’ve ever met. 😉

  12. Alex says:


    ODF does specify how formulas should be represented. What it doesn’t do is specify how to interpret them.

    That is, OpenXML and OpenDocument deal with formulas in the exact same way. If you want to understand OpenXML files, you need to know how Excel works, and ditto OpenDocument (though in that case it’s OpenOffice.org to some degree).

  13. Adam says:

    M.> "[…] it intrigues me to think that [a coder] believes that ANY requirements that specifies limitations of expression is something that should be sought after via Government imposed mandates."

    Wow. How did you get that from what I said? I am a coder, and I’m totally against Governments "specifying limitations of expression". Was I vague when I said "If I have implied that I think a government should pass a law mandating that all companies must use a specific format at all times, then that was *unintended* […]"?

    I’d like to clear that one up.

    I pretty much agree with everything you say, so it must be me not making my point very well.

    About the only thing I take *slight* issue with is that:

    "But enforcing upon the world that one format and one format only is how the world must interoperate suggests that its time to go and look up the definition of interoperate and the purpose of things being interoperable."

    Note: I do not disagree with the "enforcing" bit. I’m against "Enforcing upon the world that […] one format only is how the world *must* interoperate […]"

    But surely having a single standard that everyone can conform to is the *essence* of creating interoperable systems. Having two different standards for the same thing creates *incompatibilities*.

    ASCII and EBCDIC are competing standards. They are incompatible with each other, and a program that can read and write one can not necessarily read and write the other. Time spent providing support for one is not time spent providing support for the other. Even worse, not having a standard for how to represent characters as a sequence of bits, or for each competing text editor to use its own private encoding instead, would be the antithesis of interoperability.

    Similarly with Blu-Ray and HDDVD. Competing standards that do the same thing harm interopability by fragmenting a market, and make sure that some applications/players will not be able to read the data from the other format, despite the fact that they do the same thing.

    The purpose of interoperability is for multiple devices/applications to be able to access the same data. For that to happen most effectively, you ought to have a good, well-defined way of representing that data.

    The original DVD standard is a good case in point here. A whole bunch of people with a lot of clout sat down and created a single spec on how they were going to store movies on shiny bits of plastic. If you get a copy of that spec you can create yourself a region-0 DVD that will play in any DVD player, or create yourself a region-0 DVD player that will play any region-0 DVDs. You can be sure of this because there are NO DVD players that only work with "the other spec", or that work best with "the other spec" because that’s the one they spent most of their development time on.

    No, a goverment should not "force" everyone to use the same format for their own documents, but it should choose the format it will use for their own.

    That way, everyone knows what support they need (and therefore what applications they have a choice of) if they’re going to exchange information with the government, and all companies wishing to supply software to the goverment know what standards they need to support to be considered for the bid.

    Eventually, one format will manage to win. I’m glad I don’t have to worry about EBCDIC support/documents anymore. I’ll be glad when everything’s in Unicode/UTF-{8,16} instead of all the incompatible encodings that currently exist.

    Gosh, I just wish that a load of major industry players would all create/join some kind of organisation where they could get together and discuss what they need from an office document format. Then they could design it together, so that everyone with a stake in writing applications that use such documents has their needs at least considered. Then they could create some initial implementations to test the design and iron out some of the problems that they didn’t forsee. Eventually, they could create a standard that everyone, not just the participants, could use to work with office documents. All the information would be in one place, and no implementors would have to worry about splitting their efforts over supporting multiple file types. Wouldn’t that be something?

  14. Alex,

    I believe that the ODF spec just says "here is where formulas would go", but doesn’t specify what the syntax is.

    That’s not the case with Open XML, as you’ll see when the next draft of the spec is released from Ecma.


    You wish is exactly what we are doing right now in Ecma. We meet for hours every week with a collection of companies (some competitors like Apple and Novell; some partners like Intel, Toshiba, and NextPage; some customers like the British Library; StatOil; Essilor; and BP), and we work through all the documentation and make sure that there are no barriers to interoperability. We have even seen prototypes from both Essilor and Novell on implementations that support the Open XML formats.

    I don’t think either ODF or Open XML is going to make all other document formats go away though. HTML will definitely still be around for instance. That’s where we get to take advantage of all the benefits of software though. It’s maleable… we can build transforms that you can plug into if your solution only supports one format natively for example.


  15. Adam says:


    Which other companies have had input into the _design_ of MOOX? Not tweaks at the end, but input into what they need out of a document format _from the start_?

    What independent implementations of MOOX exist that will help to feed back changes to the spec and iron out the bugs?

    And how does MOOX help with creating a _single_ office document format, when OASIS started their effort long before MOOX went to ECMA? Especially when Microsoft, _as a member of OASIS_, could have helped to create _that_ spec in the first place, if they were really interested in interoperability.

  16. Adam,

    I guess maybe I need to reread things then, because I most definitely walked away with the idea that you felt one document format mandated by the Government was something that we should seek after.

    I’m glad to hear I was wrong about this, however, as I was worried (if not made obvious by comments :D).

    With all of this said,its funny to me that the answer to a lot of the problems that everyone is trying to solve in the office document format space all comes back to one very wonderful little technology.

    COM. 😀

    None-the-less…  I digress 😉

  17. Hey Brian,

    Not sure how your blog email system works in regards to notifying you of new messages, but I just sent off a message.  No reason to rush to respond.  Whenever you have the time to think things through and respond back once you have works just fine for me.

    Thanks 🙂

  18. Adam,

    WordprocessingML, SpreadsheetML, and VML were all around before Sun took OpenDocument to OASIS.

    We already have over 300,000 developers out there around the world building solutions on top of Office 2003’s XML support and have had a ton of feedback on the formats. We have a huge network of MVPs that also bring us feedback from customers; and we seperately engage directly with customers to find out how we can better solve their problems.

    Heck, last summer I invited anyone that was interested to provide feedback on the schemas: http://blogs.msdn.com/brian_jones/archive/2005/07/11/437681.aspx#comments

    Now, we’re in a state where we are getting hard core validation from a collection of partners; customers; and even competitors where we are walking through every single piece of the format and making sure it will work properly for everyone’s scenario. There should be nothing preventing anyone from implementing a solution on any platform. I understand that some folks from IBM have been pushing this idea of a ‘scale of openness’, and from my point of view with the format, if you can do anything you want with it, and fully extend it, and it’s completely documented and verifyied to be implementable cross-platform, that’s pretty darned open. 🙂

    (BTW, I’m trying to find some time this week to dig into those perf issues we were talking about last week)

    David, I just got your e-mail. Thanks! I should have some time later this week to look into it and get back to you. I appreciate the follow-up!


  19. Brian, Excellent!  I’ll look forward to your reply 🙂

  20. omz says:

    Gartner.com says ( Research ID Number: G00140101 Publication Date: 12 May 2006

    http://www.gartner.com/resources/140100/140101/iso_approval_of_oasis_opendo_140101.pdf ):


    Users: Recognize that you eventually will be saving your office product data in an XMLbased

    format. Users that need ODF support today or need to comply with ISO standards

    should explore applications that support ODF. If you need compatibility with Microsoft Office

    formats or cannot cost justify a migration, *lobby Microsoft* to support ODF and look

    for plug-ins that allow you to open and save ODF files from within Microsoft applications."

    [ poster’s emphasis ]

    Come on Brian… tell your developers to make a ODF plugin ( in their spare time at least ;-).

    Please be proactive with your customers needs.

  21. I have to say that I disagree with a couple of statements Rita made in that article. I do agree that we will all eventually be saving out data in an XML format. I also think that many folks will be really suprised by the quality of the Open XML format. The upcoming draft that Ecma is planning on realeasing should be a really great eye opener there. The Ecma format is also going to ISO, so I wouldn’t discount it just based on the ISO certification of ODF.

    I wish we had some spare time though omz 🙂
    This has been such an incredible release to work on. We’ve done so much, but it’s also been a lot of work. I’m really looking forward to there being sometime in the next year when things slow down a bit.


  22. Adam, I think some of your comments overlook how innovations happen in industry. For example, you choose to compare ASCII and EBCDIC. But what about ASCII and UTF-8? If governments had mandated (for their own use, sure) ASCII because "it does most of what we need in a text encoding that we can think of", and that sort of behavior was scaled to most governments and industries (which is what you are implying – they would all be making a standards call for their use), we would not be able to move forward with innovating even in plain text formats. UTF-8 didn’t even exist when ASCII would have been mandated.

    By your argument there would be strong industry DIS-incentives to improve ASCII since all these organizations would have banned any replacement because it wasn’t "the standard". Why try to introduce new things your customers will not buy because of their policy? There might still be a way for UTF-8 to come about in such a world thanks to the forward thinking organizations that didn’t close the door on new things, but it would be slowed down considerably.

    A good example of healthy multiple standards is wifi. Should we have frozen on the first published standard way to do 802.11? (or its precursors?). Clearly 802.11b was worth publishing and using, but not mandating so that 802.11g or "n" or "a" could not also be developed. You could have said that we just don’t need more than one wireless standard. You might even say now that “g” is OK because it is backwards compatible, but that’s of course what we’re trying to do with OpenXML wrt to the older binary formats.- and what no one else is making a priority.

    You talk as if document formats are a static thing that we can "just figure out" and then they’ll be "done". There has never been a point in computer technology where something is “done” like that. We (humanity) collectively do not have such wisdom.

    When SGML, wait, HTML came out, there were a LOT of people calling for it to be the one true way to store formatted text. The fundamental issues with it that made it not pragmatic were not so clear to most people – even obvious ones like images can’t be stored in the same file (didn’t matter because everything would be stored on servers ). It was designed for the few things it did well and people got carried away into thinking it did everything we needed (or at least “80%” ha!) Thank goodness the calls to standardize all formatted text storage as HTML, the "universal file format" were ignored – otherwise where would ODF be?

    Likewise it is obvious to us at Microsoft who actually build products with the new formats and to others as they go to implement them that OpenXML is a format that has certain benefits over ODF and deserves to be a standard people can use and not be legislated against. Brian mentions performance and real-world usability in his latest post. For another example, a primary design tenet for OpenXML was to provide "backwards compatibility" with the billions (trillions?) of existing formatted documents (Office binary formats). It is *not* OK to just keep 80% or whatever of current doc formatting and contents. Keeping everything as they move forward is the number one priority for our customers, and it is also a kind of stewardship role that Microsoft has. We’re responsible for maintaining the data integrity of a huge chunk of the world’s information. This is a huge and difficult goal of OpenXML that ODF does not share.

    Does this mean we think ODF shouldn’t be a standard? Hardly. It’s important to let the market move forward and determine what the right uses of formats are, how they can be improved and not try to legislate them (even for a single government entity). I for one would love to see the arguments for ODF stop being religious or theoretical or academic or aesthetic and start being more about what scenarios the format is optimized for technically to understand when it would be the right standard for a customer to choose vs other options.

    Does all this mean we think ODF should never come out of Office apps? Of course not. We’ve said from the beginning that we expect at least motivated third parties to develop output (and input) converters for Microsoft Office. The ODF alliance even announced such themselves. On our part, right now we are busy finishing the format our customers are asking us to get right. if there’s significant demand we might do ODF – this is not news, we’ve been saying it for awhile. Right now demand for ODF is miniscule to put it kindly. We still get far more requests for updated WordPerfect converters, and that is utterly dwarfed by requests for PDF support – which is why we did PDF support. We’re doing what our customers want – believe it or not.

    Sorry if this post sounded a little shrill – not my intent. And if you don’t trust Microsoft which is perhaps what most of this is about then we just have to keep plugging away to earn trust. To me this whole document format things is really a pragmatic matter: solve problems, optimize for key scenarios. And of course any entity can choose to do what it likes with the software and formats it uses, even limiting itself to one format if that’s what it wants. I’m all for customer choice since I think we can deliver best on what they need – but it’s worth considering the impacts of such a decision on that org for the future and its agility. Most important though is that we do need to let the market’s innovation engine run.

  23. Francis says:

    Adam and Chris, you are both right!

    Government can distort the market and destroy incentives for progress.

    On the other hand, gcovernment *CAN* have a very salutory role through "technology forcing." The goverment stimulates innovation by issuing standards that cannot be met with current technology. Business is forced to develop and implement new technology to attain them. For instance, if the EPA were to mandate that all power plants emit 50% fewer emissions in the next five years, the electricity would not go out. Instead, utility companies would be forced to oblige by inventing and deploying new/non-conventional technologies. A positive externality (side effect) of this regulatory regime is increased competitiveness. Forcing domestic producers to develop new technology gives them a leg up on international competition.

    I am not sure, however, whether this–much like patents–should be applied to the fast-innovating software industry.

  24. Francis, your example is actually reinforcing my point. What you call a “standard” for emissions is actually a different type of standard – it a goal which companies are free to try many different solutions for. There are many different approaches to emissions scrubbing and the government is not specifying that standard, just the end result they want. In this way they are actually creating a market and *not* standardizing. So that’s a fine thing and not what Adam is suggesting.

    Similarly in cars, the government would not be so foolish as to try to pick a winner like “hybrid” or “hydrogen” or “fuel cell’ or “pure electric” and tell everyone they have to use that in order to reduce emissions. In practice no one knows what the right long term choice(s) are going to be in these areas so the government is wisely just setting emissions and mileage goals (albeit not very aggressive ones). The market will figure out the right choices and they will likely include several options, just as we have had gasoline of different grades, diesel and even some propane and CNG powered cars for decades. Diesel is good for trucks, but gasoline is better for cars, and high-octane gas is better for sports cars. CNG and propane are good for fleets of vehicles such as buses, taxis and delivery trucks. That is my point: having multiple standards optimized for different things is valid. I am glad the government didn’t standardize on only one fuel.

    Some options that are pretty far away and very different from how things work today like hydrogen would probably require some kind of government support to get going outside of fleets of vehicles, although possibly not if they really offered benefits like price, energy to volume (longer range between fill-ups) or similar. Maybe the government would be picking wrongly since we don’t know how that’s going to play out – its best to set the goals we want to achieve and not specify how to achieve them. Interestingly, hybrid is the option that is taking off naturally (they all have government incentives) and it is the one that is backwards compatible with the existing infrastructure. Hmmm.

    Whenever there is an explosion of new technology there are always people clamoring for a governing body to reduce the confusion and just pick a winner. The government needs to resist doing this and instead set goals for interoperability, compatibility, whatever it feels are important and let technology firms and standards strive to meet or exceed those goals. The right standards will thrive in the end for the right uses. No set of bureaucrats can possibly determine the right technical solution in advance anymore than we can predict the future.

    With doc formats this whole discussion is also missing the role that *standards* play. To become an official standard at ECMA or ISO a standard must include extremely detailed documentation on how to implement it so that anyone adhering to the standard can interoperate with anyone else. With OpenXML, there are many different firms including some working on open source apps and proprietary apps (e.g. Apple) who are making sure that the OpenXML standards are fully explained, documented and implementable from the standards.

    BTW, OpenXML as standardized by ECMA and later ISO will be fully compatible with open source GPL due to the covenant not to sue – we’re already seeing the work being done. As a proof of concept you can see today even the older WordProcessingML that Word2003 can use and covered by the same covenant is supported by Open Office 2.x – and we didn’t even have to standardize that for them to be able to do it. The existence proof is there.

    Consider CDs. To the layman, there’s just one format. You stick it in and it works. If the CD has data you can read the data, if it has CD-video you get that, likewise for audio. What a great universal format – not! There are many different standards for recording information and even formatting CDs that are not compatible. But because each one is a standard that is documented for everyone to use, nearly all CD and DVD players can play them all because they have implemented all 10+ of these well documented standards. The right formats are used for the right data types.

    That’s most likely how its going to be for doc formats too. No need for a single “one size fits all” format – you can achieve excellent interop with multiple formats that are clearly standardized. Most likely we’ll be in a world where every app in a category like word processing can open each others’ formats to the best of their capabilities once they are standardized and then people will use the formats and products that work for them.

  25. Molly C says:

    To Brian Jones and Chris Pratley:

    Do either of you have anything to say to this recent cnet article?

    "ISO approval ‘unlikely for Microsoft Open XML’"


    It claims that since ISO ratified ODF, then they’ll reject any other XML format.  Seems like bull, but if it’s true, then it seems that ISO is playing politics and is flushing its credibility down the toilet.  But what say you?

  26. I have read that article Molly, but I strongly disagree with it. If ISO took that approach, there would be no new innovation or evolution in the software industry. The Open XML formats and the OpenDocument format serve different purposes, and I don’t think there will be trouble for Open XML in ISO. There are all kinds of examples out there of multiple technologies are similar and been both been given ISO approval.


  27. omz says:

    >>The Open XML formats and the OpenDocument format

    >>serve different purposes, and I don’t think there will be

    >> trouble for Open XML in ISO.

    I believe their purposes are the same, they are office software documents formats, mainly intended to save user’s "office" documents ( at home or at work ).

    More than that,  they must guarantee that this documents are accesible to *all* people in *all* platforms at *any* time.

    May be the best solution is to bring all the "parties" together ( MS, Sun, IBM, Corel, Adobe, users, developers, etc ) to colaborate toward a *unified*-vendor neutral-totally open format a.la HTML  ( http://www.w3.org/TR/REC-html40/ ).

  28. Molly C says:

    > I believe their purposes are the same, they are office software

    > documents formats, mainly intended to save user’s "office"

    > documents ( at home or at work ).

    That you had to add the "mainly" qualifier implies that there are different purposes served, although they may overlap.  Besides, there are features in OpenXML that simply aren’t in ODF, which indicates that OpenXML has a broader purpose than ODF.

Skip to main content