Groklaw - Digging for Truth

Wow! The ODF peasants with pitchforks are have taken to the streets, and ISO document expert Alex Brown is taking them on. The volumes of traffic generated by any discussion of the ISO XML document wars continues to amaze. It's very one sided though. The basic problem seems to be that ISO has accepted two XML document format standards, OOXML and ODF, with OOXML being held to a higher set of expectations than ODF. Alex would do well if he could step back from the OOXML - ODF war, and move the discussion to something like the theoretical IDABC ODEF: the European "Open Document Exchange Formats" design. With ODEF as single set of XML format requirements against which both OOXML and ODF can be measured and compared, Alex might be able to neutralize the heated emotions of angry Open Source - Open Standards - Open Web supporters, who mistakenly think ODF measures up to ODEF expectations and requirements. Trying to compare ODF to OOXML isn't getting us anywhere. At some point, we have to ask ourselves what is it that we want from a standardized XML document format. Having participated in both the Massachusetts pilot study and the California pilot discussions, i have to say that the public expectations were that XML formats would have a basic set of characteristics: open markup; structured separation of content, presentation and logic; high level interoperability (exchange), and Web ready. These are basic "must have" expectations. XML formats were expected to be "better" than 1998 HTML-CSS. But when we apply the basic set of expectations, todays HTML+ (webkit HTML5, CSS4, SVG/Canvas, JS, JS Libs) turns out to be a far better format. Where the XML formats really fall off the wagon are the interoperability and Web ready expectations. For the life of me i don't see how anyone can compare ODF or OOXML interoperability with that of HTML+. And of course, HTML+ is the native language/format of the Web. OOXML is only "interoperable" within the Microsoft platform of applications. ODF interop is simply laughable; with the ever embarrassing and problematic example of exchanging ODF documents between OpenOffice and KOffice - both of which have been anchor participants on the OASIS ODF TC since it's inception. (The application specific Open Office XML format specification was the 2002 foundation of what we now know as ODF. KOffice joined the OASIS ODF TC in February of 2003, less than two months into work on ODF). Neither OOXML or ODF are Web ready formats. Meanwhile, with over 60 billion public documents and another estimated 35 billion behind the firewall, HTML+ is perhaps the most interoperable document format the world has ever known. Sure, there are cross browser problems demanding lots of workarounds resulting in a general dumbing down of document functioanlity - but that's clearly an application implementation problem. As Open Web browsers race to prove their HTML+ compatibility with the webkit weighted ACiD-3 test, the foot dragging of proprietary Web vendors becomes ever more obvious. Clearly we need an ACiD-3 test for XML and HTML+ formats. One geared to measure applications and their documents against the basic expectations. What ODF and OOXML have over HTML+ is the advantage of heavy weight desktop editors. Let's be blunt here. There are no native HTML+ office suite editors. The four primary contenders (MSOffice, OpenOffice, KOffice and WordPerfect) all fail when it comes to native, read/write HTML+. Leading Open Web editors like Google Docs, Zoho, Zooos, and BuzzWord, struggle to achieve acceptable exchange with desktop office suites, instead of delivering the kind of robust webkit HTML+ the Open Web demands. Reuter's Rule kicks in here, and it is harsh and unforgiving; "Conversion breaks documents". Whether this breakage is measured in terms of presentation fidelity, application specific settings, or embedded logic, the breakage is unavoidable. It's a killer, certain to take a business document out of workflow or workgroup process. There is a sad truth behind this situation. HTML was designed to be application neutral. Both of our dominant XML formats however were designed as application specific. 1998 is perhaps a key date here. XML 1.0 was released as a meta-language; a language for writing specific purpose languages. With the release of the XML specification, the W3C began to pull back from further development of HTML and CSS - especially as they might evolve as a structure and presentation markup combo. OpenOffice and MSOffice seized the XML moment, using the meta-language advantages to create application specific XML encodings of their binary document dump. This is not something they could have done with HTML-CSS in 1998. But looking back, one has to wonder what the world would be like today if OpenOffice had decided to eXtend 1998 HTML-CSS, submit the eXtensions to the W3C, and become the world's first native Open Web office suite of editors. It turns out there was in fact many internal discussion at StarOffice, prior to the decision to go with an application specific XML encoding, concerning the creation of a Web browser as part of their suite. Legend has it that these discussions twisted on the costly problem of having to rewrite the internal layout engines of the office suite editors to produce quality HTML-CSS documents viewable in a browser. Excitement over XML, and the simplicity of encoding the binary dump without having to rewrite the layout engines, resulted in an easy decision: drop the browser and forget about the costly problems of native HTML-CSS. The trade off that comes with feature filled but application specific XML is two fold: zero interoperability and Web dead documents. The advantage is that XML can be customized to fit every application, platform and vendor specific nuance known or unknown. With XML formats and data schemas , application vendors are free to drive a desktop to Web to server to device platform convergence in line with whatever business objectives and opportunities the future might present. The problem with these infinitely customizable but application specific XML formats is that the public expects powerful office suites and compliant editors to provide the kind of interop and Web readiness we get with HTML+. And it's simply not there. Nor do i think there is any chance it will ever be there. Perhaps if our first XML format effort had been an application independent eXtension of HTML-CSS-SVG-JS, designed to fully accommodate complex and compound office suite documents, we would find ourselves in a different situation. With two application specific XML formats now sitting as ISO standards, and application specific variations of each XML format sprouting like weeds, i don't think we can ever go back to 2002, and start all over. What's done is done. We have three formats to consider: ODF, OOXML and HTML+. The strengths of ODF and OOXML is that of powerful desktop editors. The weakness of these XML formats is exactly the strength of HTML+: interoperability and Web readiness. IMHO, there are two ways forward; replace or re-purpose the desktop editors. Replacement is beyond costly in that years of business systems and workgroup processes based on client/server architectures has left most business bound to the MSOffice productivity environment. Replacing MSOffice will break these business processes in much the same way as document conversions break these processes and workflows. As every pilot study has demonstrated, replacement is costly and disruptive. Nor does it work to set up parallel Web ready systems; thinking that it's possible to do MSOffice bound business stuff in one suite of editors, while doing collaborative Open Web editing in another. Integrated "value added" Web functionality will trump parallel systems every time. Editing business documents in MSOffice, especially those based on templates, and then trying to collaborate on these documents in Google Docs, ends up being frustratingly counterproductive. Microsoft holds the integration key, and they will use it to leverage their desktop monopoly into a proprietary MS WebStack-Cloud-Ria centered business systems monopoly. The Microsoft "rich-client / rich server" strategy does however depend on the successful re-purposing of MSOffice as a Web front end. In this vision, the MSOffice productivity environment becomes a browser on steroids. For Microsoft, the way forward is clear. They will re-purpose MSOffice to become an editor suite of MS Web documents. Instead of HTML+, Microsoft offers the proprietary and platform specific .NET-WPF technologies that include XAML, Silverlight, Smart Tags, LiNQ, XPS, VML, etc. These proprietary technologies are alternatives to Open Web formats, protocols and interfaces found in HTML+. The thing is, it's entirely possible to re-purpose MSOffice 2003 and 2007 to natively speak Open Web HTML+. This may not apply to MSOffice 11 though. And who knows, maybe somebody will take a close look at the emerging OpenOffice plug-in architecture and discover a means of re-purposing to HTML+? The advantage of this re-purposing approach is that once the powerful editors are able to speak native HTML+, that opens up the desktop to interoperability and collaboration with a world of Open Web editors, browsers and server systems. Exactly what the world expected, but sadly did not get, from the XML format efforts. Hope this helps, ~ge~

Jespers comment has somehow been clipped from this Diigo preview. Here is the full context: The problem with that, as I understand it, is that the transitional spec is pretty much unimplementable by anybody except MS Well, herein lies the problem, dude ... you don't understand it.