But be careful taking this argument too far As we’re happily discussing over on xml-dev, (X)HTML + CSS works just fine for this kind of simple, static, everyday document, and there are a bazillion commercial, open source, or free beer products available to produce (X)HTML. Furthermore, HTML is undeniably the most popular standardized document format in the world. If you don’t worry about the “corner cases” that HTML doesn’t cover, ODF doesn’t have much of a leg to stand on either.

But more importantly, the data-oriented corner cases are quite significant in a goodly number (if not percentage) of real-world customer scenarios that Jean Paoli is very happy to tell people about. Do you really want to argue that these aren’t worth supporting? Likewise, “information integration” of enterprise data and documents is almost certainly as much of a growth industry behind the firewall as “mashups” of public data are in “Web 2.0″.

All I’m arguing, and I think all the MS Office people are arguing, is that people should be encouraged to use the right tool and format for the job and not try to fit everything into a single “standard” and lop off the corner cases. (X)HTML has a role to play for sure, ODF will probably develop a significant base as products that support it are actually deployed, the Office 12 formats will almost certainly be considered sufficiently powerful, open and standard for a large segment of the market, and there’s always things like DocBook available for real high-end documentation needs. Furthermore, customized XML formats that meet a specific organization or industry’s needs will be increasingly used, IMHO, as XML tools mature enough to make this feasible for non-geeks. All these should be allowed in the toolkits of enterprise and government developers, even if any one of them could cover all but some “corner cases.”

I don’t pretend to be making a detailed technical analysis of why one format or the other is better for this use case. I’m just pointing out that Brian/Jean talk about the data-oriented business document scenario a lot, and Tim focuses on documents that are just text and markup in making his argument that ODF should be the one and only “standard” in this domain. I’m also pointing out that the choice of RELAX NG makes ODF well-suited for “text” documents, but doesn’t have the wide range of tool support for data-oriented work (e.g. binding XML to programming objects or database tables) that mainstream developers rely on.

http://xml.coverpages.org/XMLForTheMasses.pdf

If you’re a ruthless monopolist with a long and sordid history of corrupting standards to further your control over the marketplace, this kind of FUD is almost too easy. Besides, the ruthless monopolist has a very different approach to file formats than one would find with open source and open standards initiatives. The monopolist is forever seeking ways of tying, bolting and binding the file format to specific applications using arbitrary and quite artificial software dependencies. The open source – open standards effort of course tries to separate the file format from the applications. Software dependencies, especially the binary kind, are the kiss of death for an open, portable, cross platform, application independent file format.

So what we have here are two very similar XML file formats, ODF and MSXML, that spawn from two very different objectives. The ruthless monopolist tries to lock their MSXML to the Windows XP stack, ever finding new and inventive ways to bolt end user information and information processes into a cascading entanglement of interdependencies binding the Windows XP desktop to suites of XP servers. There is nothing independent or portable about MSXML. Okay, so they submit the spec to ECMA. Aside from all the legal gotcha’s and intentionally vague fine print, Microsoft has moved their point of control from the specification to the packaging format. Of course by doing this they can now claim that MSXML complies with current marketplace demands for a truly open XML implementation. But by shifting their control point to the packaging, a whole new set of complaints will ensue. How much longer can this endless game of whack-a-mole to go on?

Want proof that MSXML breaks the XML promise? Not even the mighty monopolist can perfect a transformation between MSXML and ODF, and that breaks the most basic promise of XML – the promise of highly inter operable interchange of information. If it’s real XML without the dependencies, then show us by perfecting a clean, clear transformation.

Yes, it is true that MS Office and open source cross platform champions OpenOffice.org and Mozilla have reached “parity” as far as desktop productivity environments are concerned. This parity is generally described as having 80% or more of the feature set, but having 100% of those features most used and most important. Let’s say for the sake of a good argument that OOo has 95% of the MS Office feature set The missing 5% might be superfluous features that no one uses, but nevertheless, one could honestly argue that OOo the application is comparatively “technically insufficient”. Okay, so the next step is to lay out the missing 5% of features, analyze them for their importance to specific information processes needed by users, and determine a bang for the buck ratio. OOo probably would win this comparison 95% of the time (if not for the endless flood of FUD). But the monopolist could still say that OOo is “technically insufficient”.

But here’s the thing. The “technical insufficiency” of OOo has nothing to do with claims that ODF, the file format, is “technically insufficient”. ODF was designed to be application independent, with the recognition that some applications will need to reflect in the file format highly focused but “limited” application services. Other applications like OOo and MS Office, will need the file format to cover the entire desktop productivity environment as well as the highly interactive collaborative computing space.

ODF was designed to be both scalable and eXtensible. The file format is able to handle the comparatively limited needs of highly focused, single purpose applications, the very broad universal transformation layer needs of legacy systems being merged into SOA’s, and, the needs of that global googlespace where desktop productivity environments are rapidly evolving to mesh with highly interactive collaborative computing efforts.

If the “technically sufficient” aspects of MS Office can be expressed in MSXML, i damn guarantee you that they can be expressed in ODF. As Tim bray said, “That’s what namespaces were invented for”. The X in XML stands for eXtensible.

Does this mean that the vaunted MS Office developers are “technically insufficient”, quite unable to understand XML? No. It simply means that the monopolist business objectives are focused not on interoperability, but on maintaining control of the marketplace, keeping the upgrade treadmill churning by artificially tying applications to proprietary file formats, and continuing the anti competitive extortion of obscene profits.

Based on their bastardized implementations, one could easily argue that MS Office developers don’t understand HTML, and are “technically insufficient”. When Microsoft set out to murder Netscape, and claim the Open Internet browser space for their own, they raced to submit new HTML features to the W3C. They needed that “Open Standards Compliant” imprimatur. As soon as they no longer needed that stamp of compliance and good citizenship, Microsoft forked off with a bastardized entanglement of HTML extensions and implementations that broke the Open Internet into two separate camps. One side of the Open Internet was owned and controlled by Redmond. The other side set adrift, wondering how this could have happened.

XML is the Web 2.0, and what the monopolist is trying to do now is really not that much different from what they did to HTML and Java. Yes the stakes are much higher. The players are different. But it’s the same ole “embrace, eXtend, eXtinguish” game plan.

After all we’ve been through, and all the reprehensible things we’ve seen, who in their right mind would trust the monopolist to finally be doing the right thing?

Besides, in the long run none of this treachery, deceit, and gotcha whack-a-mole will matter. It’s not about the desktop. It’s about the Open Internet. The XML file formats are just a means of bridging desktop productivity environments into the Open Internet and the age of interactive collaborative computing. Whether you’re working on a local SOA, or a global Service Oriented Open Internet Architecture, it’s still the same. Like other legacy information systems, the effort is to include legacy desktop productivity environments.

As one wag cleverly stated, “Microsoft is stuck on C Drive”. They can’t seem to break the personal computing orientation and make that leap to the Open Internet. Their dilemma is perhaps due to the fact that they have yet to figure out how to seize, control, and “own” the Open Internet. But they keep trying. MSXML is just the latest effort.

So who is it that has figured out the Open Internet? Google has. Instead of trying to control the Open Internet, Google set out to organize mankind’s information using the Open Internet. They’ve been so successful at this that it’s hard to separate Google organization services from the Open Internet. They have accelerated the speed at which information moves across the global infogrid, they have greatly increased accessibility to that information, they have exponentially increased the volumes of information available, and, they are ever seeking more clever ways to escalate interactive participation – which increases the value of information.

ODF has the potential to deliver Microsoft to Google, and do so on a silver platter. The reason is that XML is directly in the business objective line of fire for Google. For Microsoft however, XML is the end of monopolist control over information.

If you’re in the business of organizing Open Internet ready information, XML is it. From the universal metadata model, through the highly structured presentation and content model, to the bridge between XML:RDF where tagging of “conceptual relationships” becomes possible, ODF is going to transform vast volumes of information – perfectly structured for Google to apply the awesome power of their processing and storage capabilities. If ever there will be a moment in time where Moore’s Law merged with Metcalf’s Law, this is it. This is Google’s game to win or lose. If they choose ODF, it’s all over but the shouting. It won’t matter what ECMA, ISO, Massachusetts, or even what the W3C does. With the Open Internet, it’s not about the desktop marketshare. It’s about the information.

~ge~

I’m not part of the MS Office team, but I believe that the developers that they are targeting are not the *internal* MS developers but *external* developers who need to do ordinary things like write small apps that complement MS Office or write integrations with enterprise systems and databases. In all those scenarios, reducing the impedance mismatch with OO languages and RDBMS is a more important technical goal than alignment with the mainstream XML technologies.

The other technical issue that Tim Bray’s posts and the Groklaw article ignore is the importance of data as well as text in an office document. “Almost all office documents are just paragraphs of text, with some bold and some italics and some lists and some tables and some pictures” http://tbray.org/ongoing/When/200x/2005/11/27/Office-XML. That’s certainly true of the majority of actual Word, etc. documents out there, but not true of the ones that are going to be processed by 3rd party developers. Ordinary text/table/image documents are pretty much exclusively for human consumption; it hardly matters what XML or (X)HTML format they’re in so long as there is a stylesheet to render them in a reasonable human-readable form. The more interesting documents, and the ones I hear Brian Jones and Jean Paoli talk about, are what one might call operational business documents, with a combination of human-readable text and machine processable data. As I understand it, the technical design of the MS Office formats focuses on the needs of documents that contain live *data* from external sources or create *data* for downstream processing. I don’t get the sense that this was a major design consideration for ODF, as shown by their use of the document-oriented RELAX NG schema language rather than the more data-oriented W3C schema language that MS Office supports.

Finally, I’ve heard Brian Jones address the question of why the Office XML default formats are so ugly: It’s because they’ve learned over the many years that they’ve been working with HTML and XML representations of Office documents that the most important criterion that real users value is the user experience in the office application. Users want the document to “remember” where they left off editing, what the zoom level they had previously set, and so on. All that makes for ugly markup, but it can be safely ignored by those with no incentive to dive deep into the documentation to figure it out. That “state of the editor when the document was saved” information would be lost in translation to PDF, ODF, or whatever anyway.

Are there are any others? The unnamed person you quote offers nothing.

OTOH, I think there’s perfectly valid technical arguments to make on the other side. See here for one take:

http://www.groklaw.net/article.php?story=20051125144611543

I gave some context on the article here:

http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2005/11/26/anatomy-of-xml-office-formats

I contributed to it because I frankly got tired of hearing the anti-ODF FUD.