I think that the term "white paper" was being used tongue-in-cheek by the author to dig at the way there are so many Microsoft funded "white papers" out there which are completely biased and contain lies (whether it be by falsified or misrepresented statistics, omissions of important details, or just outright lies).

The details that you have complained about are at best picky and at worst pedantry. The point is Microsoft is out for number 1 = Microsoft. It serves their interests to keep everyone using their products and they will do anything to destroy the competition whether through marketing/misinformation (like their "white papers"), buy-outs, legal action, or changing the laws of the land by bribing politicians.

Considering that OOXML is very far from the XML used in Office 2003, frankly, I'd say that this early format was a dud. Moreover, at that time this 'XML' format wasn't XML-conformant - as in, it probably worked with MS's XML v3 parser, which isn't even XML compliant.
Second: of course, since the base format for ODF was OpenOffice.org's document format, which WAS (in 1999) XML-based - so it was Open Office XML, as in OpenOffice's XML. Said format was already parsed by several applications, and OASIS' goal was to extend it so as to cater to as many people as possible. Note that Microsoft was part of OASIS at the time. Strangely, they never mentioned anything during ODF's design that hinted at incompatibilities with their suites. Now they have the gall to say that ODF can't reproduce their documents faithfully, and that they weren't asked for advice when drafting ODF.

Had you read the whole article, you'd see that said bias has a source: OOXML is awkward, designed for Microsoft products to the exclusion of all others, and would be, as such, unworthy of being called a standard. This has been described in details with practical examples. As such, I'd respectfully recommend you get your head out of that place where the sun doesn't shine and read the whole of it - you might learn something that isn't mentioned in a MS Office advertisement for once.
---
A computer is like air conditioning: it becomes useless when you open windows.

I have to wonder if the very selection of the name OOXML wasn't a deliberate attempt by Microsoft to try to create confusion in the public mind about the OOo of the Open Office.org. Imagine the reaction if Open Office had tried to call their word processor M$ Terd, or something similar.

I have seen so many MS evanaglists going around tom tomming about the spreadsheet formulae... but what use are they if they cannot map into the legacy binaries. Secondly what ODF compatibility is being referred to. Anyone making such statements is nothing but a copyprinter of MS's baseless claims and not worthy of being called a technologist. Where is the demonstrable evidence of OOXML supporting ODF formats.. and please do not refer to MS sponsored Novell's ODF converter project....

Dear hAl
Thank you very much for the commenting on this article. All feedback is greatly welcome, and you have obviously taken a lot of time and effort in your comment. I appreciate this greatly. However, you have raised some interesting points that I feel I must address forethwith.

"Firstly this document is indeed serieusly misrepresenting history history on OOXML suggesting ODF has a much longer pedigree where both XML office formats started about 1999-2000."

The XML that Office 2003 uses is greatly different to the MS-OOXML submitted to ECMA. It was neither the default format used, nor was it adopted to any great degree, and nor could it be used to save and restore documents reliably. It was also developed behind closed doors with little community interaction. This greatly differed from the StarOffice then OpenOffice formats where they developed their XML standard from the ground up to be interoperable, and refined it with close co-operation with the community.

"Secondly it is putting examples up from OOo and MS Office which although using each format are not per se good implementations of each spec and also with OOo at least two years longer to implement an implementation of ODF."

The examples given are not contrived. It is the ODF and MS-OOXML XML representations of the meat of the said documents. I am afraid I neither understand the point not relevance of your OOo reference. What two years? Longer than what? At time of writing of the article NO application supported MS-OOXML, However, the white paper compares the formats, not applications, so this is digressing anyway.

"Thirdly although ODF is supposed to support SVG the example show that pasted SVG in ODF (which is supposed to support SVG) is embedded as a separate file which is probably also allowed in ODF but makes the whole reusing of SVG in the spec sort of redundant where the pasted SVG is actually converted to VML in MS Office 2007 and becomes a native part of the document. So even although ODF has native SVG support the ODF implementation forgets that whilst the OOXML implementation of MS Office is the one to recognise the SVG correctly and convert it to native VML. This example only shows why it is sucky to use a comparison in ready made implementations in stead of comparing the actual spec."

The example I guess you are referring to is the "Dalek" picture embedded in the "Word Processing File". This is a "Jpeg" picture embedded in the document. Both formats permit this, but the manner ODF does this, using a "draw:frame" tag and a "draw:image" tag is considerably more elegant and interoperable than MS-OOXML's "v:shapetype", "v:stroke", "v formulas", eleven "v:f" (with the cryptic "eqn" attributes), "v:path", "o:lock" and "v:shape" tags in MS-OOXML.

You also say that: "... So even although ODF has native SVG support the ODF implementation forgets that whilst the OOXML implementation of MS Office is the one to recognise the SVG correctly and convert it to native VML". This sentence is somewhat nonsense. What do you mean the "ODF" implementation? ODF is a format. Also I am very happy for MS-Office in that it can convert SVG formats to VML, though the functionality of the applications are not relevant to the formats themselves. I feel I need to say though that I would be a lot happier if MS-Office actually saved files in the more interoperable SVG, that has been accepted as a standard by W3C, whereas VML has not.

"Fourthly this document supports reuse of standards like SVG and MathML which is basicly a good thing but does not notice that these are not document standards but webstandards that for instance do not support the rest of the ODF specs tags for revisions, bookmarks, footnote or anthing else that might combine into the markup. when revising a single digit of a math formula in an ODF doucment that would therefore require the entire math to be marked as a revision or (if possible) the math to be split up in multiple parts."

When you say " ...not document standards but web standards" I assume you mean the standard is more suited to web pages than editable documents. I admit, I have done limited research, but what research I have done would suggest you may well be correct. However, as you point out in your comments there are working solutions applications using ODF can implement to get around this limitation, and I would suggest the way forward is in the next version of the standard to enhance the SVG and MathML specifications, or create a subset of them, to facilitate the required functionality easier rather than using a proprietary single-vendor method of storing the information.

"Fifthly this document suggests that using shorter tags in OOXML requires more tags ? However this is not substantiated. Also it seems the OOXML spec mainly uses short tags for those item that are uses most like the main namespaces w=wordprocessingml and command tags for line, rows, colums and cells and uses longer descriptive tags for less frequent items. Also OOXML tagging use shows the relation between certain parent and child elements actually making implementation easier rather than harder as this document suggests."

I do not suggest shorter tags requires more tags. I simply point out the the OOXML uses more tags than ODF. This is substantiated in both the examples I gave, and seems largely due to the fact OOXML does not support the "SPAN" functionality of XML. I have not managed to figure out what "parent" and "child" relationship you are referring to that MS-OOXML shows that ODF does not.

"Sixthly the document does mention the redundancy of data in the spreadsheet cell as an advantage because the formatted version of the data is easily retrieved. That is correct but also it requires any implementation to make certain that the data and it's formatted version are always synchronised. The ODF spec does not state how to deal with inconsistencies in the cells value and representation or whether a document should verify on opening that these are correct. An application not verifying this could potentially be at risk from hidden data in spreadsheet value item. Especially at risk when this that value for instance could contains (references to) script or embedded executable elements."

ODF and MS-OOXML are formats. It is up to the applications to ensure consistency in both of these. It has no place in the format specification itself. Implementing security checks while loading data in the application is plain common sense, and one which Microsoft has a very poor track record in. Also, I would have thought that the MS-OOXML method of storing spreadsheet data is at far more at risk to security problems than ODF due to the inconsistent manner which formatting can be included, the cross referencing of strings to an index in a separate part of the spec and the peculiar way dates are stored as numbers, and that number being inconsistent depending on a global setting.

"Seventhly the document suggests that OOXML cannot handle ODF Office settings whilst ODF could handle OOXML compatibility settings. However the author seems to be unaware that OOXML actually contains a feature that is called custom settings. By creating a namespace and XML with your implementations settings you can add custom application settings to OOXML as well and even make them validate using a schema. Particularly bad in this white paper is that it suggest its wrongly perceived lack of compatibility with ODF settings as a reason not to choose for OOXML. Very poor thinking as OOXML actually has built in extensibility even beyond it's custom setting that could also manage any compatibility issue with ODF."

This is news to me, I obviously missed it buried in the 6000 or so pages of documentation. Thanks for pointing this out. You however epitomized the philosophy of the difference between MS-OOXML and ODF. MS-OOXML handles Microsoft's own applications natively, while everyone else needs to use the "custom" settings their, while ODF places everyone on an even footing.

"Eigthly this document suggest an inconsistency with ISO 216 (paper sizes). OOXML actually support non ISO paper formats which is as it should be because those ISO formats are not covering all common office paper formats in use. ODF uses a flexible paper format allowing for even more variation of paperssize but also possibly requiring more implementation for validating whether a given paper size size is actually available and or how to handle near exact sizes. With ISO 216 not being the only papers in use in for Office documents inconsistensies seem normal."

If an ISO standard exists then it makes sense to use it. There is no justification for using "1", "9", and "30" instead of "Letter", "A4" and "C4". Your point of not covering all paper sizes is valid, but simply unilaterally making more numbers up is not a valid solution. Storing precise paper dimensions is valid in this case, though, I agree, not perfect. If more codes are required for paper sizes it makes sense to extend ISO 216 properly rather than take a "go-it-alone" attitude.

"Nigntly The documents objects to OOXML referencing windows meta files and clipboard objects as they are propriety windows related formats. However these are only mentioned as optional enumeration values for embedded items. So these values can even be used on a linux platform to easily identify that the document contains embedded objects it cannot handle without having to open the embedded file. If an ODF file contains these windows related items (which it also can) it might have to verify the embedded filetype purely on it's extention or even open the embedded file. On the other hand the dismisses the references to java in ODF's java applets because the java standard is supposedly well documented. However it fails to mention that any implementation of native embedding of java applets actually requires a java virtual machine which for instance Microsoft isn't allowed to make themselves after it's legal issues with Sun (who were in part responsible for the addition of java appplets to the spec) making full implementations dependant on 3rd party Java VM licensing."

The point I was making about the META files is that MS-OOXML was obviously not designed for interoperability (which is backed up by statements by ECMA and Microsoft – see Note 11 at the foot of the article itself). Why are Microsoft's Windows META files singled out? Why cannot they be treated as any other format? It implies that the only applications that can support MS-OOXML have to support Microsoft's proprietary META files too.

Your point about JAVA I in essence agree with you, though I am not sure about the "Microsoft is not allowed to make a Java Virtual Machine" bit. If I remember correctly all what the legal ruling stated was that Microsoft were not allowed to employ their "Embrace, Extend and Extinguish" strategy with the JVM and still call it "Java". It did not limit them as to what functionality their programmers could and could not include in programs.

To re-iterate the point of the article, Java is now (on the verge of being) open source completely license un-encumbered. Windows META files are not. I believe it is far more of a sin to specify the MS-Meta files than it is the Java ones.

In conclusion, your accusation that I may be "biased" for ODF and against MS-OOXML. This bias is based on the research I did into both formats. The examples I gave were not contrived, and epitomize the differences between them. ODF is not perfect. You pointed the lack of spreadsheet formula definitions. Although not totally missing from ODF they are grossly lacking. This, I believe, was an oversight by OASIS and one they are correcting with the "OpenFormula" specification. However, it is an understandable oversight. Neither specification specify "Macro" syntax, and nor should they as that is very much in the realm of the application itself, and the application's functionality should not be limited by the interoperable document specification.

You have not addressed my biggest criticism of MS-OOXML, and the crux of the reason why I think it should not be an ISO standard. Standards exist for interoperability. An office file format is no exception. It is good that that one person should send me a document created in onje application, and me to be able to open and manipulate it in OpenOffice, AbiWord, Koffice, Lotus Notes or azny compliant application I choose. ODF sets out to achieve this. After examining MS-OOXML it is obvious that that does not. It simply sets out to store in an XML format data that is currently stored in the Microsoft binary "doc", "xls" files. Recently Microsoft claimed that ODF was simply an XML "dump" of the4 OpenOffice internals. This is both wrong and hypocritical. Wrong in the sense that ODF is most certainly NOT that, but was created in conjunction with the community, and hypocritical is obvious that MS-OOXML IS an XML "dump" of MS-Office's legacy formats.

They also claim that MS-OOXML is neccessary for rendering MS-Office legacy documents precisely. Again, this is just silly as it is the application that does the rendering, not the format. The fact the Microsoft claim that only MS-Office can do this shows the closed nature of them, and their lack of respect for interoperability. Also, we are talking about writeable office formats here. The standard for precisely rendered portable document formats is, you guessed it, PDF.

Please forgive me. This comment has grown much longer than I anticipated. And thank you once again, hAL, for contributing to the discussion.

Eddy macnaghten