Orcmid's Lair
Orcmid's Lair
status 
 
privacy 
 
contact 

Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

This page is powered by Blogger. Isn't yours?

Recent Items
 
Office XML's IP-Infringement Specter, I: Copyright (long)
 
Creating the World You Want to Live In
 
Gaming the Social Space: Googly Blogger Spam Juicers
 
Papers Please: Congress Games the Electorate
 
Agenda Shear: Privatization of Schools and Public Oversight
 
Dan Pink | Orange is the New Pink
 
Stationery is bad
 
I Can Tell By Your T-Shirt You're a Commoner Too! Lessig on Bzz
 
We Want Your Feedback - Sure You Do!
 
Fifty is Nifty: Happy Birthday Dave

2005-06-09

Microsoft OX vs. OASIS OD: Is It Really Open Format vs. Open Standard?

Orcmid's Lair: Office XML's IP-Infringement Specter, I: Copyright (long)Updated Information: The table, below, has been updated in Analysis 0.75, Toward Open-Format Adoption.  The 2005-12-06 blog post, Lining Up Formats for Office Documents, summarizes the later analysis.

While I mull over the problems that software patents pose for software developers and the specter that is aroused for some of us literal-minded geeks, I notice that there are some odd statements around the ease with which Microsoft is supposed to adopt the OASIS OfficeDocument specification as an obvious pathway from its current binary formats to an open-standard XML solution.  So I’ve prepared a little addendum to my previous missive on the subject.

3.5 Open Formats vs. Open Standards?

There is some chatter about Microsoft's Open Format not being truly open, and that true openness means no encumbering patents.  Rather than argue the point, I think a reality check is called for.  Here's what I have found by applying a modest level of diligence:

 

OASIS OpenDocument

Microsoft Office XML Open Format

Type of specificationelectronic-document format (700 pages, June 2005)electronic-document format (spec. not yet available; skimpy documentation of predecessor formats)
progenitorsOpenOffice.org (OOo)XML Microsoft Office 97-2003
derivative work of specificationallowed solely for discussion and explanationexcluded
schema methodologyRelax-NG schema definition (504k)XSD: XML Schema Definition (assuming continuity with current Microsoft Office XML Reference Schemas)
schema variationsone relaxed [;<), one strict, plus package specificationone set per document type (Word, Excel, PowerPoint each with and without macros), with shared generic pieces in a (common?) package specification (assuming continuity with current Microsoft Office XML Reference Schemas)
licensing of schemasnone stated (Sun Microsystems and OASIS Open copyright notices)same notice as on documentation
royalty-free patent licensingSun Microsystems "essential claims" royalty-free licenseMicrosoft "necessary claims" royalty-free license
patent-license scope limitationonly where unavoidable in order to implement the specification, and only to implement the specificationonly those portions of a software product that read and write files that are fully compliant with the specification of the schemas
patent reciprocity requiredyesno (although suing Microsoft or affiliates for infringement of a related patent claim will terminate the license)
patent-license notice requirednoyes
specified compatibilitysome (forks OpenOffice.org format)round-trip fidelity with Microsoft Office binary-format documents, Office 2000-2003 and Office 12; degree of down-level convertibility is unclear.

The Microsoft Office XML Reference Schemas license establishes open formats.  That is what was promised, and that much is delivered without question.  One of the new openings that Microsoft celebrates is making it easy to repurpose documents in those formats.  Likewise, one may produce documents in those formats as a repurposing of other material.

Although I think there is a speculative case for allowing derivative works of the OX formats, I want to make it clear that Microsoft has provided what it promised: an open format.  It's a proprietary open format the way TIFF, PDF, and GIF are.  It's more open (or less proprietary, take your pick) than MP3 is.  It is determined by a single specifier, the same as FORTRAN, C Language, and Java (and a lot more) were.

It's the schemas that can't be "repurposed."  That's what I am picking at when I claim there's a derivative-use bind.  That may turn out to be unimportant.  We need to find out.

Is this the difference between (merely!) an open format and an open standard?  Or is there no material difference?  In some sense, the OX format schema is like the specification of a programming language.  The idea is to program in it (use the format), not make new programming languages.  Of course, people do make new programming languages based on the specifications of older ones, as witnessed by the survival of C Language in C++, Java and C#.  It would seem that that is frowned upon for the Microsoft Office XML Open Formats and for the OASIS OpenDocument format.

The term "standard" is being bent a little in comparing the Microsoft Office Formats and the OpenDocument format.  If there is any "standard" office document format, it is the one already implemented and preserved by the progression of Microsoft Office implementations since Office 97.  It is the format that other products, including Microsoft Office 12, must deal with in order to be widely acceptable in the office-productivity marketplace.  It doesn't get more "standard" than that.  Specifications become standard through their adoption in practice, not their publication.

That OASIS declares a 706-page unimplemented specification as being an "OASIS Standard" is fairly amazing.  It will take substantial effort to reality-check that specification, and it will be a little while before anyone confirms multiple, interoperable implementations.  The test suites that will be required will be impressive, I'm sure.  I am also a little surprised that the schema is being defined using a Relax-NG OASIS Committee specification that has been around since December 2001 and hasn't made it to even OASIS Standard.  There is, however, ISO/IEC 19757-2:2003 which was issued in November, 2003, and one must trust that to be substantially the same (or use the PDF document here).

It seems to me that OpenDocument must be demonstrated to accommodate the Microsoft Office format, not the reverse.  Can OpenDocument accurately represent documents created in Microsoft Office, preserving all of the features of those documents?  Can faithful conversion be done mechanically?   That's the legacy challenge that must be dealt with.  It doesn't strike me that the burden of proof is Microsoft's.

 
Comments:
 
===cut===
That OASIS declares a 706-page unimplemented specification as being an "OASIS Standard" is fairly amazing. 
===cut===
OpenDocument will be implemented in OpenOffice.org Version 2.0 and in KDE KOffice Version 1.4
Unimplemented specification? Do we talk about OpenDocument or about Microsoft Office Open XML?
If you think OpenDocument is unimplemented than you are uninformed. Please take a look at OpenOffice.org, KOffice, IBM Workplace, StarOffice. OpenDocument is not a dream. It is a real format with enough support to present a real alternative.

===cut===
It will take substantial effort to reality-check that specification, and it will be a little while before anyone confirms multiple, interoperable implementations.
===cut===
Could it be that all members of the OASIS OpenDocument working group already did that? How do you think they agreed on that standard?

===cut===
It seems to me that OpenDocument must be demonstrated to accommodate the Microsoft Office format, not the reverse. 
Can OpenDocument accurately represent documents created in Microsoft Office, preserving all of the features of those documents?
===cut===
If Microsoft cannot store its office document features with the existing OpenDocument file format than you cannot blame OASIS. OASIS welcomed everyone including Microsoft to help designing a new file format based on OpenOffice.org´s XML file format.
 
 
Thomas makes a number of points that I have seen on other blogs (e.g., http://blogs.msdn.com/brian_jones/archive/2005/06/13/428655.aspx where Thomas's comment also appears.

I think this is deserving of a new blog entry, because Thomas has some important concerns.

Here I want to question the assumption about the ease with which Microsoft could have participated. Who seriously believes that the OASIS OpenDocument project would have taken legacy preservation of Microsoft Office Documents (with their requirements for a thousand more elements) as a design constraint, and how would OOo format have survived that effort? How could the committee have survived that effort?

I don't want to diminish the accomplishment of OOo and the OASIS OpenDocument. I think it has been influential in terms of impact on the opening of office documents as well as providing an alternative product that serves many, especially where there was no integrated office-productivity product. We might not even be having this conversation if it weren't for that.

At the moment, we have too many people telling Microsoft what to do and how to do it, but only one hand in the air for accepting the heavy lifting that preserves the varied investments of 400 million users in multiple languages and cultures. Don't underestimate the importance of that and the difficulty of the effort.
 
 
Hello. Your licensing information regarding Sun is outdated - they have revised it make very clear they intend to enforce no restictions against the OpenDoc format, since the OASIS-required boilerplate was unclear.
Am I reading orcmid's comment correctly: a format (OpenDoc)that currently supports the office needs of over 30 million users would need to define 1000 more elements to support Microsoft files? And, of course, since the binary format is secret, the only people who could implement 100% conversion to OpenDoc would be Microsoft, who have explicitly stated that they won't.
Viewed things a different way, 400 million (not my number) people have their data in a format that they can only fully access with the blessing of a single company. This is of enough concern to some that they are beginning to rebel against the notion.
And, in closing, the world is once again busily comparing a technology that is available (4 implementations of OpenDoc) against a Microsoft one that isn't (I see no Office 12 here!) - reminds me of the 18 months Win95 competed with O/S2.
 
 
I don't know where you get your numbres. The 400 million people are currently using Microsoft Office, and the new XML support will be available in all Win32 ones using a plug-in to be made available freely. In addition, there is XML support in Office 2003 already.

Neither you or I will be the ones who determine whether an implementation of the OASIS Open Document Format will be good enough.

You are absolutely correct that the table is out of date. The new Sun Patent Statement on OASIS Open Document IPR is absolutely terrific. It would be great if Microsoft will provide a similar relaxation of their royalty-free license for the Open Office XML, the Open Package Conventions, and other parts of Metro that will be important to office-document users.

I will post a new version of the table and I will put an update notice on this page when that's happened.
 
 
The new table is posted and a summary of the latest analysis is also provided. See the top of the present article for new links.
 
 
The people posting here should check whether the MS format and lisensing meet GPL.
And should discuss the legal issues comparable to the use of PDF.
 
 
1. The specifications for the current formats do not permit derivative works so they don't qualify as open-source specifications.

2. The license for software implementing the current formats is not GPL-compatible according to FSF.

3. The Office Open XML formats being developed as ECMA Specifications have high-quality conformance requirements comparable to those for the C, C++, and EcmaScript standards.

4. The ECMA Specifications are not about software. The question about royalty-free patent licenses will need to be resolved at that level.

Check the later versions of this material for additional information.
 
Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 06-04-23 14:26 $
$$Revision: 3 $

Home