Wouter

Regarding the different capabilities of different parts of a format, I think that it would be useful for a standard to specify that e.g. spreadsheets shouldn't have to support certain layout settings. I do think that having entirely separate formats for the layout (DrawingML versus VML/WordprocessingML layout) is just ludicrous. This would have been much better done using a single base structure and per-situation limitations on what is allowable and what isn't. At least that gives implementers the choice of using the same framework to process both types of layout. The way it's done now, you have to do everything twice, for no good reason. For example, the main difference between WordprocessingML text and DrawingML text (apart from being able to use styles) seems to be that DrawingML puts everything in attributes and WordprocessingML puts everything in nested tags but the tags in WordprocessingML have the same names and content as the DrawingML attributes, so it's really only a needless structural difference! These kinds of choices reek of design-by-multiple-committees-that-aren't-talking. :-(

I see now that in one of my earlier comments, the text <A1> has gone missing from the formula =<A1>+3.

It does indeed look as if it is an implementation flaw and not something in OOXML as such (please don't make the mistake of Stepháne's and conclude something - wrong - about the format based on the implementation of it. However - it sheds some light on the issue that OpenOffice throws away information that it doesn't understand. If I were to speculate on this it could be that OOo loads the content of the document into the internal object model of the application suite - and if it has not implemented kerning in spreadsheets, there is no place to "park" this information ... and hence it is lost. I seem to remember something in the OOXML-spec that a conforming application should simply ignore valid content that it doesn't understand. I think this would go a long way towards avoiding the mess you describe here.

I agree that it's nasty that OOo Calc apparently converts the document into an internal format which cannot represent markup that is part of the standard. What I do like about it, is that ODF has only a single way of representing text, and text styles. I am currently working on an OpenXML converter for my company's application, and the fact that DrawingML text markup is so different from VML text markup (which does use the same format and styles as WordprocessingML) makes it loads of extra work to support. In contrast, in ODF, everything is so single-point-of-definition that even spreadsheets and wordprocessing tables are completely unified. The fact that OOo Calc doesn't implement the spreadsheet formatting correctly is a bug in OOo Calc, not in ODF. The interesting part is that this means that the spreadsheet functionality also transfers to tables! For instance, try the following: in OOo Writer, insert a 2x2 table. Enter "3" in the top-left cell. In another cell, enter the text "=+3". Note that the cell then shows "6"! :-)

I have always suspected Stephane Rodriguez, he has a business in doing Excel extracting tools and was an early critic of OOXML in that domain. His arguments have always been very flaky, and he has been publicly exposed in a number of threads around the web (like when he did not understand the spreadsheet). He seems to have expanded from the area of his expertise to other areas, and I suspect he is being paid to do this. Stephane's own business was threatened by the availability of OOXML as it depended entirely on being able to decode obscure features in the old binary file formats. The further announcements from Microsoft for translators from binary to OOXML might have threatened his business more. It is in this environment of fear that Mr Rodriguez was probably approached by an interested party and funded him to write anti-OOXML pieces. The pieces are not very savvy and as this article proves (and many other articles that have debunked him) his knowledge is not very deep. Why would someone jeopardize his own business and his reputation is beyond me, and I can only come to the conclusion that he is being paid to do so some consulting fee.

A number of things you are saying are misleading. 1) The style model in ODF is common to all ODF file formats. This is a huge gain for ODF implementers since they can grab a style read/write library and add it to their project. 2) .docx styles uses its own style model, different than the one in .xlsx and the one in .pptx. But the style model in .docx you have exposed is just a fraction of style in .docx since you haven't even mentioned the styles coming from DrawingML and the styles coming from VML. So you have 3 style models in .docx alone. Now that's what I something cost effective for implementers and those willing to interoperate across file formats! 3) In fact the ODF style model is a hierarchical one, that's what you seem to have missed when you said that text:span were embedded in one another. Have you even figured out this is HTML works for instance? Have you heard of inheritance versus override? Now, tell me where is the inheritance in the .docx style model where styles are in the w:rPr sequence, either one after another, not one inside another? 4) Your comment about the verbosity of the markup is nonsense. Everyone knows ODF is more verbose, I don't think anyone ever tried to claim otherwise. We already know that Microsoft uses the smallest element names as possible to improve the so-called performance of parsing, even though that is left for one as an exercise whether this really matters given that 1) our computers are not 486 computers these days 2) the whole thing is ZIPPED and ZIP is dictionary based so the zipped size should be the same order of magnitude, which is what matters if you are talking of actual file sizes. Anyway, as usual, you have posted an extremely biased view of ODF. I did not expect less from you.

XML is een afgeleide van SGML en SGML is een gestandaardizeerde versie van IBM's GML. Ik heb hier een IBM Bookmaster User's Guide en daar heet de meest gebruikte tag, :p. voor "paragraph".

Guess it's probably not in IBM's best interest to see things move towards open standards. Big shame... Do you think the ISO people will nog be swayed towards IBM's business goals?

Nice work! Looking forward to support for some repeating table controls