More information on the Open XML translator and some questions answered


There were a lot of great comments from last week’s announcement about the creation of an open source project to transform between the Ecma Office Open XML formats and the OASIS OpenDocument format. Rather than respond to all the comments and questions directly, I thought it would be better just to write up another post to address the general themes people have raised.


Here are the main questions:




  1. Will the translator only work with Office 2007?


  2. Aren’t there licensing differences that make ODF and Open XML incompatible?


  3. Will the functionality be easy to find in the UI?


  4. Doesn’t this move contradict what you’ve been saying about Office not supporting ODF?


  5. Will the Ecma Office Open XML formats still be the default in Office 2007?


  6. Why don’t you join OASIS and help improve where they are lacking?


What versions of Office will this work with?



Well, first you should all remember that we are making the new Open XML formats backward compatible and providing free updates to Office 2000, XP, and 2003 which will allow all three of those versions to consume and generate files in the Open XML format. The new tool that is now an open project up on sourceforge will convert from the Open XML format into ODF, which means that you can use this tool in combination with the free updates to read and write ODF in all those earlier versions of Office as well.


Aren’t there licensing differences between ODF and Open XML?


Actually, this misunderstanding is the unfortunate result of a really strong push by folks who I don’t believe quite understand the Open XML story. There are a handful of folks who blog a lot (primarily ODF supporters) who aren’t up to speed on the latest policies around the Open XML formats.


Let’s address this first misunderstanding. The formats are available without any licensing restrictions. Any IP (patents, etc.) that Microsoft may have behind the formats does not apply to folks who want to implement the formats, because Microsoft made a legal commitment to not enforce that IP. If you hear people complaining about licensing issues, they probably just aren’t up to date.


Secondly, the formats are no longer owned by Microsoft, they are owned by Ecma international. They are fully documented and the spec is free to download. A large number of organizations (British Library; Apple; Novell; Microsoft; BP; Intel; etc.) have worked on ensuring that the documentation allows for cross platform implementation.


Will the functionality be easy to find in the UI?


Look for yourself, here’s a screenshot of the current prototype:



It’s directly exposed in the UI. We’re even going to make it really easy to initially discover the download. We already need to do this for XPS and PDF, so we’ll also do it for ODF. There will be a menu item directly on the file menu that takes to you a site where you can download different interoperability formats (like PDF, XPS, and now ODF).


Heck, if you wanted to be even more hardcore, the Office object model allows you to capture the save event. So if you wanted to you could make it so that anytime you hit save you always used the ODF format, just by capturing the save event and overriding it. I’m not expecting folks to do that, but it does show just how extensible Office really is.


Doesn’t this move contradict what you’ve been saying about Office not supporting ODF?


I’ve been pretty clear that I thought third parties would come along and build ODF support into Office if there was interest. That was shown to be the case pretty early on, as there have been a couple different projects announced over the past year. Ironically, one of the most high profile projects was announced by the OpenDocument Foundation but it has turned out to be pretty secretive and closed, which seems to go against all the goals of “openness”. I’ve had folks ask me how they can get a hold to it, but as far as I can tell only a select group of folks have been given access. I saw a quote saying they still hadn’t decided if they wanted to charge for it or not, so that may still be holding things up.


With all the mystery around projects like that, we had a number of governments ask us to get involved and actually choose a project to back, as they wanted to know that if any of their constituents used the ODF format, they would be able to view those files.


I think this project is a great example of the openness of both of these formats. We are now going to have an open source implementation that everyone can use. It will of course be freely available to anyone, and will really help show how to use the two architectures of ODF and Open XML.


Will the Ecma Open XML format still be the default for Office 2007?


Yes, this is definitely still the case. While this new translator will help people read and write the ODF format in Office, it will also help make it clear to all why the Open XML format was necessary. The Open XML formats were designed to be 100% backward compatible with the existing set of Office binary formats, and that was really a goal that we can’t compromise on. If we went with an XML format that resulted in data loss or poor performance, then the only people that would use it would be folks who actually cared about that specific file format. Since most of our users don’t really care about file formats, we needed to create an XML file format that we knew everyone could use, otherwise most people would have just gone back to using the old binary formats, and that doesn’t help anyone.


While the ODF format is great in terms of being an open XML format, it’s lacking in a number of functional areas that make it not a realistic option for Office to use as a default format. For instance, the format for ODF spreadsheets is much less efficient from Open XML’s spreadsheet format. I have a few posts talking about this (and I plan to cover it in greater detail as we move forward):









There are also a whole host of areas that are left unspecified in the spec (such as spreadsheet formulas), which would have meant we’d either need to extend the format, or wait for it to catch up (and it sounds like they are more than a year out for formulas in particular). There are a number of blog posts out there talking about the incompatibilities between the various applications that have implemented ODF, and a lot of that is due to the lack of clarity on some features in the spec. Look at this comment from the OpenDocument Foundation talking about KOffice’s ODF support:



Our tests show that OpenOffice and KOffice have some problems opening each other’s OpenDocument files. Also, support for drawings is a bit incomplete.”


The Ecma Open XML format is significantly further along in all of these areas, just look at the differences in the documentation of numbering formats, formulas, etc. The draft of the Ecma spec released back in the spring has over 160 pages on spreadsheet formulas; the ODF spec only has 1 page.


I don’t want to be critical of ODF because I think it’s great to see applications use open XML formats for their storage. I’m calling attention to these points because I think a lot of folks have mistakenly assumed that once there is a standardized office format, everything is set and you don’t need another one. Unfortunately that’s not the case, and I want everyone to understand why we couldn’t use ODF as our default format. I have no problem with multiple XML standards for documents and I think this is definitely a case where an alternative is necessary. If a single XML file format were the way to go, then we would have just stopped with XHTML (or maybe DocBook).


Most of our customers actually do understand this, and contrary to the news being spread (primarily by people excited about the ODF format), most governments have not adopted policies around ODF exclusively but instead around open formats in general. Most of those governments have also expressed that once the Office Open XML format is approved by Ecma, it would also be viewed as an open format.


For example, the Belgium government is currently being described as “mandating ODF”, but that’s actually not the case. They even made a public statement last week after we made the translator announcement that clarified this. Here’s a small blurb from that:



“The government’s choice for ODF is clear, but not exclusive.” …”If the OpenXML file format (Microsoft’s own contribution in the domain of open standard file formats) receives ISO approval as a standard, then this format will also be eligible for use in the administration of the Belgian government.”


Why don’t we join the OASIS technical committee to help them along?


I had a few folks asking this question (and saw it on a few other blogs as well). The standardization of Ecma Office Open XML formats is really moving along well, but there is still a bit more work to do here to nail things down. If you’ve read through the latest draft (all 4000 pages), you’ve probably noticed how comprehensive of a spec it really is. For example, there are over 160 pages on how spreadsheet formulas works as compared to 1 page in the ODF spec. The ODF spec still has a lot of catching up to do, and according to this post they are still more than a full year from just getting in line on some of the basics (like formulas) that have existed in office documents for decades.


The Ecma Office Open XML spec on the other hand serves as a great base in terms of fully standardizing an XML format that is capable of representing the billions of Office documents that exist today. Once that’s done, we (as a community) can then move forward and start to enhance it with new innovations. It’s maintained by Ecma, and anyone can join and participate in the standard.


I think that anyone interested in helping to drive the future of office file formats should join us in Ecma and take advantage of the powerful framework for document formats that is being delivered. As I already pointed out, formulas in spreadsheets for example is already close to being fully documented. The same is the case for all the international features and functionality (like the various numbering styles I’d mentioned before). If you don’t have the time to participate directly in the working group, you can instead send direct feedback here: mailto:ecmatc45feedback@ecma-international.org


-Brian

Comments (38)

  1. Why did you guys put the prototype up on SourceForge instead of CodePlex?

  2. Adam says:

    "…a lot of that is due to the lack of clarity on some features in the spec. Look at this comment from the OpenDocument Foundation talking about KOffice’s ODF support:

    ‘Our tests show that OpenOffice and KOffice have some problems opening each other’s OpenDocument files. Also, support for drawings is a bit incomplete.’"

    You make it sound like this is unusual or even unwanted.

    IE still has some problems displaying HTML4 and CSS2, despite the fact that those specs are over *8 years* old.

    With _all_ specs, be it document formats, image formats (e.g. PNG partial transparency support took a while to appear on a number of platforms IIRC), programming languages (C99 now 7 years old, still not fully supported by GCC or MS CC last I looked), it does take some time for interoperability issues to be worked through, for all implementations to agree on what is the correct interpretation on unclear parts of the spec, and for corrections, addendums, defect reports, etc… to be made to the spec itself.

    A /necessary part/ of making sure interoperability /works/ is actually having multiple independent implementations attempt to interoperate, so that these issues can be found, raised and worked through. (Specs are like programs – they’re never entirely bug-free.)

    Tell us again, how /are/ the independent implementations of the complete MSOOX spec coming along? How are these issues being found in /those/ 4000+ pages?

  3. davidacoder says:

    You are not serious about that UI, right?!? The right way to do is to just put it into the "normal" open dialog, as a format selection into the "save as" dialog and allow us to pick the default format for saves in the options.

  4. As I blog on extending the Office 2007 UI (http://pschmid.net), let me address the UI issues….

    davidacoder: Office 2007 gives an add-in (whether from MS or not) either the option of taking over the "Save As" dialog completely (which means that the built-in Save As dialog never shows, but only the own you provide) or adding an item somewhere in the Office button menu (the approach chosen by the add-in). As this functionality is not built-into Office, what you are asking for is not possible.

    If someone wants to use ODF only, it is fairly straightforward to replace the existing New document, Open document and Save As dialogs.

  5. Dr. Nikitah Imani says:

    Pet peeve. I run an older laptop on Win98SE. Now the XML adapter program can run on Office XP, which is the last version of Office compatible with 98SE. However, when I downloaded it, it wouldn’t install on Win98. I can understand why we shouldn’t expect 987 specific upgrades in this regard. But why wouldn’t the program work with any valid installation of Office XP including those on Win98 since I suspect not a few of the Ofice XP users are running that os. With the older laptops like this, upgrading is not an option and not all of us can just run out and buy a new laptop on Microsoft command.

  6. davidacoder says:

    Well, then MS should enable plug ins to do that. If they are going to ship two themselves, it would really make a lot of sense. Also, could the ODF item at least appear on the sub-menu of the save as thing? Making it a top level thing in the office menu ist just terrible and will be an incredible bad example for other add ins. From that point on every add in will add a major entry to the main office menu and will always be able to point to MS, since they did that with their add in as well…

  7. Francis says:

    Patrick: if what you say is true, then how is it that:

    1. installing the Office 2007 Beta suddenly gives me a raft of new open and save options in Office 2003?

    2. adding/removing import/export converters in Office 2003 also changes the file type list in these dialogs?

  8. Patrick Schmid says:

    davidacoder: You could put it into the Save As list. But where would you put the open ODF file then?

    Francis: Regarding 1. Did you install the Awareness Update? That should modify the list to include the new file formats (OpenXML). Keep in mind though that the Awareness Update is a patch to Office 2003 and not an add-in.

    2. Good question. Maybe if you write it as file converter instead as an add-in, you can do this. But written as an add-in, you’ll have to go the RibbonX route which doesn’t give you access to this list. Let me see if I can’t find some documentation on this issue.

  9. You haven’t really answered the question about joining the TC, using it instead to digress into promoting OXML.

    In the previous post, you asked a series of questions about interoperability to the blogosphere. My point was that it makes much more sense to address these concerns and questions directly with the ODF TC.

    On another point, I really think you ought to avoid the constant bigger-is-better comments and reference to incompatabilities between ODF applications. On the first point, one reason ODF is signficantly smaller is because it heavily-reuses existing standards.

    On the latter, OXML has yet to have a single shipping application, much less multiple. When you ship and another vendor implements full OXML support and you have seamless interoperability, then you can make a reasonable argument. But until then it’s FUD.

    Finally, I’m sure you realize that the standards process is slow, so I’m not really sure it makes much sense to spread disinformation here. The three current subcommittees whose work with go into ODF 1.1 and 1.2 will finish their work in less than a year, and it’ll then take a few months to go through the approval process. So what? How long will it take TC45 to finish the spec, get it approved, and then go through ISO?

  10. davidacoder says:

    Patrick, I understand that you don’t have much choice here. But at the same time, I believe MS should enable a add-in way to do this in a proper way, in particular when they intend to give official blessing to this project. We agree that from a UI and consistency perspective the right thing to do would be to integrate into the extisting open and save dialogs, and have no extra top level menu item? Then MS should enable that for your project.

  11. BrianJones says:

    Bruce, I don’t think I’m spreading FUD at all. Michael Brauer says in that link that the committee draft is still 1 year away and that OASIS will not vote on it until at least October 2007. Then it will most likely take another 6 months to go through ISO.

    I made that statement because from what I can see, both OpenDocument and OpenXML are incomplete specs. You can’t possibly think that OpenDocument is a complete spec when it doesn’t even cover the basics like formulas and more advanced international features. I haven’t claimed that Open XML is complete yet either, but it looks like it’s much further along. The current goal for Open XML is to have it an Ecma standard by the end of this year (as opposed to the end of next year for OASIS to vote on ODF).

    And in terms of shipping implementations of either spec… as I’ve said I’m not claiming that Open XML is complete yet, so I’m not expecting there to be many shipping implementations. We’ve seen a number of prototypes built by people in the working group (Novell, Toshiba, Esilor).
    The shipping “implementations” of OpenDocument aren’t really much better though. Every document I’ve played with opens differently in the different applications. I even had a document that when saved from KOffice as ODF caused OpenOffice to crash. So I would hardly say those are good examples of shipping products supporting the standard (outside of OpenOffice and those applications that took OpenOffice’s file I/O code, the rest are more like prototypes).

    -Brian

  12. Patrick Schmid says:

    davidacoder: Just to clarify one thing: I don’t work for MS nor do I have to do anything with the development of the add-in. I happen to be extremely interested in the 2007 UI and blog on how to customize it (as that doesn’t work out of the box anymore). From that point of view, I don’t know of any way to add it to the list in the Save As dialog. However I didn’t think of writing it as import/export converter (instead of an add-in) as Francis suggested. I don’t know if that is possible, but I am going to find out.

    Being able to add an entry to those lists would be very low though on my list of UI customization issues to request for 2007. There are so many shortcomings in the new customization model that are much more important to fix.

  13. Simon Jones says:

    Brian,

    You said that several people have asked the question "Why don’t we join the OASIS technical committee to help them along?" but you don’t really give an answer. The nearest you come is "I think that anyone interested in helping to drive the future of office file formats should join us in Ecma…".

    Can you answer the question?

    Simon Jones

    Contributing Editor

    PC Pro Magazine

  14. Wouter Schut says:

    Yes, please answer the question.

    Why didn’t and doesn’t Microsoft join the OASIS technical committee to help them along?

    Microsoft has a very bad track record with (open) standards. And even today Microsoft is clining onto its own proprietary standards. Participating fairly in open standards just isn’t a company wide mantra. And even in this Office arena you’re not really convincing. This plugin should enable the user to make Odf the default format with just a simple setting (just like you can set OpenOffice to save as .doc). If Microsoft isn’t willing to change Office then the odf effort doesn’t really go far up into the tree.

    In order of preference Microsoft wants to:

    – dominate with own proprietary standard (samba, ntfs)

    – create a new incompatible format (html, java)

    – create own ‘open’ standard (openxml, .net)

    And whenever posible:

    – try to close any standard (msn messenger)

    – inform the world about how bad non microsoft proprietary standards are (aac)

    – give your own solutions a head start

    – create a hurdles for others

    Ps. I did try out Office 2007 Beta (it completely destroyed my office 2003 installation and the ribbon was very anoying). And also with the odf plugin:

    http://www.seweso-systems.com/2006/07/odf-plugin-for-office-12.php

    P.s.2. Yes I personify Microsoft the company. I need to do that to be able to trust it. Currently Microsoft is a very schizophrenic person if you ask me, doing this with the left hand and something else with the other. Fix this!

  15. Andrew says:

    The answers to that question — why doesn’t MS join OASIS and influence the standard so they can use it more effectively within  Office — seem painfully obvious to me.

    1) Tying themselves to an "open" standard with different objectives for a file format than Microsoft has is foolish.  ODF is designed to be very human-readable, and is designed specifically around OpenOffice.org’s formats (not Microsoft’s).  The design goals of ODF do not apparently always match those of Microsoft.  Should Microsoft try to subvert ODF so that it fits their goals more closely, or should they develop their own standard and allow users to choose which one is more effective for their use?

    2) Some of the more powerful members of OASIS vis-a-vis ODF are not exactly friendly with Microsoft, and develop competing products.  Why would Microsoft want to subject themselves to the huge contention that would almost doubtless arise in such a situation as vendors struggle within the committee to control the format to their own benefit (or the detriment of their competitors)?

    As for why they didn’t join OASIS and help out, even if they had no plans to depend on the standard, what makes you think Microsoft is particularly interested in helping their competitors?  ODF is, in reality, to the benefit of Microsoft’s competition.

    My personal feeling is that competing document format standards, if they are open, are a Good Thing.  That way, everyone has the opportunity to choose the format (or formats) that best suit their needs.

    But hey, I’m just a guy who uses Office.  I’m no expert.

  16. BrianJones says:

    Thanks Andrew, I think you really nailed a couple of points there.

    Bruce, Wouter, Simon,
    I’m sorry if it appeared like I didn’t answer the question. I thought I had actually made it clear why we weren’t participating directly in the OASIS committee, but let me try to clear it up.

    We ultimately need to prioritize our standardization efforts, and as the Ecma Office Open XML spec is clearly further along in meeting the goal of full interoperability with the existing set of billions of Office documents, that is where our focus is. The Ecma spec is only a few months away from completion, while the OASIS committee has stated they believe they have at least another year before they are even able to define spreadsheet formulas. If the OASIS Open Document committee is having trouble meeting the goal of compatibility with the existing set of Office documents, then they should be able to leverage the work done by Ecma as the draft released back in the spring is already very detailed and the final draft should be published later this year.

    To be clear, we have taken a ‘hands off’ approach to the OASIS technical committees because:  a) we have our hands full finishing a great product (Office 2007) and contributing to Ecma TC45, and b) we do not want in any way to be perceived as slowing down or working against ODF.  We have made this clear during the ISO consideration process as well.  The ODF and Open XML projects have legitimate differences of architecture, customer requirements and purpose.  This Translator project and others will prove that the formats can coexist with a certain tolerance, despite the differences and gaps.

    No matter how well-intentioned our involvement might be with ODF, it would be perceived to be self-serving or detrimental to ODF and might come from a different perception of requirements.   We have nothing against the different ODF committees’ work, but just recognize that our presence and input would tend to be misinterpreted and an inefficient use of valuable resources.  The Translator project we feel is a good productive ‘middle ground’ for practical interoperability concerns to be worked out in a transparent way for everyone, rather than attempting to swing one technical approach and set of customer requirements over to the other.

    -Brian

  17. Simon Jones says:

    Brian,

    Thanks for the clarification. I think you addressed the question squarely there.

    Simon Jones

    Contributing Editor

    PC Pro Magazine

  18. Wouter Schut says:

    Thanks! This really helps to see it from your point of view.

    Ok so the short answer would be: The effort to bring Office 2007 and Odf together would have been to great and it probably would have resulted in a PR nightmare.

    It seems your answers is more mature and objective than before. I can accept this answer better than something like "Odf is bad" because I really don’t think Odf is bad. It’s not perfect and it doesn’t have perfect implementations but I believe the direction where Odf is headed is better.

    Odf is a more procedural, generic, simple and vendor-neutral format than OpenXml. OpenXml represents the structure of office 2007 to much. Which from a development point of view is of course very logical ánd very efficient. You have a consistent object-model, grafical-model and document-model which all fit together nicely. And that is pretty handy if you want Office 2007 and not Office Forever ;).

    Some questions:

    – How much did the object-model for Office 2007 change if you disregard all the new features?

    – Is the object-model for Office 2007 similar to the structure of OpenXml and if not what are the differences?

    – Will Microsoft try to bring Odf and OpenXml together in the future or will this never be goal?

    – Is it posible to incorporate a Microsoft converter which converts Office binaries to OpenXml into an Open Source Application?

    – How does Odf affect your work? are you happy with its existence?

    – Can we expect more Microsoft standards to open up and XMLize?

    – Do you understand the scepticism agains OpenXml?

    And keep up the good work!

  19. Andrew says:

    "Ok so the short answer would be: The effort to bring Office 2007 and Odf together would have been to great and it probably would have resulted in a PR nightmare."

    Not to mention the extra contention would likely slow down the ODF process tremendously.

  20. Stephen McGibbon has an interesting blog post based on his observations of the politics behind standardization….

  21. Como se sabe XML en un formato independiente de la plataforma y del lenguaje, y la adopción que vienen surgiendo desde…

  22. Como se sabe XML en un formato independiente de la plataforma y del lenguaje, y la adopción que vienen surgiendo desde…

  23. Patrick Schmid says:

    I looked into the question of whether it would be possible to show the ODF formats in the Save As dialog file format list. The information is straight from the Office 2007 beta team, so I am quite confident that there are no other options.

    1. The SaveAs dialog cannot be customized

    2. The only option to provide a SaveAs dialog with the ODF formats in it is to replace the built-in dialog with a custom created one (using RibbonX e.g.). This is not an option for this add-in. Why? Read my style guide on RibbonX customizations: http://pschmid.net/blog/2006/06/09/20

    3. Writing this as import/export converter is not an option either. The only program for which a custom filter can be written is MS Word. However, such a filter would convert between the external format and RTF, which definitely misses the point for the ODF translator project. For more info on this, see http://support.microsoft.com/kb/111716/en-us

    4. The only viable solution is therefore to provide the formats as items in the Office button menu. The current implementation as its own menu item is in my opinion the best approach. Adding ODF to the Save As flyout would bring up the issue of where to place the Open ODF command. By having open and save combined under one menu item, users can find and use both commands easily.

    5. If anyone wanted to use ODF as the default format, it is fairly straightforward to change the RibbonX code to have the ODF open & save features be the ones called when using the built-in open & save. The built-in ones could then be moved to a menu item similar to how ODF is currently implemented. This is probably a change of a max of 10 lines of code.

    6. As I have stated before, the ODF translator is an Office 2007 add-in and therefore limited to whatever is available to all other Office 2007 add-ins. Microsoft isn’t going to provide any special MS-only hooks into Office 2007 just to integrate the ODF, PDF & XPS things into it. MS-only hooks would just be a waste of development resources and non-MS add-in developers would want to use them as well (which would be simple due to the open source nature of the ODF translator project). Hence, this is either going to happen through a normal Office 2007 add-in mechanism, or not at all.

    7. I personally highly doubt that customization of the SaveAs dialog will appear in Office 2007 and I am not in favor of implementing it either. There are many other aspects of UI customization that should be addressed long before doing any work in the SaveAs dialog area.

    I hope this addresses all UI related issues of the ODF translator add-in.

    Patrick

  24. Dan says:

    This seems like a conscious choice by Microsoft to limit competition at the same time that they are creating press releases about how they are fostering competition.  I highly doubt that Microsoft doesn’t understand that they are trying to scuttle ODF adoption by creating multiple, minor barriers to entry for its use in Office 2007.  Having Microsoft, or yourself, tell us that it is not technically possible to put ODF in the Save As dialog box, or saying "but where would we put the Open ODF option?" is really insulting.  

  25. Patrick Schmid says:

    Dan: insulting?

    First of all, I am not involved with the ODF translator project at all. Second, I don’t work for Microsoft. Third, I was referring to the SaveAs flyout. You can add an entry to the SaveAs flyout that says "ODF". But then the extremely valid question is where you would put the open ODF command in the Office button menu. The menu item for Open does not have any equivalent flyout. So where do you put it? This is not an insult, just a straightforward design question. Have you actually looked at Office 2007 yourself? Your question rather implies that you have never seen this Office button menu and really don’t know what I am talking about.

    This ODF translator project was an afterthought by Microsoft. Hence it has to make do with what is currently possible.

    In terms of the actual Save As dialog box: It would be nice for it to be there, but it’s just not going to happen. Why should MS waste resources on providing one particular feature for add-in developers that most Office add-in developers (all not affiliated with Microsoft) would put at the very bottom of their wish list? How many add-ins would actually use such a feature (answer: 3; ODF, PDF, XPS). Sorry, but providing such a feature to satisfy 3 add-ins is a real waste. There is so much missing in Office 2007 from the point of view of an add-in developer, that MS has enough work for the entire next release (after 2007) before even considering the SaveAs dialog box issue.

    Keep in mind that most average users really don’t care about ODF vs OpenXML. All they want to do is save their files and they are hardly ever going to change the default file format anyhow. As Brian has pointed out before, ODF doesn’t support all that OpenXML supports, and hence ODF is anyhow not useful as the default file format for Office 2007.

    Quite honestly, whether ODF is in the SaveAs dialog box or not doesn’t really matter. Most people who will use ODF will do so due to company/agency policy. That means, the ODF add-in will be preinstalled for them by their network administrators. Network administrators can easily change the add-in (one of the benefits of open source) in such a manner that ODF will be the default for open and save (by providing their own Open & SaveAs dialogs and functions). That’s rather simple to do.

    Everyone else who downloads the ODF add-in, will actually know what they are downloading and will have no problem finding it at its prominent location in the Office button menu.

    In summary: Instead of calling this an insult, download the source code and modify it to your taste. A few lines of XML and a few lines of source code will do wonders. If you don’t like the way the add-in works right now, write something better and post it.

  26. Dan says:

    If Microsoft is blocking the SaveAs dialog box from being customized (I’m not talking about the flyout, so forgive me if I confused things– I’m talking about the old-fashioned way of saving documents with which people are accustomed and which people will still use extensively), then it seems misleading to say that this is an open process, because what is happening is that it’s open up until the point of making ODF a first class format.  Sure, Aunt Sally may not know or care about formats per se, but technology is rapidly moving towards having data able to act much more interactively with web services, tools, etc.  So when tools come out that do cool things with data in ODF, Aunt Sally may want to be able to make use of those tools, and save to ODF.  So by blocking ODF from being a first-class format, Microsoft is seeking to preempt innovation in ODF and steer it towards Microsoft-centric tools.  In any case, I really am not going to believe Microsoft’s claim to be embracing interoperability unless they do what is one of the most obvious and important steps towards interoperability– allowing ODF as a first-class citizen.  I am a Microsoft customer, and I want to be able to save ODF in Word 2007 as easily as I would save Microsoft OpenXML formats; I want people to be able to easily send me documents in ODF and have them be as simple to open as it is to open OpenXML or .doc formats.  I don’t believe that it’s technical or manpower issues that keeps Microsoft from doing this.  If it is, and Microsoft developers are so limited in their technical ability that they are unable to do what is obviously a simple task if one has access to the code, then Microsoft is in a lot of trouble.  Fortunately for Microsoft, and unfortunately for us consumers, I don’t believe for a moment that it’s actually technical or manpower issues that’s to blame, but rather willful reluctance to allow true, low-barrier interoperability.

  27. Patrick Schmid says:

    Dan, Microsoft is not really blocking it, but rather not providing it at this point in time. It might be surprising that MS is actually very limited by resources and everything they do is carefully prioritized and then decided upon.

    The ODF project appeared after Beta 2, and MS is denying almost all requests for new or changed features at this point as they are focused on stability and performance right now. Essentially, if it’s not in Beta 2, it is almost certainly not going to be in the final product.

    Even if it appeared much earlier in the beta cycle, providing customization for the SaveAs and Open dialogs would have competed with other UI customization issues:

    – ribbon enumeration. As great as the new ribbon is, there is no built-in way for an add-in to "read" it or trigger things like a tab change (without some not so great to use "hacks")

    – MS-group customization: groups on the ribbon provided by MS cannot be changed. So you can’t just add a button to the Clipboard group e.g., but rather have to make your own group next to it

    – in-ribbon galleries: add-ins can’t create galleries like the Styles one on the Word home tab. The only galleries add-ins can create have a dropdown button in the ribbon with the gallery appearing below it when you click it

    – second chance at loading ribbon customization code: an add-in gets one chance to provide ribbon customization XML, which is quite limiting for some add-ins

    – ribbon customization XML cannot be provided via VBA: if you write add-ins in VBA (there are a lot of people out there doing this), you have to include the XML in the actual zip container of the OpenXML file. You cannot just come up with it dynamically and just pass it to Office in your code

    – the status bar cannot be altered, nor can the buttons you see in the Word full screen reading mode

    Those are just the big things I could think of that don’t work on the UI customization side. For users, there obviously is the major issue of no UI customization at all. If you are a user, you either need to learn how to use the Ribbon XML stuff or get a 3rd party add-in. Otherwise, the ribbon cannot be altered by you.

    Maybe MS will provide customization of the Open and SaveAs dialog in the next Office release (#14, 13 is being skipped). It certainly won’t make it into Office 2007 this late in the beta cycle.

  28. Steve says:

    Brian, I understand that you’ll get crap no matter what way you proceed, but one thing bothers me.

    Reading this blog entry http://www.robweir.com/blog/2006/07/lost-in-translation.html

    makes me uneasy.

    It’s nice and all to have the plugin and be able to read ODF, but doing a poor job of it opens you up to a lot more (probably false) criticism than not having the plugin does.

    I’m hoping that Microsoft is actually fully behind the plugin and that it will quickly improve to the level of the other software packages that read ODF. It doesn’t have to be perfect (because as you said, the current products that use it don’t implement it perfectly), but it has to be good enough not to lose information.

  29. BrianJones says:

    Hi Steve, that analysis really seems to be a bit premature (to say the least).

    The project has just started, and I’m not suprised that it’s easy to identify problem areas. I suppose it could have been worked on more in private before it was posted up on source forge, but the whole point was to give great transparency to the project at an early stage. This way people can directly participate in the development.

    Let’s actually hold off on judgement as to the quality of the output until it’s further along. But if you see any areas that need work, feel free to post them to the site (or you could even work on it directly)!

    -Brian

  30. Dave says:

    I think what everybody needs to understand is that Microsoft has an extremely bad (and deservedly bad at that) reputation for interoperability. Their attention to vendor lock-in and FUD is legendary. Only the IBM of the past even comes close. If you can’t admit that, then you’re drinking too much of the cool-aid.

    Until such time that they actually prove *repeatedly* that they are serious about interoperability, nobody is going to give them the benefit of the doubt. End of story. This obvious UI decision seems to signify that they aren’t going to do that soon.

    And for those of you saying that this is alpha software, and that it will change due to customer feedback, what’s the obvious choice from a UI designer’s standpoint? To a) have every plugin that saves another format have its own fly out  menu in the main file menu, or b) to just add it to the save as list? If you seriously answered a, then I think you need some lessons in UI design!

  31. The new ODF to Open XML Translator Project has been getting a lot of attention lately. This is a collaborative…

  32. Como se sabe XML es un formato independiente de la plataforma y del lenguaje, y la adopción que vienen