When is a standard not a standard?

When is a standard not a standard?


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 - 2.15.1.95), 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 - 5.1.12.41). 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"(6.2.3.17) 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" (6.4.3.1) – 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 (6.2.3.17 ) 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 – 2.15.3.26) and useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules -2.15.3.63).

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.

Conclusion

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.

Notes

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".

Category: 

Comments

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:
http://download.novell.com/SummaryFree.jsp?buildid=ESrjfdE4U58~
(also provides OOXML support on linux I presume)
or the opensource translator made for Microsoft:
http://sourceforge.net/projects/odf-converter

The Wraith
http://ooxmlhoaxes.blogspot.com/

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?

K<o>
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...

Yours

Eddy

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:

Section: 2.15.3.6
autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)

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

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

Section: 2.15.3.51
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.

Eddy

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
http://ooxmlhoaxes.blogspot.com/

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.

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

I'll try
I have several numeric fields in that are in a single hidden reference column but formatted as dates. They contain values 39083.00; 7; 12; 28; 30; 31; 365; 366.
Only the first one is really ment as a date the others are just poorly formatted as a date when the whole column was formatted
Somewhere else on the visible spreadsheet part are other date formatted fields that are a combination of these fields based on whether you want monthly or weekly paychecks. How to store these fields in your ISO format and get the same results the original spreadsheet did?

Edward Macnaghten's picture

It seems you have written non-portable macro code that uses a feature almost exclusive to Excel. As a programmer I would suggest the cells should be "formatted" correctly to reflect what they contain. I would suggest this has nothing to do with interoperability but coding practices.

Eddy

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

It appears you agree that the suggested spreadsheet cannot be reliably converted using iso dates.
The suggested example has nothing to do with macro's but is an example of poor formattting by the spreadsheet user. For 15 years all kind of spreadsheet users of have at will mixed numeric and date fields and combine them into formula's and references.

The basic problem in conversion of spreadsheets with numeric date fields to iso date field is that there is no reliable way to determine if a numeric vualue is ment to be a real date or just a numeric value. A real user can probably easily determine that because such a field might have a big label above it stating "Employed since" but an automatic program cannot interprete that kind of extra info.

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

I fail to see the problem.
The values are interpreted as dates at runtime and stored "as is" in the file as numeric data. No need to convert to or from dates, they aren't dates, they are just treated like ones when loaded.

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

Wow, you are exactly describing the exact properties of the date1900 formats in OOXML.
Storing them in a file as numeric, no need to convert and interpreting as date them on runtime.
Amazing...
That is exactly what OOXML suggests you do.
You just gone from someone against that date format now describing it as a solution.

Geoffrey Lehr's picture

Except for the first one, they look like date differentials or definitions to me (a week's worth of days, a year's worth of months, etc), so without a baseline date (which I presume the first one is), they can't (shouldn't) result in dates. They could just as easily be a bunch's worth of bananas, or a carton's worth of eggs, so, yes, since they're not dates, they should be stored as numbers, and converted to a date if/when they need to be made permanent. The first one, however, should be stored as an ISO date (whatever that date's value is; I don't know or care, but I would know if it were ISO).

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

They look like is a good description. I picked numbers that might have some meaning to people. However a conversion program cannot distingish between numbers in that way. Also we stil have no idea how ODF will solve things like subtracting dates which can have different time-zones, how ODF will deal with iso 8601 periods in formula's and lots more.
I think that when ODF finally shows up with a formula's languages they will probably have reduced the ISO date format to a subset that can be represented by numerics completly dropping timezones and periods and anything that gives iso dates more value as a format above a numeric format. Else it just would be to hard to implement for every software builder.

A ISO date is just a complex representation of a continuous timeline. A numeric date is a simple representation of a continuous timeline. For use in spreadsheets, ISO dates are overly complex and will need to be toned down dramatically so they are not much more than a formatted numeric date.

Geoffrey Lehr's picture

No, a conversion program can't recognize the meaning of different numbers, which is the entire problem of using the 1900/1904-based integer in the first place!

If the timezone is specified in the ISO date, there's no problem whatsoever with any manipulation, and if not, well, a user has the same problem anyway when entering dates: are they entering the current timezone? Universal? Something else? Not a unique problem.

I think that you underestimate software builders, and overestimate the difficulty of implementing ISO 8601, but time will tell.

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

Using the ISO 8601 format would be a valid ch=oice is there was a need for the more advanced features this format has.
So if there is a requirement for timezones or datetimeperiods to be stored in spreadsheets cell (and I must say I have never seen anybody even remotely suggest such a requirement) then the ISO format would be a good choice.
But at the moment date storage requirements suggest that a low level numeric date field is still a logical choice.
Also in the OOXML spec a subset of ISO 8601 dates for spreadsheet cell storage would be be easy to add in a future version (allthough not nescesarily easy to implement).

The Wraith
http://ooxmlhoaxes.blogspot.com/

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

Sorry for my english :[
Convert datetime to numeric is very easy, and nobody has question about this.
But all discussion about converting numeric to datetime.
I have done one test in OpenOffice Calc: set cell A1 = 1980.01.01, set cell A2 = 1 and A3 = A1+A2. After that, I have formated cell A3 to DateTime (dd.mm.yyyy) and have got display result = 02.01.1980. Then save file and have seen that OpenOffice write into file. What do I see? First cell have value = 1980.01.01, next cell = 1 and last cell have formula. It is very clear.
But if first cell have value like Open XML that I have seen value = 29221. And if I don't correct use base date (1900 or 1904) I will have error, but I never have error with OpenOffice format.

When we use open format we must know how convert value to date

Sergey

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

This is how GDI+ (gdiplus) works.

An EMF can be old-style plain GDI, pure GDI+ (embedded in "comment" blocks in the EMF!), or a hybrid that can be rendered via either GDI or GDI+.

So within an EMF, you have comments. Within the comments, spanning them in fact because comment size is limited to 8 kB, there is an EMF+. The EMF+ is composed of many records. One type of record is the "Object". There are different types of Object, including "Image". An Image Object can be a Bitmap, EMF, or other.

Note the recursion. The Image Object containing an EMF may in turn contain an EMF+. Also, the "other" could be HTML (IE7) or OOXML or Windows Media Player data or whatever.

Obviously this can and will be abused; the plan is clear. That said, a document format ought to allow embedding anything and everything. One might even embed OpenDocument, LaTeX, *roff, XCF (Gimp), Adobe Illustrator, or Postscript data.

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

ODF has created a special object for OLE linkings and embedding.
You refer in OOXML to just a type value but on the other hand you think creating a special embedding method for it in ODF is ok ?
This is much weirder in ODF as they are supposed to only create interoperable documents and it now has OLE linking and embedding in it's specifications which is not on available on all platforms.

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

That is an embarrassing reply.
Firstly because ODF also has special embedding for Sun's java applets as well so it is not just something from MS that get special treatment in ODF.
Secondly because OLE linking and embedding is not limited to embedding of propriety Microsoft formats or closed formats what you are suggesting. You can also OLE embed ODF files in OOXML and OLE embed OOXML in ODF.
Thirdly you mention a special enumeration type for OLE embedding as an issue/problem in the OOXML spec but when it comes to ODF special exemptions in the specs it is suddenly ok ???

It look like watching at the different specs with a double standard.

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

"I understand how people can see it as a standard.

Except it is not."

Standards: De facto or De jure.
Office's format may not be the de jure standard since it hasn't been established by law but like it or not due to its high market penetration it is a de facto standard or standard in "practice". Which one is best? That's open to argument but tt is important that people recognize the difference before really make assertions about which is more legitimate.

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

Except that Microsoft keep changing the "de facto standard" so you have to keep upgrading you copy of Office.
:-(

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

... that 95% of the arguments for OOXML simply trumpet the same arguments, always put forth without evidence by various Microsoft shills and PR guys. Have people really lost the ability to think?

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

Your document is one big container of opinions that have little to do with reality.

Where were you when ODF was ratified trough ISO.
ODF standard is not ideal either.

An example.
You state: Why is there a special enumeration type for meta files or bitmaps. So why has ODF special embedding objects for java applets and other embedding for other objects ??

So why is ODF as an interoperable format not supporting ISO 216 standard paper sizes but has it in stead flexible printer paper sizes which are not really interoperable unless they happen to conform to a standard which means that standardization is implementation defined in stead of format defined.
You are also suggesting that a converting stringtype percentage to a numeric is hardly more demanding than converting a decimal number. firstly you should understand that a decimal point is hardly a standard. I use a decimal comma. For a name that requires stringlike verification anyways thatis not a problem but for a value it is actually is. Storing decimal numerics without a decimal point is actually more standard than using a decimal point or a decimal comma.

You state that Microsoft should store their unique quirks in a generic "config" tag or similar rather than on the main name-space. Reading your article I will now state that if they would have done you would now have written about the evil Microsoft hiding Office setting in config setting that are actually completly non interoperable by design. ODF's config setting items are a huge implementation nightmare. Only an ODF fan would suggest they are a solution. Even the custom tags in OOXML are far better as at least they require custom schema validation and are unique because of the XML custom namespace use.

Your oppinions are noted but seems like you based it purely on onesides very limited research and knowledge of format issues with OOXML while you seem to support ODF which has also lot's of it's own issues.

A big issue of ODF is that this standard made for interoperability does not know any two interoperable implementations yet.

Is OOOXML an ideal standard ? No.
But actually fasttracking standards never are because they are standarsds derived from existing technology.
It is easy to hammer on OOXML for it's compatibility issues which aren't always the optimal solutions but frankly this whole article feels like you would not have minded the same issues if they just would have been in a format that was used by OpenOffice !!!!

The Wraith
http://ooxmlhoaxes.blogspot.com/

Edward Macnaghten's picture

The Wraith:

Thank you very much for your comments.

I agree with you that ODF is not perfect, I never claimed it was, but after examining both ODF and OOXML I would say ODF was miles ahead as a candidate for a standard, in fact I think OOXML does not meet the basic criteria to become one.

I agree with you on the ISO 216 and ODF - it should support it instead of just storing the page widths and heights despite it is easy for an application to extrapolate the ISO 216 name from the sizes. What ODF should not be changed to do is make up it's own non-standard cryptic page names which is what OOXML has done.

As for your arguments on the "config" tag I think you have missed the point of it. Microsodt Office has unique configuration settings only relevant to it, so does OpenOffice.org, so does KWord, so does AbiWord, so does Lotus Notes, so do every other office suite in existance. At the moment I can create a file in KWord then load it in OpenOffice.org and then in AbiWord. Each presents and can manipulate the content satisfactorily and pass it on. Although some configuration option changes were not transferred because they were unique to the previous application does not effect interoperability. To limit the "config" options to those of one application simply is limmiting the format to that one application locking out use by all others, some would say that is Microsoft's goal.

For instance, when using OOXML it is possible to specify formatting quirks unique to MS Word 2003, but not possible to state the ones unique to KOffice. That means that MS-Word can save and load the file without problems, but Koffice cannot as settings would be lost in the interim making the format impossible to use with Koffice. However, both Koffice and Word can use ODF satisfactorily (or could if MS were not so negative about it). Although unique application settings could be lost when passing the document from a user of MS-Word and KOffice, and I agree that is not perfect, it is a million miles better than simply ignoring KOffice and all other non Microsoft office programs exist.

Hopefully in the future applications can store and pass on "config" settings not applicable to it in a manner similar to the "about:config" screen in Firefox. However, the lack of this in current applications is the fault of the applications, not the format.

Most configuration settings define some precise operation and rendering quirks. Operation quirks are not relevant to inter-operability and to transfer a precise representation of a rendered document you should use a standard like PDF, not an editable document format, which is really for work-in-progress transfers.

As for accusing me of criticizing Microsoft if they tried to improve relationships with other office suite vendors, you have me very wrong. I would be singing their praises if they did that, but unfortunately they are not.

As for the JAVA Applet point. JAVA is not an ISO standard, however it is on the verge of becoming an open source project and is run by the Java Community through the Java Community Process and it's APIs are published, also the APPLET tag was taken straight out of HTML4. Although this does not make the APPLET tag ideal again it is a million miles better than including closed proprietary formats in what is supposed to be an open specification.

Am I one-sided? Maybe I am, but that is AFTER I analyzed both ODF and OOXML specs. I came to each spec with an open mind. ODF is not perfect as a standard, but OOXML is unacceptable as one.

ODF IS interoperable, and being used as such. OOXML limits functionality to that of Microsoft Office. It would be nice if Microsoft joins the rest of the world in supporting ODF properly, such us including it in the Save/Open dialogs and being able to make it the default format, then these arguments and articles will all become moot and we can move on happily exchanging documents with EVERYBODY.

Eddy

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

Could I point out that there is a petition here, set up by me, to persuade the UK government to standadise on ODF

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

Charles, I wish I was in Austin, we'd be having that cup of coffee today. I doubt we'd convince one another of anything, but I've found it difficult to locate people willing to debate these issues in person.

Cheers,
Doug

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

Excellent article.

My one comment is that your brother should consider long term access to his documents. Has he ever tried opening Word documents from a few years ago?

Only an open standard remains accessible into the forseeable future... even if the software to load your document is no longer available, the fact that the standard is open ensures that you could (in a worst case scenario) consider writing custom code to load your old document.

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

I was referred to this page via Groklaw on saturday. I also commented on Groklaw. However Groklaw removed just about all of my comments from this page:
http://www.groklaw.net/article.php?story=2007030308154032#comments

It is sad that anti-OOXML sentiments leads to removing of comments on what once was an open site. The same for comments made on the grokdoc objections discussion page
http://www.grokdoc.net/index.php/Talk:EOOXML_objections (points 22-31) which are ignored because they are not in line with groklaw's anti-ooxml policy.

I notice that many of the objections mentioned by opponents of ooxml (including a lot by the national bodies and on this site) refer to the objections found on the Grokdoc/Groklaw discussions. It should be worth mentioning that those objections are based on a policy of removing ony opposing oppinions.

The Wraith.
(quite shocked by Groklaw's comments removal policies...)

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

For anyone following along at home:
Here is a diff of the edits Mr. Wraith, (trading under the name HAI at grokdoc, apparently), added:
EOOXML_Objections_Clearinghouse&diff=6706&oldid=6699

and here is the edit in which they were removed: diff=6719&oldid=6716

As far as I can tell in reading the history, NO comments by HAI/The Wraith were removed from any Talk pages, contrary to what e claims above, however, comments were removed from the EOOXML Objections Clearinghouse page, per the claim that they were not objections to EOOXML, which they wern't -- they were discussions about the objections, which were addressed and discussed on the talk page.

I can't comment on the claimed removal of comments at groklaw.net, as it lacks a public history review function.

-- An otherwise uninvolved reader.

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

Most of my comments were made in this article http://www.groklaw.net/article.php?story=2007030308154032#comments
and sever articles in the weeks before that:

Of course you won't find them anymore as they were removed.
Try adding in a article positif on OOXML or nagatif on ODF and it is gone in a few minutes

The Wraith.
http://ooxmlhoaxes.blogspot.com/

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

That's why the blog host trapped you; if you are indeed the same Anonymous person referred to in
this response to a similar lament there.

Honest opinion is always welcome on Groklaw. Not so dishonesty, personal attacks or bad language. All this is made perfectly clear on the very page where postings are authored, and it has been the subject of countless discussions over the years. Fact is, since we are only guests we have to abide by the house rules.

I never saw your many postings, I think; according to PJ, not many others ever did either.

-Roland

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

I think honest opinion is only welcome on Groklaw if it supports the views of the site.

The Wraith

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

For those of you arguing the need for a SINGLE, OPEN STANDARD, how would you be arguing this point, or doing anything on the WWW, without a single, open standard, called TCP/IP.

That's right. Single OPEN standards create growth, collaboration, entertainment, financial opportunities, education, and so many wonderful things (porn included). Without standardizing on a SINGLE, OPEN STANDARD, we would not be communicating. Novell would speak IPX, Microsoft would speak non-routable NetBUI, and the only people on the Internet would be the Net BSD folks.

So stop bringing up petty arguments for why 'there should be more than one standard', 'de-facto standard', or 'who cares if Microsoft uses proprietary extensions' crap. If you feel there should be more than one 'standard', turn on NetBUI (you will have to add it, unless you are running Vista, because Microsft stopped supporting it, just like all the other MS de-facto standards you buy), and get off of our SINGLE, OPEN STANDARDs based TCP/IP network.

Brick

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

The date formats reminded me immediately of "Office Space" movie.

IOW, I think, EOOXML is good for industry: we would need to hire more people to convert year from "two digits" to something human readable!

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

What has human readabiltiy to do with storage of dates in an spreadsheet file in a zip package.

Showing a date to a user in a spreadsheet is determined by the included formatting and the implementing application.

Actyally we still have to wait and see how ODF inplementations will deal with showing dates according to their timezones. Will spreadsheets convert to the timezone of the reader or show the date in the timezone of the maker ? How will those spreadsheets deal with files created in ne timezone and editted in another timezone. Remember that in spreadsheets in general dates are generalle inserted without with a timezone so that it is up to the implementation to apply a timezone. Enjoy the hell that is ISO dates when using spreadsheets globally within a company.

At most ISO 8601 should be an alternative storage format for dates in spreadsheet cells. However the complexity of such a format is startling and people do not understand that it is MUCH MUCH more difficult for spreadsheets interpretation than a numeric format. Having build a small spreadsheet once the idea of ISO dates alone is just giving me headaches

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

[anonymous *coward*? no, just too lazy to remember yet another login . . .]

If MS should abandon OOXML and adopt ODF, we know from experience how they work with standards. As they did with HTML. They soon tack on their own "enhancements" that only run under Windows (as they did with Java as well). Surely the standards folks won't mind if MS just throws in an *extension* saying if this document is opened under MS Office you'll see the formatting, but if you open it in OOo you'll just see plain text? Throw in enough enhancements, "certify" enough MS techs in corporate IT departments so they get a real warm and fuzzy feeling about implementing the MS Office extras, and MS can develop widespread reliance on its "enhancements" to ODF. We wouldn't want standards to stand in the way of great new features, would we?

Even if the EU really held MS's feet to the fire and forced them to fully disclose the details of the enhancements, MS would make them complicated enough that they could keep rolling out new ones faster than open source folks could implement them.

Open source folks have the competive disadvantage that they are developing in an open, transparent system, where MS engineers can immediately pick up on anything valuable in progress and duplicate or enhance it, releasing it simultaneously, and make it interoperate better with their own (under this scenario) ODF enhancements. But MS, even if forced to eventually disclose the code or APIs of such ODF enhancements, does all its development behind closed doors, making it as hard as possible for open source folks to develop equivalents until late, when MS is already preparing to release the next version of the enhancement. So MS can continue to parasitize the works of open source developers, while keeping the world tithing on what it develops. A cycle that will continue until people really add up the costs of using that next incremental goodie from MS.

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

Open XML is a confusing name. XML is a standard and it is already open. true or not?

EOOXML is simply cryptic.

None of the two names indicate the usefulness of the standard, unlike ODF (Open Document Format). There is no needs to put XML in the name just because the format use it. Why not simply call it OOD (Office Open Document) or better MS-OOD (Microsoft Own Our Documents)?

It is true that the other naming convension aren't meaningful either (IEEE-1394, ISO-639), but they are related to the standardization process and they are used because they implicitly say they are a standard and where to get the description.

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

Actually ODF used to be called Open Office XML format when it started it's life in the OASIS technical committee. However they changed the name that related to much to OpenOffice to match the fictive name (Open Document format) mentioned in some government report on standard for documents (not sure if it was an EU or a US report though).

The Wraith

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

I suspect the "fictive" name was "ODA" (which IIRC had several expansions during the decade around 1990. Seems to me one was "Open Document Architecture". There was a big standards fight between ODA and SGML (which itself might be considered a predecessor of XML), which was effectively won by SGML and the ODA community essentially dissolved.

DeepOne

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

Ed,

I read your soliloquy with interest.

However, I find myself torn.

In general, I believe standards are good. However, I have found what I consider counter-examples... Cases in which standards, rigidly observed, render the subject of the standard more complex, burdensome, and opaque than necessary. None of my examples target Office products, so I beg your indulgence...

In the programming world there are language standards. One of those standards is ISO/IEC 7185 Pascal. Per the section 6.8.3.5 "Case-statements" states "One of the case-constants shall be equal to the value of the case-index upon entry to the case-statement; otherwise, it shall be an error."

Various Pascal vendors have --in my opinion-- properly violated the standard by providing a vender-supplied-violation to section 6.8.3.5, namely a "catch-all" statement (usually implemented as otherwise or else). Alas, there is no syntactic standard for the "catch-all". Therefore, porting code from one compiler implementing a "catch-all" to another implementing a "catch-all" requires some minor text changes. On the other hand, writing code that strictly adheres to the standard results in code which in my experience (a) is more complex, (b) has reduced readability, and (c) has increased maintenance costs.

Many other areas in the (Pascal) standard are also deficient... to the point the standard is pretty much irrelevant. While I find those details sufficiently annoying that I would not willingly use a product that implemented only the standard, those details are not relevant to the point I am trying (probably unsuccessfully) to make... that while official standards are generally good:

  • they are never perfect;
  • they are out-of-date as soon as published because innovation, fortunately, does not stop;
  • the standards process may be hijacked by parties with political agendas, which results in standards that are of limited use to anyone else.

I have no good solution to the problem... Other than my old man's general caveat:
"Scrutinize everything, trust no-one."

Keith
Full disclosure: I own stock in MSFT & SUNW. I use MSFT and Sun products. I have been programming for 30+ years. And have worked on O/S and hardware platforms that no longer exist (thank goodness!). I've written applications in many dialects of Pascal (many of which also no longer exist), as well as Fortran, Lisp, Prolog, PL1, Java, JavaScript, HTML, ColdFusion, C, Basic, Ada, assembly and as well as other languages which are fortunately extinct. I've written various kinds of language translators, successful commercial applications, federal government applications, robot, space-shuttle and accident simulations, data manipulators, etc. None of which means anything and all of which sounds more impressive than is true in reality.

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

Scrutinize everything, trust no-one.

My grandfather had a saying he liked to use: "Figures don't lie, but liars sure do figure."

Barry Jomeneos's picture

I think if it's not ready yet, MAYBE like 6-12 more months. IMO it's ready now, but some people, such as yourself, disagree.

Is there something specific you're waiting for or looking for to make it official?

-------------
Ajax Upload Script

engineers's picture

OOXML is supposed to be a standard for document interchange that uses XML but sometimes nothing can be perfect. Before a company starts to ship programs they put engineers to the test. Sometimes flaws can get unnoticed i guess.

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

agree that open standards are best, but ODF has major shortcomings in it's spreadsheet format.
SIG
----

samuelstanislas's picture

We always choose the simplest path possible. I guess this is why we prefer using Microsoft Office for our documents. This way we're pretty sure that everyone who needs to receive them will be able to open them. M.O. has become a standard when dealing with documents. Some of us here feel the need to use other, perhaps better, applications that suit our needs but that aren't compatible with other people's habits.

TrisT's picture
Submitted by TrisT 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.

kartuş

Author information

Edward Macnaghten's picture

Biography

Edward Macnaghten has been a professional programmer, analyst and consultant for in excess of 20 years. His experiences include manufacturing commercially based software for a number of industries in a variety of different technical environments in Europe, Asia and the USA. He is currently running an IT consultancy specialising in free software solutions based in Cambridge UK. He also maintains his own web site.