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.

https://www.mercurynews.com/mld/mercurynews/news/opinion/14543676.htm

"… 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.

https://www.oreillynet.com/xml/blog/2006/05/debunking_the_odf_bunk.html

"… 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.

https://blogs.techrepublic.com.com/Ou/?p=196

"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)!

-Brian

Comments

• Anonymous
  May 12, 2006
  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 :D
  
  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! :D

• Anonymous
  May 12, 2006
  The comment has been removed

• Anonymous
  May 13, 2006
  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

• Anonymous
  May 13, 2006
  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.
  
  -Brian

• Anonymous
  May 13, 2006
  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.
  
  -Brian

• Anonymous
  May 13, 2006
  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.
  

• Anonymous
  May 13, 2006
  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?
  www.ecma-international.org/activities/Office%20Open%20XML%20Formats/TC45_GA_Dez05.ppt
  
  * 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?
  http://openxmldeveloper.org/archive/2006/03/23/79.aspx
  
  * 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?
  http://en.wikipedia.org/wiki/List_of_applications_supporting_OpenDocument#Word_processors
  
  * 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.
  

• Anonymous
  May 13, 2006
  The comment has been removed

• Anonymous
  May 14, 2006
  The comment has been removed

• Anonymous
  May 14, 2006
  The comment has been removed

• Anonymous
  May 14, 2006
  (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. ;)

• Anonymous
  May 14, 2006
  Brian,
  
  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).
  
  

• Anonymous
  May 15, 2006
  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?
  

• Anonymous
  May 15, 2006
  The comment has been removed

• Anonymous
  May 15, 2006
  Brian,
  
  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.
  

• Anonymous
  May 15, 2006
  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. :D
  
  None-the-less...  I digress ;)

• Anonymous
  May 15, 2006
  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 :)

• Anonymous
  May 15, 2006
  The comment has been removed

• Anonymous
  May 15, 2006
  Brian, Excellent!  I'll look forward to your reply :)

• Anonymous
  May 15, 2006
  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 ):
  
  "Recommendations:
  
  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.
  

• Anonymous
  May 15, 2006
  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.
  
  -Brian
  

• Anonymous
  May 16, 2006
  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.
  

• Anonymous
  May 17, 2006
  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.

• Anonymous
  May 17, 2006
  The comment has been removed

• Anonymous
  May 17, 2006
  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'"
  http://news.com.com/2100-1016_3-6072695.html
  
  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?

• Anonymous
  May 17, 2006
  The comment has been removed

• Anonymous
  May 18, 2006
  >>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/ ).

• Anonymous
  May 18, 2006
  > 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.
  

• Anonymous
  March 24, 2008
  PingBack from http://carsmaxblog.info/brian-jones-open-xml-formats-hey-lets-start-talking-about-the/

• Anonymous
  April 01, 2008
  PingBack from http://copyrightrenewalsblog.info/brian-jones-open-xml-formats-hey-lets-start-talking-about-the/

• Anonymous
  May 28, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=brian-jones-office-extensibility-hey-let-s-start-talking-about-the

• Anonymous
  June 09, 2009
  PingBack from http://toenailfungusite.info/story.php?id=1166

• Anonymous
  June 13, 2009
  PingBack from http://outdoordecoration.info/story.php?id=2086

• Anonymous
  June 13, 2009
  PingBack from http://thestoragebench.info/story.php?id=7444

• Anonymous
  June 16, 2009
  PingBack from http://topalternativedating.info/story.php?id=12233

• Anonymous
  June 19, 2009
  PingBack from http://debtsolutionsnow.info/story.php?id=4423