I sometimes hear it said that formats like OOXML, or ODF for that matter, are simply XML serializations of a particular application’s native data representation. This is said, seemingly, in an attempt to justify quirky or outright infelicitous representations. “We had no choice. Office 95 represents line widths in units of 1/5th of a barleycorn, so OOXML must as well”. This technological determinism indicates poor engineering judgment, laziness, or both.
An easy counter-example is HTML. Does HTML reflect the internals of NCSA Mosaic? Does it represent the internals of Netscape Navigator? Firefox? Opera? Safari? Are any faults in HTML properly justified by what a single browser does internally? Applications should follow standards, not the other way around.
The question we should be asking is not whether a standard is similar to an application’s internal representation. That in itself is not necessarily a fault. We need to go a step further, and ask if this encoding represents reasonable engineering decisions, not just for that one application, but for general use? Or in ISO terms, does it represent the “consolidated results of science, technology and experience”? If it is a good, reasonable engineering choice with general applicability, and the original application already found that solution, then this is a good thing. We should be encouraging standards to encode the best practices of industry.
Take colors for example. There are only so many ways one can represent colors in markup. You can have an RGB value encoded as triplets where red= (255,0,0). Or you can have a hexadecimal integer encoded as RRGGBB, where red=FF0000. You can do it W3C style, like CSS or XSL-FO with a hash mark in front, like #FF0000″. There are variations on this, adding an alpha channel, using a different color model, etc. These are all reasonable engineering choices, and no one would fault a standard for choosing any one of them, even if the choice happens to match what a particular application does. They are all reasonable choices.
The final arbiter is engineering judgment. Making a capricious choice, merely because a particular application made that same choice, in spite of contrary engineering judgment, this would be a bad thing.
With this in mind, let’s take a look at how OOXML and ODF represent a staple of document formats: text color and alignment. I created six documents: word processor, spreadsheet and presentation graphics, in OOXML and ODF formats. In each case I entered one simple string “This is red text”. In each case I made the word “red” red, and right aligned the entire string. The following table shows the representation of this formatting instruction in OOXML and ODF, for each of the three application types:
| Format | Text Color | Text Alignment |
|---|---|---|
| OOXML Text | <w:color w:val=”FF0000″/> | <w:jc w:val=”right”/> |
| OOXML Sheet | <color rgb=”FFFF0000″/> | <alignment horizontal=”right”/> |
| OOXML Presentation | <a:srgbClr val=”FF0000″/> | <a:pPr algn=”r”/> |
| ODF Text | <style:text-properties fo:color=”#FF0000″/> | <style:paragraph-properties fo:text-align=”end” /> |
| ODF Sheet | <style:text-properties fo:color=”#FF0000″/> | <style:paragraph-properties fo:text-align=”end”/> |
| ODF Presentation | <style:text-properties fo:color=”#FF0000″/> | <style:paragraph-properties fo:text-align=”end”/> |
The results speak for themselves.
What is the engineering justification for this horror? I have no doubt that this accurately reflects the internals of Microsoft Office, and shows how these three applications have been developed by three different, isolated teams. But is this a suitable foundation for an International Standard? Does this represent a reasonable engineering judgment? ODF uses the W3C’s XSL-FO vocabulary for text styling, and uses this vocabulary consistently. OOXML’s representation, on the other hand, appear incompatible with any deliberate design methodology.
I fear that before we can tackle harmonization of ODF and OOXML, we will first need to harmonize OOXML with itself!
As another data point to underscore your thesis, let me point out a passage from Antonis Christofides’ BRM account: The changes that actually passed in Friday morning did add the possibility to store dates in ISO 8601 format, but they also keep the old ways, and in addition they add all ways proposed in the Disposition of Comments. Therefore we now have five different ways of representing the same thing.
The scary thing is that new flaws keep being uncovered in OOXML, because its sheer size masks even “obvious” internal inconsistencies like the ones you pointed out here.
It will be truly sad if ISO lowers its standards so far that it will accept this monstrosity. It is equally sad that some of us have been convinced that drastically lowering ISO’s standards, destroying its reputation, and crippling future efforts to get the world behind a single common data format for office applications are an acceptable price to pay for getting a “seat at the table” with Microsoft.
Aside: you have a couple of typos in the first two paragraphs: s/had not/had no/ and s/Mosiac/Mosaic/.
w? a? srgbClr? pPr ? jc? OOXML : Because obfuscation must be an open standard.
With the docs being that cryptic, it’s a good thing we have computers to decipher them for us.
you gotta be pleased you didn’t have to do that table in O2007XML!
He he he
@Hans, computers don’t program themselves. This is a labor intensive industry, and a well-designed format is easier/less-expensive to program than a poorly-designed one. Otherwise what is the argument for moving from the binary formats to XML? Computers could decipher the old formats also.
So imagine you are writing a simple program to find all red text in a set of documents and change it to blue. Maybe this program is to help with readers who are colorblind (something like 10% of all men). What is easier, writing this for a format that has a uniform principle for encoding text colors? Or one that will take you days to find all the different ways in which text colors are encoded?
The point is that any format will have its essential complexity, the complexity that matches the real-world task, and which you cannot simplify further. But a poor design will also layer on “accidental” complexity, complexity entirely due to poor modeling, inconsistency, lack of naming principles, poor factoring of concerns, etc. This complexity benefits no one. It doesn’t make the format more expressive or more capable. It simply makes it harder to use.
I find Microsoft’s insistence that the format reflect the internal representation… interesting. This is due to the fact that Microsoft has a fairly well respected usability lab, and one of the key tenets in UI design is that UI should represent the task, not the application architecture.
Yet with all this knowledge about proper UI design — and in a sense, a data format can be considered a form of UI — they’ve thrown this out the window.
Rob,
Thank you for providing an object lesson in why so many of us IT people have serious concerns about OOXML. All of the emotional arguments can easily be set aside when concrete, irrefutable evidence is presented in the light of day. What you’ve shown is empirical evidence that OOXML is not truly ready for the big time. I have no objection to it being an ISO standard once it is cleaned up and, as you put it, good engineering decisions prevail over the head-scratchers littered in those 6000 pages.
Please keep up the good work.
-MC
With the docs being that cryptic, it’s a good thing we have Microsoft Office to decipher them for us.
Thank you Microsoft, you have convinced me ! i will spend this u$s 300 and buy the wonderful decipher-machine Office 2007.
Microsoft will try and paint ODF as a serialization of ODF’s internal representation because that’s what they’ve done with OOXML.
It was designed according to the needs of the file format, not the needs of any one application. Open Office had to be modified to fit ODF, once it was finalized.
OOXML, on the other hand, is directly and explicitly based on MS Office, and the OASIS base terms of reference actually says that it’s not allowed to contain anything that’s not already in MS Office.
Tying yourself so tightly to a single vendor’s implementation is a bad thing to do for something that wants to be declared a ‘standard’ — even if that implementation is well engineered.
In the case of OOXML’s tie to MS-Office, you don’t even seem to have ‘well engineered’ as an excuse.
Of course an interesting fact about HTML is that the available form elements are the same as those available to Tim Berners-Lee on the NeXTSTEP system that he wrote the first graphical browser.
“Are any faults in HTML justified by what a single browser does internally?”
Minor note: the HTML 5 effort is very concerned with what the development versions of Firefox, Opera and Safari actually do now. They want to avoid the disaster of CSS, where a pie-in-the-sky spec was written with no regard for interoperability.
But then, they’re trying to make sure HTML 5 is clearly implementable and useful and hits the ground running, with multiple working implementations available :-) Which is turning out to be a pretty good way to update a standard they want people to actually use.
ANSI C was also developed with an eye to what existing implementations of the predecessor product did.
However, in the case of OOXML, there is no effective predecessor product – converting from the binary representations of the past to XML is enough of a leap that backward compatibility (in the sense that files output by the new program will be understandable by the old) is completely impossible. The best you can do is have the new product convert old files to the new format, and make an update to the old products to enable them to convert from the new (and possibly even use it natively.)
Since effortless backward compatibility is impossible, any excuses they make citing compatibility with older formats is completely invalid. It would be like the US demanding that the UK defend its colonies in the Americas, after our revolution. It just doesn’t work.
Also note that both HTML 5 and ANSI C were paying attention to what *multiple* implementations did, not just one.
Absolutely BRILLIANT post!
Inconsistency… all over the place.
Does any of it explain the non-backward compatibility of Excel colors described in detail here?:
http://dearmicrosoftofficeteam.blogspot.com/2008/03/dear-microsoft-office-2007-team-please_03.html
I love the other distinguishing feature of your brief example – to which you did not alude:
‘right’ (OOXML) versus ‘end’ (ODF).
Obvious difference in either heritage, development, or both.
“end” is from the W3C’s XSL-FO text-align feature. So rather than say “left” or “right” align, we say “start” or “end”. This makes the markup more robust for different writing systems, whether RTL or LTR.
It is good to see that OOXML is firm in the knowledge that there is only one true text orientation. If left-to-right text was good enough for Jesus, it is good enough for ISO. In contrast, ODF’s politically correct waffling (“end”) is truly pathetic.
@cayhorstmann
I always thought Jesus wrote right-to-left. His native language was Aramaic which is written right-to-left. He was a Jew. So he probably wrote Hebrew, too.
However, I might have missed the irony in your post.
Finally Rob. This is a much better mode of attack than the FUD and politics most people are using against OOXML. I’ve always said it’s better to do a side by side comparison of ODF vs OOXML rather than pontificate about how evil MS is.
After all, thats what we developers are mostly interested in. To hell with politics.
“If left-to-right text was good enough for Jesus, it is good enough for ISO.”
I’m sure you’re being ironic, but for the sake of less-historically accurate minds reading here…
Jesus read Hebrew, which is a right-to-left language.
So this is funny because left-to-right WASN’T good enough for Jesus.
Yes, I know I’ve destroyed the subtlety in the original comment. But subtlety and engineering precision are rare bedmates.
It is good to see that OOXML is firm in the knowledge that there is only one true text orientation. If left-to-right text was good enough for Jesus, it is good enough for ISO. In contrast, ODF’s politically correct waffling (“end”) is truly pathetic.
You may have written that as tongue in cheek, but if literate, Jesus was probably familiar with Latin (written Left to Right), Greek (written Left to Right, but occasionally boustrophedonic [forwards and backwards]), Hebrew (written Right to Left), and Aramaic (written Right to Left). It is indeed possible that Jesus spoke Aramaic primarily, with some Hebrew and Greek; and would certainly have come across Latin inscriptions.
Remember, Cay is from Northern Germany. So even his humor sounds serious.
Hmm, drifted off-topic a bit here! I thought Cay’s comment was very funny just as it was :-)
Rob, we’re coming down to the wire here and it seems to me that since Microsoft is represented in most NBs (or at least their advisory groups), then Microsoft will probably know the outcome of the final vote before anyone else (even ISO). Do you know if individual NBs are going to make their decisions public before the 29th?
As an example, the Microsofties are very open about the US NB’s decision (which is not final yet, is it?)…
I seem to recall that NB’s that don’t want to change their September vote don’t even need to contact ISO, so perhaps ISO won’t know the outcome until the deadline actually passes – unless of course the received votes are decisively on one or other side of the thresholds.
I’m sure that ISO themselves won’t make any announcement until the 30th, but maybe “inside sources” will leak clues before then?
Rob, Microsoft has a tell They are at their loudest where they are the weakest. The last “open letter” we got from Microsoft came right before the OOXML defeat last September. If you recall, at that point they were also trumpeting the US vote. As then, I have a fuller picture of where the votes are going, and it isn’t so rosy for Microsoft. And as then, I will respect NB’s desires to go public only if or when they desire, and I won’t be breaking news of their voting positions here. I wish I could, since there would be some great news to tell. But I can’t.
As for timing, some NB’s have already decided, while others have continuing discussions through the month and will come to final positions only at the end of the months. Considering how close the vote was in September, and the complexity of the approval criteria, I don’t think anyone will have a good sense of the outcome until we see the official announcement.
Not sure is this a sign of tell or not but at least yet more PR activity:
http://www.microsoft.com/interop/letters/ChrisCapOpenLetter.mspx
For the OOXML presentation text alignment – is the “algn” a typo, or is it even worse than I thought?
The OOXML specification says “algn” and PowerPoint 2007 writes out “algn”, so I assume that is intentional.
Remember, they save a byte by doing this.
Cay’s Comment was an allusion to people who were protesting updating of the King James version of the Bible. The joke being that someone said: “If the King’s English was good enough for Jesus, it should be good enough for us.” This is funny because Jesus most certainly would *not* have spoken, read, or written in “The King’s English.” And was used to prove what a narrow world view many people have.
@Meneteqel:
I think Cay was correct. Everyone knows that Jesus was a citizen of the US of A —so help Him God— and when I say everyone, I mean many of the other citizens of US of A.
Check also the already mentioned “If the King’s English was good enough for Jesus” quote.
@cay: Please do drop in a joke in your comments, us guys think you were serious! I seriously think ODF has the upper hand in terms of coding, reusability, and style.
A couple of comments.
1) CSS 2, being largely a specification created without an implementation does not to this day, have a 100% implementaiton.
2) ISO C++/89, again, a spec written largely without implementation is also unimplemented in it’s entirety to this day.
It would seem that specifications derived from implemented specifications have a much better chance of having other full implementations than unimplemented ones.
Coincidentally, that’s also why ODF has been so well implemented. Without OpenOffice’s full and complete implementation, it would be unlikely that anyone else would be able to either.
Anonymous:
HTML forms were not yet present in the first version of HTML (implemented by timbl’s WorldWideWeb browser).
Forms were introduced in HTML 2.0, which in its turn does not yet contain all form elements that are present in HTML 4.01 (such as BUTTON, INPUT TYPE=”file” and OPTGROUP).