Login:
Password:

Microsoft Will Support ODF If It Doesn't 'Restrict Choice Among Formats'

By Scott M. Fulton, III, BetaNews

June 15, 2007, 12:09 PM

In a policy document specifically timed for release this afternoon, Microsoft's general managers for interoperability, Tom Robertson and Jean Paoli, make a play for ownership of the standards issue facing users of competing document formats, by saying the company would support ratification of its own Open XML format along with OpenDocument Format (ODF) as ISO standards, if and only if doing so would promote choice among the world's consumers.

"We should expect the creation of new formats in the future as technology evolves, and, as has always been the case, users should be able to choose the formats that work best for them," reads the team's open letter this afternoon. "Microsoft has consistently supported choice, so it took no steps to hinder ISO/IEC's ratification of ODF 1.0 and supported ODF 1.0's addition to the American National Standards list. Microsoft will continue to support recognition of ODF 1.0 and other formats on such lists around the world as long as doing so in no way restricts choice among formats."

In their letter, Robertson and Paoli paint a picture of the open source ODF format as perhaps trying to monopolize the standards process, by virtue of having claimed the "open" mantle first, though standards judges may be selectively unaware of the fact that Microsoft Office includes the applications chosen by most of the world's computer users. Certainly there's a place for ODF in the world, the interoperability team continues, and users are free to make that choice for whatever reasons they'd want to do so.

"ODF's design may make it attractive to those users that are interested in a particular level of functionality in their productivity suite or developers who want to work that format," they write. "Open XML may be more attractive to those who want richer functionality, the ability to integrate business data into their documents by defining their own document schema, or a format that was designed to be backwards compatible with existing documents. This is not to say that one is better than the other - just that they meet different needs in the marketplace.

"It is not unlike how some people wanting to travel from one place to another will choose an automobile and others will choose to fly," the letter continues. "Both are modes of transportation but they are fundamentally different and serve different communities, just as ODF 1.0 and Open XML are both document formats, but are fundamentally different, meeting different needs among users."

Just as the automobile can co-exist with the airplane, ODF and Open XML can and should co-exist, the team writes. They go on to imply that standards agencies should not place themselves in a role similar to restricting transportation solely to the ground level.

The letter concludes by citing Novell, Apple, Toshiba, the Library of Congress, and others for having backed the ratification of Open XML as an ECMA standard. "ISO/IEC is now in a position to ratify that strong work and provide additional choice among the formats that it recognizes," Paoli and Robertson write. "We and a growing community of users and vendors support that step."

In an exclusive interview with BetaNews, Tom Robertson told us Microsoft perceives the standards process as one of four "toolsets" the company uses to achieve interoperability among protocols and formats. But when the standards process fails, he said, the other three "toolsets" could be relied upon as a backup plan.

Standards, Robertson told BetaNews, "are a very important tool to use to address interoperability. But I would note that they're not the only tool, and they may not be the most appropriate tool in a particular set of circumstances. An example there would be where you have a cycle of innovation that's more rapid than the cycle of standardization. In that case, I do wonder whether standardization is the most appropriate way, and shouldn't you look to some of the other tools that you have available to you, to address interoperability?

"But I don't want to diminish the role of standardization," Robertson continued. "Microsoft has acted in hundreds of standardization activities around the world every year, and implements thousands of standards in its products. It's really important, and we'll continue to develop and refine our work in the standards space going forward."

More from our interview with Tom Robertson, general manager of interoperability and standards at Microsoft, later in BetaNews.

Add a Comment (11 Comments)

BetaNews reserves the right to remove any comment at any time for any reason. Please keep your responses appropriate and on topic. Foul language and personal attacks will not be tolerated.

Name (required):

E-mail (required):

Enter Your Comment:

By xyzcb1

posted Jun 18, 2007 - 10:21 AM

When did standard ever matter to the one who has the most market share? I don't understand why MS bother with this ISO standard, just go its own happy way.

Just look at the United States, did they ever give a sh!t about ISO?

Score: 0

By LleMikeByw

edited Jun 17, 2007 - 12:23 AM

It is relatively simple.

An "Open Standard" is one that EVERYBODY can use - to edit a document, put in special effects, Format, Save, Open, Append to, etc. - and ensure the document can be viewed and amended by other users without requiring conversion tools or losing any of the original structure or content (unless deleted, of course).

An "Open Standard" Document OBVIOUSLY needs to exist as an Object independent of the tool which is used to create, view, amend etc.

ODF would seem to fit that criteria whereas Open XML appears to require proprietary Microsoft tools for the viewing or amendment of the original.

If Microsoft wishes interoperability with THE "Open Standard" then the neatest solution is for Microsoft to provide functionality within it's own packages that allows a Microsoft user to create using the full "power" of it's proprietary OXML while subsequently allowing writing to the ISO-ratified ODF Open Standard.

The object of that yet-to-be Microsoft-implemented functionality within it's own packages, to ensure that an author using a Microsoft tool to publish a document has the widest possible audience.

The author/collaborator is likely to be unconcerned about the tool used to view/amend his/her work - and to be more concerned that it is viewed/amended as he/she originally intended and so that he/she can read it again.

OXML ties the observer to Microsoft viewing and edit tools.

ODF does not.

Therein lies Microsoft's vexation.

Score: 0

By zridling

edited Jun 15, 2007 - 10:24 PM

According to Paoli and Robertson, standards are important, as long as it's not ODF. Odd, the sheer number of outright lies these two tell in this report. As Rob Weir says:

[Microsoft] seems to be suggesting that increasing the number of different formats and translators leads to an increase in interoperability. This is akin to saying that increasing the number of umbrellas improves the weather. It just doesn't work that way.

We need to step back and find the proper metric. If, for sake of argument, we define interoperability as the ability for different formats to work together, then obviously as we increase the number of formats and the number of translators then the sum total of interoperability (by that definition) in the world increases. In that case, let's make the old 1-2-3 format an ISO standard, the WordPerfect format an ISO standard, WordStar an ISO standard, XYWrite an ISO standard, Quattro Pro an ISO standard, Manuscript an ISO standard, Harvard Graphics an ISO standard, Freelance Graphics an ISO standard, etc. Just imagine how much interoperability we could have in the world if we simply could standardize more formats. Every application, could have its own standard format, or maybe two or three.

But you may smell a rat in the above argument. Interoperability of formats is not the appropriate metric. A simple look at the lack of OOXML support on the Microsoft's Mac Office shows that the introduction of OOXML has reduced interoperability, not increased it. Similarly, scientific journals like Science and Nature have already come out saying that they cannot accept the OOXML format. Translation among multiple formats only partially and imperfectly attempts to work around a break-down in interoperability caused by having multiple formats. It is a band-aid approach and does not address the core issue.

A more appropriate metric than counting piles of semi-functional translators is to look at things from the perspective of the user exchanging documents. The end user doesn't see or care about formats. They care about their documents and the people and processes that work with these documents. The question for them is: what is the cost to exchange their document with other users and business processes? In other words, what is the cost to interoperate? That is the metric that counts.

Several cost drivers come into play here:
(1) What are the choices and costs in application software necessary to author a document?
(2) What are the choices and costs in application software needed by the recipient of this document, in order for them to read it, or collaborate with me in editing this document?
(3) Will others see the document as I intended? Or will there be fidelity loss from conversions?
(4) Similarly, what are the performance, security, stability, legal and licensing implications of introducing any translation steps?
(5) How easy is it to program this document format? In other words, what is the cost of business process integration?

When looked at from this business perspective, we can get away from counting piles of dead rats and thus come to a quite different conclusion:

None of the cost-driver factors lead to reduced costs with multiple formats. They all have minimal costs when there is a a single format in use. So if the metric for interoperability is the "cost to interoperate", then interoperability (and choice as well) is maximized when a single application-neutral and platform-neutral document format is natively supported by multiple applications at a range of price/function points. Introducing even a single additional format into your business will escalate costs, degrade fidelity of document exchange, and reduce interoperability.
________________________________________________
Also, for all of Microsoft's interoperability hype toward ODF, let's look at what has been normative in Windows:

Windows shell integration
(1) Double-click on a document on the Desktop or in a folder and it loads into the appropriate application. Double-click on a Word document and it loads in Word.
(2) Right-click in a folder and choose “New XXX” to create a new XXX document in the specified folder. So, "New...Microsoft Office Excel Worksheet" creates a new, blank Excel document.
(3) Right-click on a document, choose Properties and on the Summary tab you can view metadata for that document.
Recently-edited documents appear in the “My Recent Documents” under the Start menu.
(4) Documents referred to in web pages, via URL links will render in an inline Office session in the browser.
(5) Documents are indexed by the Windows search engine.

Office integration
(1) Ability to File/Open, File/Save and File/New a document via the familiar menu options.
(2) Ability to set a file format as the default file format for the application.
(3) Ability to use the familiar keyboard shortcuts, Control-O and Control-S to open and save documents.
(4) Ability to forward a document to someone in an email and for them to be able to launch the a document by clicking on it when received via email.
(5) Ability to password protect a document.
(6) Ability to post a document to a web folder or to a SharePoint server

It must be noted that none of the above integration points are allowed by the ODF Add-in for Word, the much-touted translator for which Microsoft provides the, "Funding, Architectural & Technical Guidance and Project co-coordination."
________________________________________________
So please, Microsoft, let's stop with the trains, planes, and automobiles sophistry. MS-OOXML is nothing more than a Microsoft "product" specification, not a universal format for office data. We already have backward compatibility with .doc, and even MS-OOXML doesn't provide .doc fidelity!

Score: 0

By asellus

posted Jun 16, 2007 - 12:20 PM

Basically, what Rob Weir say is that multiple ISO certifications for document format is bad.

I call bullsh*t.

There are multiple ISO certifications in image formats like JPEG and PNG which both are certified by ISO. Did you see the sky falling? Not exactly right?

More choices is good. A lock-in into only one ISO document format (ODF in this case) is not good for everyone out there. Competition is always good.

Anyway, ODF is not that easy to implement without looking at OpenOffice messy source code, just ask the guys at AbiWord. AbiWord get around the problem by using converters, just like Microsoft Word do. And if a GPL software like AbiWord does not even want to implement ODF natively, what does that say for ODF?

ODF is just as hard to implement from documentation alone just like Open XML, if not harder.

Score: 0

By PC_Tool

edited Jun 16, 2007 - 6:59 PM

He's an MS troll. Choice is good, so long as it isn't Microsoft. Then, suddenly, choice is bad, up is down, and pasting quotes from "experts" (Rob Weir means you actually know what you're talking about.

Some people just don't like to live in this place we like to call Reality.

Score: 0

By zridling

edited Jun 17, 2007 - 3:38 AM

Toolie, your blind loyalty to all things Microsoft is a source of endless humor to me. I don't think reality means what you think it means. As for Asellus, you obviously not serious when you say "ODF is not that easy to implement without looking at OpenOffice messy source code, just ask the guys at AbiWord." Somehow you guys believe the Microsoft lie that ODF is tied to OpenOffice, but don't let facts get in your way — a good ol' amerikan corporation wants you stupid, ignorant, and proud to ignore facts.

Weir is simply saying, if two ISO office formats are good, why not 3, 4, 6, 12? Wouldn't 22 be better than 2, by Microsoft's illogic? Why should we stop at MS-OOXML? And for that matter, why doesn't Microsoft submit the ubiquitous .doc format for ISO certification? What are they afraid of?

I can't wait to hear your wailing and screaming when MS-OOXML gets rejected in September. Meet you back here. Oh, and meanwhile, keep paying that Microsoft tax — they love it when you put the handcuffs on yourself after they've emptied your wallet!

Score: 0

By asellus

posted Jun 17, 2007 - 3:36 AM

22 ISO standards is better than only 2. Choices is always better. If we have that, the competition will be much better, and end-users will greatly benefit from it. Multiple ISO standards in any field has never been shown to be a bad thing. Music and picture formats thrives with multiple ISO standards, why it will be different with office document format?

AbiWord developers are the ones who first realized that implementing ODF support without referencing OpenOffice source code is very hard. That's why they use converters just like Microsoft does. With OpenOffice LGPL license, surely a GPL software like AbiWord can easily reusue OpenOffice code right? Unfortunately, the reality is hard. ODF is hard to implement without looking at OpenOffice source. Show me one word-processing software that support ODF natively (100%) and does it without looking at OpenOffice source code. The only one I know is KOffice, and they did look at OpenOffice source and their implementation is not even complete!

Fact: ODF is hard to implement, if it that easy we would have been looking at multiple implementations already. Only big companies like Sun or Google will be able to implement ODF correctly, smaller ones will be left to the dust.

Open XML is the doc format. It even has specification on how to deal with one-way conversion of doc format back to Office 97. Although it will be hard to implement of course just like ODF is.

Score: 0

By zridling

posted Jun 17, 2007 - 4:03 AM

One reason for the 6000+ page length, complexity, and numerous contradictions of MS-OOXML is its failure to use existing ISO standards. Do we have two "standards" of grammar? Why not speak Spanglish in business settings? In memos? In research papers? Do we have multiple metric standards? If not, why not? (Think about it, it's really obvious.) Besides the inherent proprietary dependencies of Microsoft's so-called "open" standard, two things right off the bat that Microsoft fails to recognize in MS-OOXML are SVG and MathML W3C — both ISO standards. So now you think Microsoft should be able to not only create its own standard out of a mere "product specification," but should use its own standard to openly contradict and ignore existing standards?

You might as well speak your own private language.

Not a single vendor has implemented MS-OOXML except Microsoft. And it will remain so. On the other hand, as of now, the following use ODF as either their native file format or allow you to:
— AbiWord
— StarOffice
— OpenOffice
— Google Docs & Spreadsheets
— Zoho Office
— KOffice
— NeoOffice
— TextMaker

with WordPerfect coming. I'm pretty sure that Google Docs, Zoho Office, and NeoOffice did not need or access OpenOffice code to implement ODF. ODF is independent of the program; in fact, it's controlled by OASIS, not Sun or IBM.

BALD-FACED LIE: "ODF is hard to implement."
Eight and counting to only one for MS-OOXML, and MS-OOXML has been finalized for well over a year now — what's taking everyone so long to write simple converters? Even Microsoft absolved itself of that duty in order to deflect criticism when they didn't work, as we know the MCAN one doesn't. Given the numbers alone, I'd say that ODF is eight times easier to implement, especially little players like AbiWord, Zoho, TextMaker, KOffice, and NeoOffice are able to implement it on their own (and as a native file format, at that). If they can, why can't big ol' Microsoft, if they're so "open" now?

MS-OOXML is not the .doc format. Maybe you don't use Office 2007, but when you save a document, you're given a choice to save as either .doc or MS-OOXML — MS-OOXML is the native, .doc is the alternative, and neither is compatible with one another. When you run Office 2007 in compatibility mode (when it reads .doc files), it tells you that there are a large number of page and spreadsheet elements that cannot be saved in .doc format.

Here is what MS-OOXML looks like when printed, all 6,000+ pages. What ISV or other vendor has the time, programmer resources, and money to fully implement Microsoft's "product specification"?

I promise you that a year from now we can have this same conversation, only ODF adoption will continue to expand while the MS-OOXML converters are still trashing documents all over the landscape.

Score: 0

By asellus

posted Jun 17, 2007 - 4:42 AM

Abiword does not support ODF natively. Conversion is what they do. Did you ever use it? And KOffice also does not use ODF if your document are complex, and will ask you to save in their own format especially in word processing and presentation. Did you ever use these 2 software? I bet you don't. Come to me when you actually use those software you listed instead of using Wikipedia as your source.

The fact that you say NeoOffice does not use OpenOffice code to implement ODF shows that you never use those software you mentioned. NeoOffice use OO code, what the hell you think NeoOffice is anyway? A port of OpenOffice for god sake. Do some research first please.

The only good ODF implementation is OpenOffice.

OOXML may not support SVG, but they did support MathML. Suprisingly they converts MathML to images though when converting to Office 2003 and before that. I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy.

Score: 0

By Marbux

posted Jun 19, 2007 - 3:16 PM

Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy."

I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not.

I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf

Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification. E.g., there is a single minor tag in Ecma 376 for Sharepoint Server, apparently left in by accident from Microsoft's own documentation. All of the other tags needed for interaction with Sharepoint Server are omitted.

As to the supposed difficulty of implementing ODF in MS Office, you might consider what former Massachusetts Secretary of Administration & Finance Eric Kriss said: "… technical people at Microsoft told him it would be 'trivial' to add support for ODF to the new Office 2007. The resistance to doing so came from the vendor's business side, according to Kriss." http://www.computerworld...273815&pageNumber=2

Asellus' point about Abiword using file conversion in its implementation of OpenDocument is just plain silly. Any legacy application will use conversion to implement new file formats, absent a complete rewrite of its page rendering engine. E.g., OpenOffice.org uses conversion to implement ODF; Microsoft Office uses conversions to implement MOOXML (and HTML, RTF, WPD, and several other file formats).

As to the notion that competing standards are a Good Thing, that could only be said by someone who is either a fool or being dishonest. Ever got that "file type not supported" error message from your operating system? That is the only benefit of competing standards.

None of this is to say that OpenDocument is perfect. Far from it. OpenDocument at present is crippled from an interoperability standpoint. I'm a member of the OASIS OpenDocument Technical Committee and I think the resistance of the big vendors to fixing the interoperability warts is simply outrageous, particularly because they are fairly trivial changes.

But the advancement of software users' interests are not advanced by painting OOXML as other than deeply flawed. It is vendor-specific and far from "open." The lesser of the two evils is clearly OpenDocument, which is at least open even if not yet interoperable.

The sooner folks can start discussing practical methods of convergence, the better. See e.g., http://ec.europa.eu/idabc/servlets/Doc?id=27956

That set of slides summarizing a conference of some 20 European national governments' IT types says a lot more about the future of office document formats than Mr. Asellus has to offer.

Score: 0

By JRT

edited Jul 27, 2007 - 8:06 PM

One thing about document formats is clear. It appears to be a natural monopoly.

This is made worse by the tendency of users to distribute completed text documents in the native formats of wordprocessors rather than using RTF or PDF.

Unfortunately, the only cure for the problem (a natural monopoly) is government action. Since it is a large customer, the government can probably do this without regulations by driving the market by demanding that the *native* format for any wordprocessing software that it purchases be an approved ANSI/ISO standard.

Score: 0