When is a standard not a standard?

Short URL: http://fsmsh.com/2110


I had a massive argument with my brother the other day over an IT issue close to my heart. I had to be careful because he is a member of the Metropolitan Police, part of the Domestic Violence Policy Unit. To clarify, his department is responsible for the policy of policing domestic violence.

What he was saying was that he, and the entire metropolitan police force, use Microsoft Word, all the police departments and stations he deals with do as well, as do all organizations he needs to interact with outside the police including the name drop-able big-wig departments in the UK government. He said they had "standardized" on Microsoft Office formats and did not see a problem with that, nor did he see my objections.

The police are by no means the only ones. My mother receives documents from theater organizations in .doc and .xls formats, as do I from local organizations. The local Cambridge and Cambridgeshire governments post documents on their web sites using them. I understand how people can see it as a standard.

Except it is not.

These formats have never been submitted to a standards body, on the contrary Microsoft have done all they can to keep them closed. The only reason why myself, my mother and others who do not use Microsoft Office can read them is due to the fact technicians spent hours in front of binary dumps of the files getting inside the head of the Microsoft developers and reverse engineering the specification: a scenario that is hardly the basis of global interaction.

Technicians reverse engineering binary dumps of Microsoft's closed formats is hardly the basis of global interaction

All this is being replaced by new XML based formats.

The Story so far

Open Document Format - or ODF - now ISO/IEC 26300:2006 – was designed to be an open standard anyone could use for office document interchange based on recognized existing standards and conventions (1). Microsoft refused to have anything to do with it, instead pushing their own new format - Office Open XML - or OOXML.

Microsoft initially placed restrictions on the use of their format. When the Commonwealth of Massachusetts' IT Division would not entertain storing documents using a format with IP restrictions, and other governments and organizations were following that example, Microsoft opened the IP using Non Assertive Contracts (2). Microsoft then submitted this format to ECMA for standard approval, however the format is not based on existing recognized standards, and it's main objections are to create an "XML"ization of their closed existing formats so that documents can be converted to these more than produce genuine interoperability with other programs(3).

Microsoft achieved ECMA accreditation, which is no surprise as one of ECMA's roles in this universe is to approve standards for submission to ISO for rapid adoption(4), and sure enough, OOXML was submitted to ISO for fast track approval. However, this is when things started to go wrong for Microsoft. People noticed that OOXML's standard was bogus. National standards bodies were lobbied accordingly, and an unprecedented twenty members raised comments, fourteen were decidedly negative and only one supported it positively.

ECMA had a month to reply to the above contradictions and comments, so they duly submitted a report to the JTC1 on the 28th February 2007.

OOXML Contradictions, objections, arguments, problems and comparisons to ODF

The object of a format standard is to facilitate and promote genuine interoperability and choice. No standard can be one hundred percent perfect, the issues are too numerous for that. After examining the technical issues I think that ODF has gone a long way to achieving this and that Microsoft's OOXML has not. I would like to expand on some of OOXML's contradictions and problems, some possible counter arguments that exist for them and my personal problems with those.

Objection 1 – OOXML duplicates and overlaps with ODF

It is pointless to have OOXML when ODF already exists as a standard for office document interoperability.

Argument against #1 – No problems having multiple standards for the same thing

Standards already exist that overlap, such as HTML, PDF/A and ODF for exchanging office documents, CGM and SVG for vector graphics, JPEG and PNG for image formats, RELAX NG and DTD for XML schema definitions and and TIFF/IT and PDF/X for publishable graphics.

My problem with that

The examples given are not relevant to OOXML's duplication of functionality with ODF. To take each in turn:

HTML, PDF/A and ODF are used for very different purposes. HTML to store marked up textual content, though not in any predefined format. PDF/A to reproduce an unchangeable paper representation of a document, and ODF to interchange editable documents for later publication. To say their collective use is for "exchanging office documents" is as crazy as saying a car, plane and ship are all similar because their use is to "get from A to B".

To say that HTML, PDF/A and ODF are the same because their collective use is for "exchanging office documents" is as crazy as saying a car, plane and ship are all similar because their use is to "get from A to B"

JPEG is used for storing and transmitting photographic type images, while PNG is more suited to logos and charts: they are designed for very different types of content.

The DTD standard was created in the 1980s. RELAX NG in the 2000s. DTD was becoming dated and could not handle the more complicated schema formats correctly so a new updated standard was needed. Not by any means an ideal situation, but one that is irrelevant to OOXML and ODF.

The TIFF standard, although, did what it was designed to do which was to create a standard reliable format for pre-press data. It (currently) simply handles transfers of bitmap data. PDF/X is a more versatile format created later and addresses some shortcomings in TIFF, including image compression, late editing and others providing for data transfer in different scenarios. Although these have similar functionality the difference with these is that they have nothing to do with maintaining compatibility with a specific vendor's product, as is the case of OOXML.

In conclusion, although multiple format standards for the same content exist, they are hardly desirable, and are rare. Often they actually represent important differences in content, as in many of the examples given, and where this is not the case the reason is often that technology has moved on since the first standard was originally created, and that it is still kept for legacy reasons. ODF caters for editable office document exchange in the modern world. OOXML was submitted long after ODF's acceptance. On that score it is superfluous.

Counter argument #2: OOXML has a distinct purpose of storing existing Microsoft Office documents

OOXML is different to ODF in that OOXML was designed with compatibility with existing Microsoft closed formats and ODF was designed for document interoperability.

There are many existing Microsoft Office documents in existence; a standard should exist that reproduces the precise formatting of these documents as originally written. Those that require this include national library archives and mission critical scenarios. Also persistence of this precise formatting is required when moving data to and from other platforms such as mobile and fixed computers.

My problem with this

This argument is incompatible with the real world: Microsoft Office document rendering varies between different versions of Microsoft Office, it also varies between the same version if different printers and/or fonts are installed, all making the above argument moot.

Editable document format interchange is never going to be precise in rendering as there are too many uncontrollable variables, and no standard can control all of them, nor do I believe any should. There are other types of formats for precise rendering, such as PDF, mentioned above. Documents that require exact duplication should use that rather than an editable document format.

Also, the point that OOXML's purpose is to represent the closed formats of a single vendor makes me wonder how that qualifies it for a standard in the first place. Standards are for interoperability and choice; basing one solely on a single product is counter-productive.

Counter argument #3: ODF and OOXML cannot be merged but canco-exist

The fundamental differences between ODF and OOXML means they cannot be merged. OOXML was designed to be compatible with Microsoft Office documents, and ODF was designed for document interchange, this as well as some "nitty gritty" differences makes merging them impossible.

However, translators can be written, are being written and have been written to convert from one format to the other, therefore co-existence is possible. This means there is no contradiction between these two.

My problem with this

The two paragraphs above cancel each other out. Having analyzed the two formats myself I agree that they cannot be merged, my point is that OOXML should not be a standard. It is obvious to me that the best solution is to interchange and store the document using ODF and for the office application itself to "translate" it when loading and saving.

Microsoft should interchange and store the document using ODF and for the office application itself to "translate" it when loading and saving it

Objection: OOXML contradicts existing standards including ODF

OOXML contradicts existing standards, in particular ODF (ISO/IEC 26300:2006), Representation of Dates and Times ( ISO 8601:2004), Codes for the representation of names of languages (ISO 639) and Computer Graphics Metafile (ISO/IEC 8632).

Counter argument

There is no formal definition of the word "contradiction" in a "Standard Format" scenario. If two formats can co-exist on the same machine and there are translators that have been written to interchange the two formats then a contradiction cannot exist.

My problem with that

The point of a format standard is that data interchange of that type should use it. The only exception to that would be if the world has moved on since the idea of standard's was conceived and it is inadequate. The existing ISO standards involving dates and times, language codes and computer graphics can cope with all the data of those types an office document program generates, and therefore should be used. Not doing so is a contradiction involving those standards; it is as simple as that.

Also, if translators exist between OOXML and ODF then as ODF is an existing standard OOXML must contradict it.

Objection: Thirty days is too short to review a document over six thousand pages long

The OOXML specification is over six thousand pages long. Thirty days represents two hundred pages a day. It is impossible to adequately review the document in that scenario.

Counter arguments

  1. The term "contradiction" is not defined so it is adequate to simply consider an overview of the standard in relation to other standards.
  2. The first draft of the OOXML standard was available in May 2006, seven months before the review period. Comments and contribution have been welcome from anyone since then..
  3. As part of the "fast track" proposal ECMA produced a fourteen page summary to facilitate understanding the OOXML standard.

My problems with that

  1. It is near impossible to review a six thousand page document in thirty days regardless of what the definition of "contradiction" is.
  2. To review a standard you need the correct draft. It is pointless reviewing earlier ones as you do not know what may have changed.
  3. To review a standard properly you need to read it, not just a fourteen page summary.

Objection: OOXML has inconsistencies with existing ISO standards

OOXML uses means of storing and transferring data that is inconsistent with existing standards. Namely Paper Sizes (ISO 216), Language Codes (ISO 639) and Color names (ISO/IEC 15445 (HTML)).

There is an issue with the representations of dates and times (ISO 8601). This standard specifies the use of the Gregorian calendar, but OOXML treats 1900 as a leap year, which it was not, and cannot represent dates prior to 31 December 1899. This is because OOXML spreadsheets (SpreadsheetML) represents all dates as a decimal number either from 31st December 1899 or 1st January 1904 depending on the "Date System" set rather than the format specified by the aforementioned standard.

ISO 8879 states that SGML tag names should be human readable and minimum emphasis placed on terseness, whereas OOXML not only uses short, abbreviated and also cryptic names it uses them in an inconsistent manner within itself, for instance, "scrgbClr". "algn", "dir" and "w" are not clear in meaning.

References are also made to "Enhanced Metafiles" and "Windows Metafiles". These are some of Microsoft's closed formats and have no place in a supposedly open standard. The Computer Graphics Metafile format (ISO 8632) should be used for that.

The OOXML standard is inconsistent within itself, as well as with recognized methods, of the representations of percentage values, which can be represented as a decimal integer - (Magnification Settings -, an enumeration of codes made up of a percentage integer prefixed with "pct" - (Shading Patterns - 2.18.85), as a code made up of an integer being the real percentage multiplied by 500 (Table Width Units - 2.18.97) and a real percentage multiplied by 1000 (Generic Percentage Unit - Which one depends what part of the OOXML specification is being dealt with.

Counter arguments #1: OOXML Page Sizes

Page Sizes: The ISO 216 page sizes are represented in OOXML, as well as others. OOXML simply uses a number to represent each page size and what number represents which size is documented there.

My problem with this

XML is not meant to be cryptic. If a page size is Letter, A4 or C4, then it makes sense for the attribute value to be "Letter", "A4" or "C4", not "1", "9" and "30".

Counter arguments #2: OOXML Language Codes

Language Codes: OOXML gives the implementer a choice. Either the ISO 639/ISO 3166 combination can be used or a special two byte hexadecimal value as specified in the document.

My problem with that

If a standard is there, and it does the job, then it should be used. Putting these "optional alternatives" in is pointless and only detracts from adoption. The ISO 639 and 3166 codes should be used alone, the Microsoft specific hexadecimal codes should be dropped.

Counter arguments #3: Color Names

OOXML uses its own abbreviations for color modifications, "dk" for "dark", "lt" for "light" and "med" for "medium". It also uses it's own description of colors such as "darkRed" (OOXML) for "maroon" (ISO 15445) and "darkCyan" (OOXML) for "teal" (ISO15445); these are more meaningful.

My problem with this

These OOXML specific names are only more meaningful in the opinion of its authors. The purpose of standards is that if everyone uses them it will make the world a more meaningful place. Unilaterally defining alternative and/or redefining the actual colours in a standard that is supposedly open is a contradiction.

Should the writers of Microsoft Office, or any other software authors, feel that "Dark Red" is more meaningful to their users than "Maroon" (for example) then there is nothing stopping them from calling it that in the application itself (though I would have thought inadvisable), it is just the standard (ISO 15445) should be adhered to in the interchangeable file.

Counter argument #4: Dates and times

There are legacy applications, such as Microsoft Excel and Lotus 123 that treat the year 1900 as a leap year. The two methods of converting numbers to dates are to help cater for that. The first (the number of days since 31st December 1899) is to cater for the legacy applications, the second (the number of days since 1904) gives a more accurate representation for newer applications. Although the range of dates supported for OOXML (12-December-1899 or 1-January-1904 to 21-December 1999) is not as big as the range for ISO 8601 it should suffice.

My problems with this

What a mess! There is no call nor need to support specific legacy applications that way. This is supposed to be a format for document interchange. Old unmodified legacy instances of Lotus 123 and Microsoft Excel will not be able to read it anyway. Catering to them in this way is pointless.

There is no call nor need to support specific legacy applications in an open document standard by incorrectly making 1900 a leap year

It would be a lot simpler just to specify the dates as ISO 8601 – for example: 28th February 2007 can be represented as "2007-02-28". No silly numbers from an arbitrary date, nice and simple. It should be up to the application to parse it and convert it to an internalnumber.

Counter argument #5: terse tag names

Other SGML standards have terse tag names. For instance, the HTML standard has tag names such as "<P>", "<HR>", "<TR>", "<TD>" and so on. OOXML is a specification for a technical markup language and it is not unreasonable to expect direct manipulation and implementation to be done with a reference manual.

My problem with this

OOXML is supposed to be a standard for document interchange that uses XML. One of the advantages of XML is that descriptive tag and attribute names can be used: this makes understanding and implementation of the standard easier. Using short and/or inconsistent abbreviations is not applicable to an open standard.

As for comparing it to the HTML standard, there are two points to note. Firstly, that HTML was created and deployed before XML standards really matured. The standard that then ensued was thus not to the quality as perhaps it should be. Second is that the old version of HTML had about thirty tags or so making it relatively easy to remember them all despite their cryptic nature, whereas OOXML has several hundred making the sane naming of tags all the more important.

Counter arguments #6: Inclusion of closed Enhanced and WindowsMetafiles

This is mentioned on two occasions: the first - "Embedded Object Alternate Image Request Types"( the OOXML format mentions these formats in enumeration lists, any formats can be included. The specification does not limit embedded graphic types to those formats. The second - "Clipboard Format types" ( – simply specifies suggested action taken by the application in certain circumstances and again does not limit the document's embedded graphic format types.

My problem with this

The enumeration list mentioned on the first instance ( ) includes: Bitmaps, Enhanced Meta Files (EMF) and (any other) Picture format. The question I have is why single out Bitmaps and EMFs? This looks like they are trying to cater to specific applications, which is not the point of a standard. The treatment of those types should be the same for "Any other picture format" and the attribute should be dropped.

The second instance should not be specified in an open document standard at all. The precise behavior of a particular application for particular (closed) formats is unique to it and not really transferable. Document standards are for interoperability of the documents itself, not a determination of how any particular application behaves: should this be needed for Microsoft Office then it should be stored in a more generic, application defined, "config" type field that does not infringe on other applications.

Microsoft should store their unique quirks in a generic "config"tag or similar rather than on the main name-space

Counter arguments #7: Percentage inconsistencies

Where the percentages are actual values they have been converted to integers to allow for efficient parsing. Fractions of a percentage are catered for by multiplying the actual percent by a number.

For the Shading Pattern (2.18.85) the enumerated code represents specific patterns where a value that can be used in calculations is irrelevant.

My problem with this

Computers can be used for calculations. They are good at that. The overhead for converting a percentage value of "27.32" into an internal integer value of "27320" is trivial. So much so that compared to the processing resource used and time spent by the computer retrieving the document data from a disk, memory card or network the overhead of that calculation would be unnoticeable.

The fact that sometimes OOXML specifies the percentage should be multiplied by 500 in some circumstances, and 1000 in others I feel is simply the icing on the cake of contradictions.

I admit that I can in fact find no ISO standard that specifies that percentages should be represented as a number whose range of 0 to 100 represents none to all; I think the reason for this is because the whole population of the world from infant school students to retirement home residents from Indiana to India use percentages that way: that is everyone and everything except OOXML. I do not see why percentages should not be represented as, well, percentages.

I can see why the "Shading Pattern Codes" (2.18.85) should be a name rather than a value. However, should a more descriptive code be required in that circumstance then it should be something like "shadingPercent10" rather than "pct10" to keep it consistent with the other names of shading patterns.

Objection: references to undocumented behavior in closed Microsoftproducts

There are a number of tags in OOXML that are references to undocumented behavior in closed proprietary products, notably previous versions of Microsoft Office. These include "footnoteLayoutLikeWW8" (Emulate Word 6.x/95/97 Footnote Placement – and useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules -

These reference closed proprietary products, and the behavior of some cannot be imitated unless the product is somehow obtained, and some of these products are no longer sold or supported by the vendor (notably the "footnoteLayoutLikeWW8" tag).

Counter argument

These are relatively few when compared to the large number of fully documented tags in OOXML, also it is not necessary for the implementor of the standard to cater for these. They are settings specific to those applications so those applications can behave in a consistent manner between saving and loading.

It is worth noting that ODF and OpenOffice.org has a similar, though undocumented, case in ISO 26300, namely the use of the "config:config-item" tag and the "config:name" attribute value for what is set. Notable examples are when OpenOffice.org sets the attribute value to "AddParaTableSpacingAtStart" or "UseFormerLineSpacing", or when KOffice set this to "underlinelink" or "displayfieldcode".

My problem with this

On the face of that argument it sounds like a school child's lament of "Well they did it over there so why shout at me for doing it here". However the reality is different: no open office document standard can be perfect and cater for every application's quirk and scenario, but these applications need to store their own unique meta information and sometimes unspecified peculiarities for consistency between sessions.

To this end, OOXML have chosen to select few applications – namely the ones in Microsoft Office and some WordPerfect formatting which Microsoft supports, place the features in the main name-space specification and then ignore all other applications.

ODF on the other hand provides a mechanism for any application to add their unique quirks without breaking the standard. It does these by placing the "quirk" in a "config" attribute value defined by the application, not a name, and placing the setting in the body of thattag.

In both the above it is important to remember that an open office document standard cannot, nor should not, reproduce the rendered document exactly. It is impossible because not only do documents render differently between versions of the application but between the same version running on separate machines of the same operating system. This is just as true for the Microsoft Office programs as it is for anyone else's: to duplicate rendered documents standards such as PDF should be used.

In short, OOXML's method of dealing with the problem in effect locks out all applications that are not Microsoft Office, whereas ODF's method keeps the standard vendor neutral and usable by any office suite.

OOXML's method of dealing with the problem in effect locks out all applications that are not Microsoft Office, whereas ODF's method keeps the standard vendor neutral and usable by any officesuite

A misconception about ODF and OOXML

There is a misconception about ODF and OOXML in existence which was highlighted in an e-mail interview between Mary Jo Foley of ZDNet and Tom Robertson of Microsoft. In it Tom Robertson wrote:

The discussions around Open XML and ODF are a proxy for product competition in the marketplace. Ultimately, this attention and focus on the needs of those who use office productivity software is a good thing for all concerned, but the attention being paid relates back to the commercial opportunities for MS Office, IBM's Workplace (Open Client), and OpenOffice commercial offerings from Sun and others. For us, the move to an XML-based file format is an important aspect of Office 2007.

I will not comment if I think he was intentionally lying when he wrote "The discussions around Open XML and ODF are a proxy for product competition in the marketplace". Certainly this is not true. The purpose of an open format is about about choice and interchangeability. There is nothing stopping Microsoft from placing an ODF file "save" and "open" facility in their Office suite(5). They have many other formats so why not ODF? They claim they have translators between the two formats so therefore there cannot be any technical difficulties: any quirks of Microsoft Office can be placed in the "config" tag mentioned above. After all, OpenOffice can open Microsoft .doc, .xls and .ppt files and save them as ODF with reasonable reliability and reverse the process, and it is not as though Microsoft do not have the resources to do the same in their product.


Going back to my argument with my brother. Microsoft have a large section of the market sewn up and the standard method of transferring documents there is by using their closed office formats. I believe they enjoy that position, and despite noises from their PR department, they would like to keep control of the document interchange format by whatever means possible in order to keep their monopolistic lead in the market place.

I do not believe Microsoft are really interested in open standards, but just paying lip service to them. The history of the OOXML and ODF "discussions" supports this theory. OOXML is not as open as it's name applies: it ignores existing standards and it only fully caters for Microsoft Office programs making it near impossible for a competing product to use. By Microsoft's own admission it is simply an "XMLization" of existing closed .doc, .xls and .ppt formats. It should not be adopted by ISO, and certainly not "fast tracked".

ODF is genuinely open. There is no reason why Microsoft cannot use it. Adoption of ODF will benefit everyone who is not trying to maintain a near monopoly in the Office Production Suite domain.

One thing my brother perhaps should ponder considering his profession: improperly maintaining monopolistic practices and situations are usually considered illegal.


Note 1: Form the OASIS document Open by Design - http://www.oasis-open.org/committees/download.php/21450/oasis_odf_advantages_10dec2006.pdf: "The OpenDocument Format was designed to be vendor neutral and implementation agnostic. It was designed to be used by as many applications as possible. In order to simplify transformations and to maximize interoperability, the format reuses established standards such as XHTML, SVG, XSL, SMIL, XLink, XForms, MathML, and Dublin Core."

Note 2: Precise history is documented at http://www.groklaw.net/staticpages/index.php?page=20051216153153504.

Note 3: IN Microsoft's open letter "Interoperability, Choice and Open XML" found at http://www.microsoft.com/interop/letters/choice.mspx it states: "OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation".

Note 4: From ECMA'a web site - http://http://www.ecma-international.org/:

"Ecma is the inventor and main practitioner of the concept of "fast tracking" of specifications drafted in international standards format through the process in Global Standards Bodies like the ISO."

Note 5: From the ZDNet interview mentioned in the article Tom Robertson wrote "Office 2007 enables people to choose from many formats, and now the Open XML Translator has enabled read and write capabilities for ODF as well".



Greatred's picture
Submitted by Greatred on

I may be misunderstanding ISO 8601, as I've only touched upon it in the past, but the example given in this article "2007-28-02" simply looks like a reversed USA date format. If I remember rightly this would be written 2007-02-28 in ISO 8601.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

...that a single-instance sort, upon the date field alone, will yield a chronological ordering of documents or items--without confusion. Simultaneous date field hits are resolved by time field ordering within any given date.

This is a logical foundation for file name prefixes.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Excellent discussion of the topic. This is of tremendous help when trying to educate people about the concerns the free software community has with OOXML.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Who cares, as you said people without Microsoft Word can read the format anyway. It's become a standard because everyone uses it, a "standards body" is only needed when this doesn't happen and everyone has different formats.

It used to be Wordperfect, if someone comes along with something better and everyone starts buying it something new can be the standard.

Sure we could go to ODF and then the millions of people using old Microsoft Word would have problems.

There are much better discussions to have.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Get the Sun ODF plug-in for MS Office, and you can save MS Office documents in a format that everyone can read for all time. Try reading some of the older MS Office and MS Write formats with current MS Office products and you have problems.

Set Microsoft Office to save as ODF as default, and MS Office users can kiss goodbye to forced upgrade cycles through planned incompatibility in file formats. That is why Microsoft and it's trolls are so violently opposed to ODF, and why Microsoft uses XML to wrap proprietary, undocumented binary blobs that makes it impossible for anybody except Microsoft to properly implement OOXML. The truth is that come the next version of Microsoft Office after 2007, Microsoft yet another new set of incompatible binary blobs, to create yet another OOXML format incompatible with the current one to force a user upgrade. That is after all the whole basis of Microsoft's business model, and the reason why Microsoft is refusing point blank to implement ODF filters in MS Office.

I accept your argument that Microsoft through it's abusing control of bundling office suite software into OEM Windows has eliminated competitors like Wordperfect to achieve a market monopoly. Hovever I cannot see how this can be used as an argument for OOXML to be made a ISO standard. What is the point after all in an ISO "standard" that only one company (which already has products compliant products) can implement, other than to confuse the public into not adopting a genuine vendor neutral and universally adoptable standard, namely ODF? I mean why does OOXML need to be given an ISO number if only Microsoft can implement it? Even the name Office Open XML is expressly chosen to confuse people with the OpenOffice suite which is one of many products implementing the ODF standard.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I downloaded it and it does not work with MS Office 2007 and it is useless without MS Office anyways.

In stead use the Office Open XML plugin for OpenOffice created by Novell:
(also provides OOXML support on linux I presume)
or the opensource translator made for Microsoft:

The Wraith

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The MCAN plugin (Microsoft, Clever Age, Novell) is not useful. The quality of the conversion is such that you are almost better off hand-typing the document in the other office product. Or even better, using the old binary Microsoft formats that are handled 85 to 95% accurately by OpenOffice.org.

Among the things not supported: named styles, so most of your formatting changes are lost.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Sorry, but it does matter!

Why? Documents are not only interchanged at this point in time. They are stored, archived and retrieved.

In order to retrieve an archived document you must have software that is the original or compatible. However, commercial vendors and their proprietary formats tend to drop compatibility, once they have eliminated a competitive product. That means you can't access your document any more.

Why is that different with an open standard? Well, because it is not a secrete and you are legally able to write any conversion to a new format that may have superseded it. And surely when many applications support the same (agreed upon) format then chances are much higher that compatible software will survive.

Why is that important? Imagine you need the document in your divorce or to proof your inheritance. Image it is a document that proofs your claim to a piece of land or that you are innocent of a crime?

Busy, documenting OpenOffice.org with screencasts

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Say, if you buy a freezer and start using it. However, the freezer is so designed that once you put your food inside you cannot transfer it to another freezer of a different make, because its incompatible anymore. Would you accept that?

Why then do you want to lock your data/intellectual thought/hardwork/whatever in a document format (eg., MS Word's .doc fromat) that would be reliably readble only by a single vendor's product (eg., MS Word)?

Even worse, imagine if you would need the exact same model in the freezer example, as is often the case with documents–you often need the same exact version of the software for complete reliablity.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I don't know why you complain about reviewing the standard in 30 days when the timeline for a fast track submission is 6 months.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

A fasttracking proces in ISO takes a minimum of 8,5 months and most likely close to a year.
The even faster PAS proces in ISO standardisation used by OASIS for ODF is about 2 months shorter.

The Wraith

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The 30 days is to decide _IF_ MS-Office XML will be placed on fast-track in the first place, not the fast-track process itself. Those opposed to the ECMA MS-Office XML as an ISO standard only have the 30 days to review the 6000 pages before deciding on whether or not to fast-track it in ISO, and to detail their reasons. The argument at this point is not even if ISO should ultimately approve it, just whether they should fast-track it.

I personally do not want to see the ECMA standard fast-tracked by ISO, and ultimately hope it fails to get ISO approval at all.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The only reason you guys rail against the standards process is because the only lame argument is that the format used by the most people is not technically a standard. lol. intellectual dishonesty.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I am anonymous, and I have no idea who you are, either. This reminds me of the amazing effort on Wikipedia. You know the guy who mapped all the timelines as they winked in and out of existence through the course of all the Back to the Future movies? Yeah. That. Wow. Just so much concentrated stuff here!

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

How about highlighting the horrors in ODF as well. The standard as a whole is basically a dump of OOo internals, in important areas it's dangerously weak, like the fact that the entire Spreadsheet spec is depending on your method of counting 4-10 pages. Nobody can implement a spreadsheet from that.. nobody.

ODF is a horrible standard, compared to it OOXML even with it's own horror looks like a work of art. But that just goes to show the type of honesty found in the ODF camp, proponents are entirely unwilling to acknowledge shortcomings of their standard while all to willing to point out flaws in opposing standards.

Instead we should seek to build one truly good standard, an extensively described standard because neither is currently good enough, though as a long time Linux user I hate to admit that in this case Microsoft hit way closer to the mark than we did. They did an extensive standard, suitably verbose but with ugly spots.. I'd take ugly over missing - at least I can implement ugly, there is no way I can sanely implement missing stuff without doing guesswork which will lead to errors and thus bad user experiences, broken documents and assorted pain.

Edward Macnaghten's picture

I will rise to this comment - I assume you are not a troll.

I have some familiarity with the internals of OOo, and more than some familiarity with the ODF spec. I can assure you there is no way ODF is an internal dump of OOo. Remember OOo's "native" format was originally "SXW" files, but they adopted ODF after it was developped with others.

Although there are about ten pages EXCLUSIVELY devoted to spreadsheets in the ODF spec there are hundreds of pages relevant to spreadsheets. The entire table, formatting, styles, charting, base settings and the bulk of the other functionality are shared with other parts of the office specification and are not included in those "10 pages". The entire thing fits together well and is well planned.

No one claims that ODF is perfect, as can be deduced that ODF version 1,1 is on it's way, however it is based on sane XML and existing standards. OOXML is not, nor do Microsoft pretend that it is. They justify their peculiar XML naming structure as required for "performance", and they almost admit that THAT IS an XML-ization of the .doc,.xls and .ppt files. In fact they promote that as an advantage for tham. Interoperability is not on their main agenda.

I have analysed ODFand OOXML, and although ODF is not perfect I believe it is a "truly good standard". It is vendor neutral and well thought out. I am not a Microsoft hater, nor do I think users of MS Office should switch. I believe microsoft should stop playing the bully and adopt ODF for document interoperability. As I said in the article, it is not as though they cannot do so...



Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

[QUOTE]ODF is a horrible standard, compared to it OOXML...[/QUOTE]

You've just proven you don't even know how to spell XML. You're the last person in the world to comment on the quality on an XML format.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

This is indeed an excellent summary of the issues, including the legitimate contradictions and the ECMA whitewashing of same. What I would like to know is, what now? Will the substance of this article be used to formulate an appropriate reply to ECMA by parties with the appropriate position and influence? If not, I fear that even a well-thought-out argument like this one will ultimately go no where.

So, what *is* next? Will you be working to proactively lobby your government and, through international proxies, others to reply to the ECMA spin?

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

you do. Most of your arguments are lame because you hate Microsoft. You are letting the hate cloud your judgement. I loved your really stupid argument:

ODF lets any application define meta tags and stuff them in the document whereas Microsoft uses only for few applications. Well go figure who is better. To me as long as i don't use those special applications, all documents created with OOXML are better. OTOH ODF applications may create 100s of different incompatible ODF documents.

And then your argument on why there shouldn't be two standard. My question is why not? Why is there not a single OS? Why is there not a single application itself?

Why not have two standards that compete to be better? Why you want standards monopoly?

Most of your arguments i find are pretty bad. I wouldn't go in the details of each as i will let other readers see that through.

Btw If you are trying to promote ODF then you are doing a dis-service to them. If you were a lawyer, i am sure people would have stripped you off your degree.

First take your biases away and then argue...

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Now put your corporate hat on, and think about how you would influence the market. Certainly Microsoft, like any other corporation has to think this way.

- If I control the data format, I control a key point: nobody can be 100% compatible with me, and I only need to introduce the fear that your documents will break if you use the non-native software. Plus, I can rely on a steady income stream as I force people to upgrade their software to maintain compatibility with their

- As a consequence of the first point, I will do everything I can to keep the data format under my control. It's ABSOLUTELY key to my future revenue. (And remember in this case, the MS future revenue is $ billions.)

- I will not open the document format as standard. That would damage my future revenue. However..

- If I am forced by the market to open the data format, I'll work very hard to make sure that the open format is closely tied to my product. It's not quite the same as having complete control, but if the standard is tied to my product then I can establish variations in later products which break the standard, but become the de-facto standard over time. And voila, I'm back where I started! You won't be able to use the standard without my software.

- If a competitor standard is available, I will not implement it. Or, if forced to implement by the market, I'll implement it in a broken way. Under no circumstances do I want a document format which is not under my control to take hold in the market. (Remember that future revenue?) I won't ever support the most current version of a standard.

- If a competitor standard is available and taking hold in the market, I'll do all the mudslinging I can. (Oh wait, look at the previous comment!)

- I will whereever possible look for ways to break standards. That includes outputting badly formatted documents; incorporating bugs in my software which crash my software when the format is used; or which corrupts the data subtly.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

To underscore your last point: Microsoft and standards: Expert Testimony of Ronald Alepin in Comes v. Microsoft - Embrace, Extend, Extinguish

(There was a wealth of very enlightening material on the web site for the trial. The web site is down but the exhibits are still around.)

My favorite bit from Exhibit 3096 ("Evangelism is war"), from a company-internal presentation to Microsoft evangelists:

"We must earn the support of ISV's ... We work hard to help our ISV's succeed! ... So, We're Just Here to Help Developers, Right? ... We're Here to Help Microsoft! Microsoft pays our wages. Microsoft provides our stock options. Microsoft pays our expenses. We're Here to Help Microsoft By helping those developers That can best help Microsoft Achieve Microsoft's objectives. Did anyone miss the point here?"

It might be the case that by standardizing OOXML, Microsoft doesn't try to help its customers or the developers of free software Office alternatives as much as it tries to help Microsoft.

That's the concern. Maybe Microsoft's intentions are all good this time (yeah, right!), but it might not be clever to trust in that.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

...as otherwise one sounds like just the sort of zealot one is attempting to paint one's opponent as.

With regard to the application-specific config tags, for instance -- these are intended for application-specific configuration, ie. information tangenial to the document content itself. The content is still readable and renderable by all compliant implementations -- but if an application is designed such that some piece of user configuration is stored with the document, it's free to do that. Further, any vendor interested in reading another vendor's app-specific configuration (should they in fact have a comparable switch) is of course free to do so.

As for your "why not?" regarding multiple standards, one might as well ask what the point to standardization is at all. Why not let competing railroads use incompatible widths for their tracks? Why would you want railroad track width monopoly?

If any of 'yall folks arguing the Microsoft position are in the Austin area, I wouldn't mind getting together for coffee some time; I really would like a chance to meet and chat with you face-to-face. I'm charles at dyfis dot net.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Your argument is whimsical and emotional at best. Its very clear you are in bias of Microsoft's side yourself.

You took the easy way out saying "i will let other readers see that through", which translates to "I'll let someone else provide the evidence", when you clearly have NONE. At best, you went on a personal attack with "If you were a lawyer, i am sure people would have stripped you off your degree."

That's just typical behaviour of someone who has NO CLUE of either OOXML or ODF standards. I bet, that you are using MS Office 2007, and you have fallen in love with the interface.

Let me give you an example why its a bad idea to have 2 standards.
If you do engineering, you have to study both the Metric and Imperial systems for length, weight, etc.

That is, in Australia, UK, etc, we use kilograms, metres, etc.
In USA and anyone else who uses the Imperial system, they use pounds, miles, inches, etc.

So what happens when you do a group project from people around the world?

You get an accident or a potential problem waiting to happen because not everyone is clear on which standard they should be using. And this confusion DOES happen in real life, not just in theory.

NASA has experienced this very issue, and it has resulted in a loss of a few million dollars of US taxpayer money...Flushed down the toilet.

So you want the entire world to waste time and money converting docs back and forth between two standards? (Time IS money)

You speak of "standards monopoly", when the only company that is trying to avoid an international standard that is ODF, is the very company that is known for monopolistic practices! That's right, MICROSOFT. They developed OOXML because they knew they'll lose control!

They could've adopted ODF, and NO ONE was forcing them not to. They chose NOT to accept ODF on their own accord. Why? Because the whole point is about control. CONTROL = PROFIT.

Microsoft controls documents standards in an effort to corner everyone to use MS Office. They will NEVER release ALL the details of their document formats, and you will be forever needing MS Office to achieve 100% accuracy in reading doc. This is why when you try to open a doc file in OpenOffice, Abiword, etc, you will always get some issue with the layout. Microsoft knows that the average user will never accept other office applications when it cannot read their files correctly. This is how they keep their dominance. They make it so that you need them, and there's the feeling that you cannot leave them.

The point of ODF is to allow EVERYONE (including Microsoft) to agree on one document standard that the WHOLE WORLD can adopt. It frees everyone the need to specifically use MS Office. They can use whatever office suite or application they choose. And that's the point. NO ONE is tied down to Windows and MS Office. NO ONE is cornered into paying for a copy (license) of MS Office. (which is what MS does NOT want).

This is a point you've COMPLETELY fail to understand. I can tell its completely over your head.

YOU ARE doing are MAJOR dis-service for OOXML by putting YOUR personal opinion into it. Your personal opinion has NOTHING to do with the document standards.

OOXML isn't a completely open standard. It has proprietary or vendor specific functions that you need to know in order to get it 100%, if you were to implement a word processing application yourself.

Such functions include:

autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)

footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement)

mwSmallCaps (Emulate Word 5.x for the Macintosh Small Caps Formatting)

suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing)

So don't pull this nonsense about bias. Its bloody obvious who's bias here.

Microsoft talks about "interoperability", but do they really do it on their own accord? OR is this all a farce because the EU's anti-trust case is pushing them into it?

Seriously, if MS wants interoperability, all they had to do is completely open their formats. Then there will be NO NEED for both ODF and OOXML in the first place!

They won't, because the ultimate goal for them is to profit on a massive scale. To profit, you need to control and corner your customers into playing your game, under your rules. In the tv show, 24, Jack Bauer calls this kind of thing: "leverage".

And that's the key issue. OOXML only exists because ODF exists. ODF exists, because Microsoft won't COMPLETELY open their existing formats to the world. This is all because they want you to be completely dependent on a specific application or product they happen to be selling...That is, MS Office.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Why not have two standards that compete to be better? Why you want standards monopoly?

Why a Standard Monopoly?

There is absolutly no reason not to have a standard monopoly. Monopolies are good when held by standards, but they are terrible when held by companies like MSFT.

If there is a standard that has the monopoly, if anyone wants to make a program to break that standard, that program will fail in the market. If a single company has a monopoly, only that single company can make programs.

Why not 2 Competing Standards?

If standard monopolies are good, competing standards are bad. What is a standard? A way of doing things agreed upon by all. With that in mind, there can be no such a thing as "competinng standards", unless one is declared the winner and the other exterminated.

Having 2 standards only leads to one of two things: confusion and/or wasted development resources (which will come with an increased number of sickening insects). Gee, there are two standard ways to implement the feature I want to code, which do I implement. Or do I need to implement both?

Extermination is exactly what MSFT wants to do with ODF. It has no intentions of competing with it. If OpenXML becomes a "standard", it will win this fight not because of technnical merits but beause of installed base. If MSFT looses in this fight, many governments (worst case) worldwide will no lonnger be able to use their format, which will mean that people will want to use ODT atleast for comunication with their government, which will mean that they will be introduced to a differrent format than theirs, which will mean that they'll demand good support for itt of their office suit, which will mean that cuite a few will choose (rather than be forced to choose) the ODT format, which will mean that MSFT will loose their hard-stolen monopoly powers, which is something that they definetly do not want.

So which are we going to have, a standard office suite format, or the current propietary non-standard?

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

arguments, I've found in a lifetime of defending what I believe in, are signs that someone has not done their homework.

Could you please define what you mean when you say "because you hate Microsoft"?

What part of Microsoft are you defending? What behaviour of Microsoft are you defending? Who are you defending in Microsoft's "hallowed halls"? What division? What part of Microsoft do you claim is under attack? For what reason?

In short, I find your arguments unconvincing and shallow.

For my part, I remember only too well the constant refrain of anguish in computer mags every time Microsoft released a new MS Office version, as people found, much to their dismay, that old, well-loved (or at least -tolerated) file formats, etc, were not fully supported in the new versions, and the people complaining had lost some important part of their documents' formatting. And that was from people who used MS Office professionally.

Given such a track record, I think it wise to look such a gift horse in the mouth - it's not guaranteed to have any teeth.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

...apart from the fact that, being an open standard, it's fully documented, therefore relatively straightforward to apply. D'OH!

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I agree that open standards are best, but ODF has major shortcomings in it's spreadsheet format. MS XML has won it's raison d'etre fair and square. ODF will have to improve it's spreadsheet before they can truly make MS irrelevant.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Nice article. I learned quite a bit from it.

One thing that could be addressed more is the need for interoperability over time, not just interoperability from one currently-available application to another but to posterity's available applications. You hint at this with your mention of reliance on undocumented internals of older (and currently unsupported) applications. When looking to the future this becomes more important as more and more vital data is stored electronically.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

wow, what a great article, i agree with everything you said,

MS scumbags are trying to keep the monopoly on the office apps by making up their own standards,
there shouldn't be more than one way for doing something, as if there are, none of them is a "standard", if a new standard is needed, then the previous standard should be improved to accommodate the needs,

to the MS-fanboy above:
its called a "standard" for a reason you moron, its not designed to compete against microsoft standard wannabes,

MS is anti OPEN anything, not integrating the ODF into their office apps is a clear proof of that.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The 1900/1904 distinction is needed. These dates get used in spreadsheets. People actually put dates into spreadsheets AS INTEGER VALUES. No joke. There are business-critical spreadsheets that compare dates against literal integer values. I mean "123456" and such.

The 1900/1904 distinction changes the numbers in use. Spreadsheets are wrong if the wrong values get used.

Edward Macnaghten's picture

There is no reason for the date to be stored as an integer in the saved tranferable file. The conversion between dates and numbers - however they are entered or what formula is used - should be done in the applications themselves. A date should be saved to file and transferred as a date regardless of how it is created and manipulated in the application itself.


Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You could justify the use of an integer format if the aim was to make your dates independent of any particular calendar system. I don't know whether the concept of a Julian day number has ever made it into an ISO standard, but it is an important and well established one.

Of course, what's much more difficult to justify is a time scale which is almost but not /quite/ linear, with a discontinuity chosen to suit the agenda of a particular company with monopolistic tendencies.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

There is no realiable way to convert simple numeric date types into complex ISO dates. Numeric dates have severly limitations in interpretation. However this makes them very usefull for calculations.
You can actually use date information fields in normal spreadsheets to multiply with. For this use ISO dates are useless.
Hoever converting from numeric to ISO and back requires interpretation of the context of the spreadsheet. This is in general beyond the scope of spreadsheets. We will have to wait and see what the ODf implementations and the OpenFormula's committee comes up with.

Suggesting that numeric dates can be converted to ISO dates and back is however not evident and no 100% reliable measure for conversion them in spreadsheets has been found.
This means that spreadsheets for 100% reliablity should also use a complex internal date format that is equivilent wiht ISO dates and also that they not be 100% reliable with legacy spreadsheets.

The whole date issue is much more complex than beats the eye. I am amazed that serious ICT expert think that using ISO dates in spreadsheet is a good solution. A much better solution would have been to use ANSI's date1600 format in both ODF and OOXML spreadsheets and then have the date1900 and date1904 formats only for deprecated legacy use in OOXML.

The Wraith

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I have been a programmer and a programs designer for more than ten years. It is fairly easy to show combinations of date files you can't reliably convert to ISO dates.
You suggest Excel can but I often have to tell Excel to display certain fields as date format manually.
The fact that you think there is 100% reliable conversion possible shows that you still do not fully understand complexity.

Geoffrey Lehr's picture

Care to give an example or two of dates that can't be converted?