OpenDocument's feed | Diigo Group

Is HTML in a Race to the Bottom? A Large-Scale Survey of Open Web Formats

Fri, 18 Apr 2008 17:53:06 -0000

Highlights and Sticky Notes:

The "race to the bottom" is a familiar phenomenon that occurs when multiple standards compete for acceptance. In this environment, the most lenient standard usually attracts the greatest support (acceptance, usage, and so on), leading to a competition among standards to be less stringent. This also tends to drive competing standards toward the minimum possible level of quality. One key prerequisite for a race to the bottom is an unregulated market because regulators mandate a minimum acceptable quality for standards and sanction those who don't comply.^1,2 In examining current HTML standards, we've come to suspect that a race to the bottom could, in fact, be occurring because so many competing versions of HTML exist.

At this time, some nine different versions of HTML (including its successor, XHTML) are supported as W3C standards, with the most up-to-date being XHTML 1.1. Although some versions are very old and lack some of the newer versions' capabilities, others are reasonably contemporaneous. In particular, HTML 4.01 and XHTML 1.0 both have "transitional" and "strict" versions. Clearly, the W3C's intent is to provide a pathway to move from HTML 4.01 to XHTML 1.1, and the transitional versions are steps on that path. It also aims to develop XHTML standards that support device independence (everything from desktops to cell phones), accessibility, and internationalization. As part of this effort, HTML 4.01's presentational elements (used to adjust the appearance of a page for older browsers that don't support style sheets) are eliminated in XHTML 1.1.

Our concern is that Web site designers might decline to follow the newer versions' more stringent formatting requirements and will instead keep using transitional versions. To determine if this is likely, we surveyed the top 100,000 most popular Web sites to discover what versions of HTML are in widespread use.

The summary statement glosses over the value of a highly structured portable XML document. A value that goes far beyond the strict separation of content and presentation. The portable document model is the essential means by which information is exchanged over the Web. It is the key to Web interop.

Up till now, Web docuemnts have been very limited. With the advent of XHTML-2, CSS-3, SVG, XForms and CDF (Compound Document Framework for putting these pieces together), the W3C has provisioned the Web with the means of publishing and exchanging highly interactive but very complex docuemnts. The Web documents of the future will be every bit as complex as the publishing industry needs.
The transition of complex and data rich desktop office suite documents to the Web has been non existent up till now. With ISO approval of MSOffice-OOXML, Microsoft is now ready to transition billions of business process rich "office" documents to the Web.
This transition is accomplished by a very clever conversion component included in the MSOffice SDK. MS Developers can easily convert OOXML documents to Web ready XAML documents, adn back again, without loss of presentation fidelity, or data. No matter what the complexity!

The problem here is that while MSOffice-OOXML is now an ISO/IEC International Standard, XAML "fixed/flow" is a proprietary format useful only to the IE-8 browser, the MS Web Stack (Exchange, SharePoint, MS SQL, and Windows Server), and the emerging MS Cloud.

Apache, J2EE, Mozilla Firefox, Adobe and Open Source Servers in general will not be able to render these complex, business process rich, office suite documents. MSOffice-OOXML itself is far to complicated and filled with MS application-platform-vendor specific dependencies to be usefully converted to Open Web XHTML-CSS, ePUB or CDF.

XAML itself is only the tip of the iceberg. The Microsoft Web Stack also implements Silverlight, Smart Tags and other WPF - .NET technologies not available as open standards. Silverlight is a proprietary alternative to SVG and Flash technologies. Smart Tags and the LINQ meta search mechanism are alternatives to RDF, RDFa and SPARQL. And of course, XAML "fixed/flow" is a proprietary alternative to advanced XHTML-CSS, CDF, iPAPER, FlashPaper and PDF.

Web formats are important. This survey sadly only begins to scrape the surface of the interoperability problems the future of the Open Web faces. ISO approval of MSOffice-OOXML is going to initiate a great transition of legacy client/server business process systems to a new model of highly efficient, barrier free and cloud ready client/ Web-Stack /server systems.

Hope this helps,

~ge~
posted by garyedwards

Tags: cdf css html ooxml xaml xhtml

Posted by: garyedwards

Compound Document Formats Group Charter

Fri, 07 Mar 2008 23:51:10 -0000

Highlights and Sticky Notes:

be widely implementable in browsers and authoring tools

Tags: cdf da-vinci foundation opendocument w3c

Posted by: garyedwards

Unbreaking the Web: IE 8 passes ACID 2 Test | John Resig

Fri, 07 Mar 2008 22:17:38 -0000

Highlights and Sticky Notes:

IMHO, the key to Microsoft's OOXML strategy can be seen in the recently released MSOffice SDK. The SDK provides a component for the fluid conversion of OOXML to something called fixed/flow. The fixed part of this interesting conjunction is also known as XPS, which is designed as a proprietary alternative to PDF. The flow part is a fascinating and highly proprietary replacement for (X)HTML - CSS.

Reading further through the MSOffice SDK, one can't help but be amazed at the lack of W3C technologies; especially (X)HTML, CSS, XForms and SVG. What we have instead is an entangling cascade of stuff like OOXML, fixed/flow, silverlight, XAML, and WPF. And then there is that recent promise of other high volume API's probably delivered through future Exchange, SharePoint, and MS SQL Server SDK's.

So, at the end of the day, what are we looking at here? IMHO, Microsoft has figured out that the smart thing to do is leverage and extend their existing desktop monopoly into the next generation of cloud computing where the Internet platform rules.

To pull this off, they have a number of problems to overcome; not the least of which is that they need to catch a break on anti trust, and, get OOXML through ISO. And oh yeah, there's that little problem that Windows can't do cloud computing.

Tags: cdf css iso microsoft odf ooxml w3c xhtml

Posted by: garyedwards

Putting Andy Updegrove to Bed (without his supper) | Universal Interoperability Council

Wed, 06 Feb 2008 03:53:47 -0000

Highlights and Sticky Notes:

In late 2007, an article by OASIS attorney Andy Updegrove claimed that W3C Compound Document Formats: [i] are non-editable formats; [ii] are not designed for conversions to other formats; and [iii] are therefore unsuitable as office formats. Updegrove could not have been more wrong.

But unfortunately, the erroneous Updegrove article was widely publicized by the usual occupants of the IBM cheering section⁽¹⁾ in the stadium where the latest big vendor game for the Incompatible File Format Cup is being played, IFFC Games Stadium.

Tags: cdf ibm interop oasis odf ooxml opendocument openxml

Posted by: garyedwards

Harmonization and Interop: The dizzying dance of ODF, OOXML, and CDF

Wed, 06 Feb 2008 03:49:40 -0000

Highlights and Sticky Notes:

With the ISO BRM fast approaching, the harmonization of ODF and OOXML is all the rage. The legendary marbux takes on this discussion arguing that ODF and OOXML both lack the interoperability framework needed to meet ISO directives describing interop requirements. He argues that interop between MSOffice and OpenOffice can be achieved using CDF.

Tags: cdf ibm interop oasis odf ooxml opendocument openxml uic w3c

Posted by: garyedwards

IBM's Director of Strategy comes clean on OpenXML - IBM WILL support OpenXML in its Lotus and Portal products - Notes2Self.net

Fri, 25 Jan 2008 09:01:29 -0000

Highlights and Sticky Notes:

Well, if that's IBM's plan they're going to need more than ODF, that's for sure - and that brings us to the announcement I've been wondering about:

IBM favors ODF as a file format because it is "truly open" and technically elegant, Heintzman said.
But IBM will support Open XML, which is the current document format in Office 2007, in its Lotus collaboration and portal products. IBM already supports older versions of Office.

I feel a Pamela Jones moment coming on .... there it is, as plain as day for the world to see, Doug Heintzman breaks through all IBM's doublespeak and hypocrisy and admits it.

I don't know about "Beyond Office" as a plan, I think the real game here is "Beyond ODF"

Tags: cdf heintzman ibm odf ooxml openxml

Posted by: garyedwards

IBM’s Stance Against OpenXML Is Increasingly Confusing : Oliver Bell’s weblog

Fri, 25 Jan 2008 09:01:29 -0000

Highlights and Sticky Notes:

Events have played out in the media and in the blogosphere over the last couple of weeks that represent a breakdown of some of those anti-OpenXML arguments that have been played back so frequently over the last year.

Arguments that there is a lack of demand for Open XML, the specification is too complex to implement, the specification can’t be deployed cross platform and the long running but baseless claim that the Ecma-376 specification might be encumbered by IPR and patent threats all appear to have been cast aside as big blue steps up to meet the demands of their own customers and the market in general.

Here is a blow by blow review of the relevant activity over the last two weeks…

Tags: cdf heintzman ibm odf ooxml opendocument openxml symphony weir

Posted by: garyedwards

Independent study advises IT planners to go OOXML | A pos on both your houses!

Fri, 25 Jan 2008 09:01:28 -0000

Highlights and Sticky Notes:

What you've posted are examples of MSOffice ”compatibility settings” used to establish backwards compatibility with older documents, and, for the conversion of alien file formats (such as various versions of WordPerfect .wpd). These compatibility settings are unspecified in that we know the syntax but have no idea of the semantics. And without the semantic description there is no way other developers can understand implementation. This of course guarantees an unacceptable breakdown of interoperability.

But i would be hesitant to make my stand of rejecting OOXML based on this issue. It turns out that there are upwards of 150 unspecified compatibility settings used by OpenOffice/StarOffice. These settings are not specified in ODF, but will nevertheless show up in OpenOffice ODF documents – similarly defying interoperability efforts!

Since the compatibility settings are not specified or even mentioned in the ODF 1.0 – ISO 26300 specification, we have to go to the OOo source code to discover where this stuff comes from. Check out lines 169-211. Here you will find interesting settings such as, “UseFormerLineSpacing, UseFormerObjectPositioning, and UseFormerTextWrapping”.

Tags: application-specific cdf ge odf ooxml pox

Posted by: garyedwards

A gadfly's take on IBM's 'support' for Open XML | Computerworld Blogs

Fri, 25 Jan 2008 09:01:28 -0000

Highlights and Sticky Notes:

On the revelation that some of IBM's products would support a document format that it officially, adamantly opposes, Hiser is not surprised one bit. IBM and Sun have both had "the magic blueprints" to Microsoft's document formats, including Open XML, for the past several years, Hiser said.

With that key technical interoperability information, "how could you not expect IBM to start coding around OOXML?" he asked.

Tags: cdf ibm odf ooxml opendocument sam

Posted by: garyedwards

Podcast: ODF, OOXML and CDF .... The OpenDocument Foundation Responds | Between the Lines | ZDNet.com

Mon, 21 Jan 2008 19:13:19 -0000

Comments:

Dragged through the mud posted by garyedwards

Highlights and Sticky Notes:

David continues his deep dive into the curious case of the OpenDocument Format and the OpenDocument Foundation.

Tags: cdf foundation ibm iso oasis odf ooxml opendocument openoffice sun symphony

Posted by: garyedwards

Open XML trumps ODF in document format fight, consulting firm says

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

Marino Marcich, executive director of the OpenDocument Format Alliance, retorted via e-mail that many users are taking "a buyer-beware attitude" toward Open XML because that format "is not interoperable and will tie them to the upgrade path of a single vendor."

For example, he noted that Becta, the U.K. government's educational technology agency, last week released a report of its own advising, among other things, that to ensure the widest compatibility of files between different applications, Office 2007 users shouldn't save documents in Open XML. Instead, Becta recommended the continued use of Microsoft's older and proprietary .doc, .xls and .ppt formats.

It's true, OOXML is not interoperable. It was designed for MSOffice and MSOffice only. The problem is that there is no interoperable" alternative to OOXML!!!!

ODF itself has serious interoperability problems fully demonstrated at the October 2007 ODF Interoeprability Workshop held in Barcelona Spain. If users want interoperbility with ODF, they must settle on a single ODF vendor. So how is that different from the interop problems imposed by OOXML?

posted by garyedwards

Tags: burtongorup cdf odf okelly ooxml w3c

Posted by: garyedwards

Open XML trumps ODF in document format fight, consulting firm says

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

The OpenDocument Format (ODF) remains "more of an anti-Microsoft political statement than an objective technology selection" by users, according to a report released Monday by analysts at Burton Group, who recommend that companies adopt Microsoft Corp.'s Office Open XML document format whether or not it is approved as an ISO standard next month.

Tags: burtongorup cdf css odf okelly ooxml w3c xhtml

Posted by: garyedwards

Whoops?! IBM products support Microsoft's Open XML doc format! Lotushpere

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

Nobody has invested more to defeat Microsoft Corp.'s Open XML document format than IBM Corp.

So why is IBM supporting Open XML in a handful of its products?

According to technical documentation on IBM's own Web sites, Big Blue already supports Open XML, the native file format of Microsoft Office 2007, in at least four of its software.

However, Microsoft Office users interested in testing or switching to Lotus Symphony, IBM's upcoming challenger to Office, may be disheartened by signs that IBM won't budge from its stance that it will only support documents created in Office 2003 and prior versions.

Tags: cdf ibm iso oasis odf ooxml opendocument openoffice sun symphony

Posted by: garyedwards

Standard or Not, OOXML Has a Lot Going for It | Redmond Developer News - Desmond

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

Ultimately, O'Kelly said it best in his report: "The relative success of ODF and OOXML, in any case, will be determined more by its utility and which community effectively exploits W3C standards than it will by one or the other more effectively navigating through ISO standards procedures."

Tags: burtongroup cdf css desmond odf okelly ooxml opendocument w3c xhtml

Posted by: garyedwards

CIO Wakeup Call: Burton Group ODF/OOXML report | The CIO Weblog

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

Although most of the ruckus over the paper has focused on the prediction that OOXML will beat out ODF, the more intriguing and meaningful conclusion is in fact that the World Wide Web Consortium (W3C) model, built on open and broadly accepted web standards already in broad use, will in fact "...be more influential and pervasive than ODF and OOXML." This implicit acknowledgment that the SaaS delivery model will dominate productivity and document storage applications is less supportive of Microsoft's approaches than many of the documents detractors care to acknowledge and suggests the entire debate is essentially a sideshow.

CIOs who are truly concerned with data preservation and open standards need to take a hard look at Microsoft's historical business practices and the remaining questions hanging over OOXML and ask themselves if it's worth making such a major transition to a format that is fraught with the same potential for vendor (rather than consumer) control in the future. SaaS options, it's worth noting, hardly escape this issue, so regardless of the very real potential that SaaS will eclipse any of the stand-alone office applications that are currently involved in this debate, it's still going to be necessary to pick a format for long-term, corporate control of vital data and documents.

Tags: burtongorup cdf cio css ny odf okelly ooxml w3c xhtml

Posted by: garyedwards

Burton Group Responds to Ars Technica's Angry ODF/OOXML Rebuttal

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

Five days ago Ars Technica issued its view of the Burton Group ODF/OOXML report and made it clear that they disagreed with its findings, going with the headline, "Analyst group slams ODF, downplays Microsoft ISO abuses."

We've had some questions from Burton Group clients and others about the article, so I thought it would be worthwhile to go through where we agree, where we disagree, where Ars Technica mischaracterizes what we said, and where it's wrong.

Tags: burtongroup cdf css odf okelly ooxml w3c xhtml

Posted by: garyedwards

Bluster keeps the ODF / OOXML debate afloat | BetaNews

Sun, 20 Jan 2008 23:52:45 -0000

Highlights and Sticky Notes:

the Group went one step further, if only that far: It advised clients to steer clear of the whole format superiority debate, in order to avoid getting dragged down into what could be called "Office politics."

"ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard," the Burton Group's Guy Creese and Peter O'Kelly wrote. "It's possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection."

Tags: burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

Posted by: garyedwards

Brian Jones: Open XML Formats : Mapping documents in the binary format (.doc; .xls; .ppt) to the Open XML format

Sun, 20 Jan 2008 23:52:44 -0000

Comments:

Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!

And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.

Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.

For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.

Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!

So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!

This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.

It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this route. The Sun - ODF covenant not to sue specifically exempts eXtensions to ODF not involving Sun! Meaning, if the interoperable subset of ODF was designed and implemented without Sun-OASIS participation and approval, the covenant not to sue does not apply. Developers beware! You cannot safely eXtend ODF without Sun's permission.

Here is the relevant text from Sun's covenant: "Sun irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation, as defined by the rules of OASIS, to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants."

The obscurity of intent is masked in clever legalese. Which means, bring your legal team if you want to eXtend ODF, and prepare to argue.

My point is that this covenant could have been written clear and direct to say that Sun will not sue anyone for any reason related to ODF. But they didn't do that.

People will of course wonder why ODF is so bad that it might a as well be ZERO interop? The answer to this question is complicated, but a good place to start is to observe that, just as OOXML is an XML encoded dump of MSOffice in-memory-binary-representation, ODF is an XML encoded dump of OpenOffice/StarOffice in-memory-binary-representation.

The interop problem truly kicks in at the level of specifying this encoding. The Ecma and OASIS technical committees are responsible for fully specifying the OOXML and ODF. This means a complete syntax and semantic description needed to properly implement the specs. ODF and OOXML share one very big fault; the presentation-layout layer (or styles) is not fully specified! We have the syntax but not the semantics describing how layout works. This is particularly problematic in that both ODF and OOXML are application specific dumps. While they each do a good job separating content from presentation, neither fully specifies the presentation layer. Nor is the presentation layer portable in the sense that a CDF XHTML + CSS separation is portable.

And it is the presentation layer that binds the formats to their originating applications. MSOffice has one way of implementing basic document structures like lists, fields, tables, sections and page dynamics, and, OpenOffice has another. That these application differences are embodied in the formats creates an enormous interoperability problem. Applications can exchange content, but break when trying to interpret another applications presentation-layout layer. Especially when that presentation layer is under specified!

There were three aspects of ODF 1.0 that were under specified: numbered lists, formulas, and styles (presentation-layout). ODF 1.2 attempts to fix the formula problem, but does nothing for styles. The numbered lists "interop" problem was not fixed, but exacerbated.

So even though the binary blueprints were released two years ago to Sun and IBM, we have yet to see any improvement in conversion fidelity able to crack the lock MSOffice workgroup-workflow business processes have in the marketplace. Writing a subset of ODF enabling us to achieve that high fidelity conversion has a legal cloud hanging over the process. And all of these concerns are shadowed by the fact that neither OOXML or ODF have fully specified their presentation layers!

No wonder the W3C's formats are attracting so much attention.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

The second issue we had feedback on was an interest in the mapping from the binary formats into the Open XML formats. The thought here was that the most effective way to help people with this was to create an open source translation project to allow binary documents (.doc; .xls; .ppt) to be translated into Open XML. So we proposed the creation of a new open source project that would map a document written using the legacy binary formats to the Open XML formats. TC45 liked this suggestion, and here was the TC45 response to the national body comments:

We believe that Interoperability between applications conforming to DIS 29500 is established at the Office Open XML-to- Office Open XML file construct level only.

And here i was betting that the blueprints to the secret binaries would be released the weekend before the September 2nd, 2007 ISO vote on OOXML! Looks like Microsoft saved the move for when they really had to use it; jus tweeks before the February ISO Ballot Resolution Meetings set to resolve the Sept 2nd issues.

The truth is that years of reverse engineering have depleted the value of keeping the binary blueprints secret. It's true that interoperability with MSOffice in the past was near entirely dependent on understanding the secret binaries. Today however, with the rapid emergence of the Exchange/SharePoint juggernaught, interop with MSOffice is no longer the core issue. Now we have to compete with E/S, and it is the E/S interfaces, protocols and document API's and dependencies tha tmust be reverse engineered.

The E/S juggernaught is now surging to 70% or more of the market. These near monopoly levels of market penetration is game changing. One must reverse engineer or license the .NET libraries to crack the interop problem. And this time it's not just MSOffice. Today one must crack into the MS Stack whose core is tha tof MSOffice <> E/S.

So why not release the secret binary blueprints? If that's the cost of getting the application, platform and vendor specific OOXML through ISO, then it's a small price to pay for your own international standard.
posted by garyedwards

Tags: burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

Posted by: garyedwards

CDI WICD 2.0

Sun, 20 Jan 2008 23:52:44 -0000

Highlights and Sticky Notes:

This document defines a generic language-independent processing model for combining arbitrary document formats.

The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, together with CSS and the DOM; it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats.

1.1. Conformance

Everying in this specification is normative except for diagrams, examples, notes and sections marked non-normative.

The key words must, must not, required, shall, shall not, should, should not, recommended, may and optional in this document are to be interpreted as described in RFC 2119 [RFC2119].

This specification defines the following classes of products:

conforming implementation: A user agent that implements all interfaces described in this specification and follows all must-, required- and shall-level of critera in this specification.
conforming document: A document that follows all must-, required- and shall-level of critera in this specification that apply to document authors.
conforming authoring tool: One that produces conforming documents.

Tags: cdf css svg w3c wicd xforms xhtml

Posted by: garyedwards

Microsoft's OOXML: The No vote | Computerworld

Sun, 20 Jan 2008 23:52:44 -0000

Highlights and Sticky Notes:

The Cyberspace Law and Policy Centre at the University of New South Wales recently hosted a symposium to discuss issues surrounding the proposed Microsoft OOXML document format standard.

In attendance at a technical session were representatives from Microsoft, IBM, Google, the Open Source Industry Australia, Standards Australia, the National Archives of Australia, and the International Organisation for Standardisation.

Tags: cdf ecma iso odf ooxml

Posted by: garyedwards

OpenDocument's feed | Diigo Group

Is HTML in a Race to the Bottom? A Large-Scale Survey of Open Web Formats

Compound Document Formats Group Charter

Unbreaking the Web: IE 8 passes ACID 2 Test | John Resig

Putting Andy Updegrove to Bed (without his supper) | Universal Interoperability Council

Harmonization and Interop: The dizzying dance of ODF, OOXML, and CDF

IBM's Director of Strategy comes clean on OpenXML - IBM *WILL* support OpenXML in its Lotus and Portal products - Notes2Self.net

IBM’s Stance Against OpenXML Is Increasingly Confusing : Oliver Bell’s weblog

Independent study advises IT planners to go OOXML | A pos on both your houses!

A gadfly's take on IBM's 'support' for Open XML | Computerworld Blogs

Podcast: ODF, OOXML and CDF .... The OpenDocument Foundation Responds | Between the Lines | ZDNet.com

Open XML trumps ODF in document format fight, consulting firm says

Open XML trumps ODF in document format fight, consulting firm says

Whoops?! IBM products support Microsoft's Open XML doc format! Lotushpere

Standard or Not, OOXML Has a Lot Going for It | Redmond Developer News - Desmond

CIO Wakeup Call: Burton Group ODF/OOXML report | The CIO Weblog

Burton Group Responds to Ars Technica's Angry ODF/OOXML Rebuttal

Bluster keeps the ODF / OOXML debate afloat | BetaNews

Brian Jones: Open XML Formats : Mapping documents in the binary format (.doc; .xls; .ppt) to the Open XML format

CDI WICD 2.0

1.1. Conformance

Microsoft's OOXML: The No vote | Computerworld

IBM's Director of Strategy comes clean on OpenXML - IBM WILL support OpenXML in its Lotus and Portal products - Notes2Self.net