Here’s a key snippet from yesterday’s interoperability announcement:
We’re also designing new APIs for Microsoft Word, Excel and PowerPoint applications that will enable developers to plug in additional document formats and allow users to select those formats as their default for saving documents.
Translation: if OOXML fails to get ISO standardisation, and/or if the rival ODF catches on or is mandated by institutions, then Microsoft wants you to keep using Office.
Product Manager Gray Knowlton has a little more detail here.
I’m not clear how extensive these changes are. Presumably it amounts to more than just tweaking the open and save dialogs to enable different defaults. Office applications already let you select from a range of different formats.
A few further comments. First, I’d like to see OOXML standardized. Aggressive IBM-sponsored lobbying has not convinced me this is a bad idea. And yes, I’ve pored over the spec and even done a little development with OOXML. Standardization tends to improve documentation and helps to protect developers from arbitrary changes.
It is interesting to see someone like Patrick Durusau, Chair of incits, coming out in favour of OOXML standardization [PDF]:
I have seen some attacks on OpenXML saying it is not an “open” standard. I am quite puzzled by those attacks and think that OpenXML makes the case for open development of standards.
Understand that as the Project Editor for ISO/IEC 26300 and the OpenDocument Format TC editor in OASIS, I carry no brief for OpenXML. However, a well defined and publicly controlled OpenXML would be a great benefit for future work on the OpenDocument Format standard so I have no reason to wish it ill.
That does not mean Microsoft has done everything right. Microsoft’s Jean Paoli, now an evangelist for standardization, told me three years ago that OOXML was not suitable to be managed by a standards body. Why the change of heart? Simply, the threat of losing market share to a rival that was standardized. Microsoft had years of unchallenged Office supremacy in which it could have opened up its formats; but did nothing until its profits were threatened.
This should tell us something about the benefits of competition.
Despite Microsoft’s efforts, gains in ODF market acceptance will damage Microsoft Office. It will take more than a few API changes to make Microsoft Office as good an ODF editor as Open Office, which has a family relationship with the rival formats.
Standardization is only a small piece of this puzzle. On the Microsoft side, Office is a decent product with massive market dominance. On the ODF side, Open Office is also a decent product and is free and open source. The fight will still be on, no matter how the standards thing plays out.
“It is interesting to see someone like Patrick Durusau, Chair of incits, coming out in favour of OOXML standardization [PDF]”
Patrick is anticipating the work on ODF 1.2 and how the ODF TC will have to ask Microsoft’s accumulated army at ISO to be gentle so that ISO can do their normal work. If you don’t know what this means, long story short, Microsoft stuffed a number of corrupt countries who have enrolled as O-members just days short of the September ballot, and it has completely stalled the work at ISO. That hurts everything at ISO now, not only OOXML.
As for Patrick’s thoughts about OOXML, they are perfectly in line with what he said when he was part of the US INCITS V1 reviewing group on OOXML last summer. In fact, he repeated it on one of the ODF discussion mailing lists just days ago :
http://www.oasis-open.org/archives/office/200801/msg00016.html
I think that characterising the objections to OOXML as “Aggressive IBM-sponsored lobbying” is disingenuous.
There are plenty of perfectly valid objections ot the spec centring around the myriad ‘proprietary’ sections embedded in the format – making it impossible for anyone other than Microsoft to fully support a supposedly ‘open’ format.
Michael,
As I understand it, many or most of these are either
a) deprecated
and/or
b) dealt with in the revisions
If you look at the design goal for OOXML, it is intended to encode legacy Office documents and I guess there is a real difficulty in doing so in a 100% clean manner.
I am sure the spec is not flawless but that is no reason to abandon standardization completely.
Undoubtedly the objection process has brought out valid and useful comments that will improve the spec. However often they are used in a destructive rather than a constructive manner.
Which bit of “Aggressive” or “IBM-sponsored” or “lobbying” do you disagree with?
Tim
“If you look at the design goal for OOXML, it is intended to encode legacy Office documents and I guess there is a real difficulty in doing so in a 100% clean manner.”
Even if that were true, it cannot be verified (see Patrick’s statement), so it does not deserve to become a standard. Obviously, a grammar whose semantics is subject to all kinds of interpretation will lead to as many different interpretations as possible, not one.
Microsoft can “fix” that by releasing the source code of the Office compatibility pack, since it does just that, migrate formats back and forth. Will they do it ?
And of course, that was not Microsoft goal.
I can tell you exactly what Microsoft changed between binary formats and the new formats, if you are interested. Scoop : it isn’t 100% BS. But the backwards compatibility excuse is a scam.
In fact, when this excuse did not convince national bodies last year, they started talking about performance (why they did what they did for performance reasons). Again, just a scam.
I can give a few details about that if you are interested.
The only logical step is go back to the drawing board, adopt ISO standards to come up with an Office document model that both brings the existing files into the future, and yet, fixes the gazillions of bad things that were done in all those years. Trivial examples : dates (OLE, incompatible with just about everything else), vector graphics (DrawingML is completely new so Microsoft could have extended SVG instead of going their own way), …
Not sure about this. It is pretty arcane if you delve into it. Things that look the same may be encoded differently if they arrived via an older version of .doc or .xls.
Performance is definitely a factor as well. An important one in my view.
Tim
“It is pretty arcane if you delve into it. Things that look the same may be encoded differently if they arrived via an older version of .doc or .xls.”
It’s the other way around. The Office compatibility pack is a reference implementation. It represents the opportunity to avoid making false interpretations (i.e. Patrick’s statement again).
I’ve given a few thoughts about that, and I think it’s the best compromise for all parties. On the one hand, we get a reference implementation, so Microsoft does not need anymore to fool us with their “open source translation projects”. On the other hand, the Office compatibility pack is pure document centric, so Microsoft keeps their IP in all what’s application level.
“Performance is definitely a factor as well. An important one in my view.”
I haven’t said that Performance does not matter (note that the working set of Excel 2007.exe is ten times the working set of Excel 2003.exe, go figure…). I’m saying it’s used a scam in a all or nothing rhetoric. With the performance excuse, Microsoft tries to justify why they are not storing default XML attribute values in the file, and instead of that those hardcods all tihs stuff in Office 2007 (and the Office compatibility pack). With a logic like this, we are all back to reverse engineering again. As Joel Spolsky pointed out, an implementor will spend ten if not more years into just doing that (I’m sure you’ve noticed what I do for a living). So what is the standard for if it does not end this carrot game?
Don’t forget, Office 2009 beta 1 is just around the corner (I sense Microsoft is keeping low profile on the subject, given the tension in Geneva next week). That’s even more changes to worry about…
Do you mean the add-on that gives Office 2003 OOXML compatibility?
As for default attribute values, are you saying that some of these are not in the spec? If they are not in the spec, isn’t that a problem with the spec (and an easy one to fix), rather than with depending on default values?
Tim
“Do you mean the add-on that gives Office 2003 OOXML compatibility?”
Yes. http://office.microsoft.com/en-us/products/HA101686761033.aspx
“As for default attribute values, are you saying that some of these are not in the spec? If they are not in the spec, isn’t that a problem with the spec (and an easy one to fix), rather than with depending on default values?”
The answer is no, from a practical standpoint, because it’s too hard to put in the spec, that would not only make it obscure but also make it much larger than it is. Everyone is complaining already about how large it is, that’s ridiculous. These are situations where this element has this default value when the parent is this and not that (for instance a 2D chart of type bar as opposed as of type line), not stuff that is described in the XSD schemas. These are gazillions of small IFs/ELSE. In fact, Joel Spolsky said accurately it’s the actual source code we are talking about.
Hence my call to release the source code of the compatibility pack so that a reference implementation disambiguates the interpretations, lack of specifications and all that.
That may seem odd for a standard proposal that is supposed to hold on a piece of paper, rather than a source code file. But tell me what isn’t odd in having Microsoft proprietary stuff getting standardized without freeing what’s proprietary?
You know, it’s not like products like OpenOffice can’t handle most of Office documents today. All this work is done. Microsoft wants us to do this all over again with this new XML thing (in fact, angle brackets surrounding binary streams).
‘Which bit of “Aggressive” or “IBM-sponsored” or “lobbying” do you disagree with?’
That the *many* people who have problems with this proposed ‘open’ standard have anything at all to do with IBM…
Michael
Michael,
Well, I didn’t say it was only IBM that objected. On the contrary, it is a bandwagon joined by many who are just anti-Microsoft, and by some who have thoughtful and valid objections. But there’s no doubt that IBM has done everything it can to foster those objections, and to my mind in an unconstructive manner.
Tim
@Tim
My last comment was eaten by your blog host.
“But there’s no doubt that IBM has done everything it can to foster those objections, and to my mind in an unconstructive manner.”
Two-pronge answer. IBM is one of that has most impact in standard committees. In a way, they are speaking on behalf of many of us. As for IBM being unconstructive, I’ll simply note that Rob Weir has posted thousands of comments which I think are constructive to better define ECMA 376, make it more consistent for others. And that is a true embarassment for Microsoft to have others do the dirty laundry.
There are certainly direct and sponsored IBM attacks as well, but let’s not forget the big picture : IBM has mostly helped Microsoft fix the draft.
It’s opening up what used to be secret. That helps developers.
Some truth in this, but nevertheless it is XML and you can use it with standard XML tools – big advantage. If you want to use Open Office then fine, go ahead. But Microsoft Office is popular and there is real business value in migrating Microsoft Office to XML formats that play nicely server side and in having those formats well documented and standardised so that we can all know how they work.
Tim
“But Microsoft Office is popular and there is real business value in migrating Microsoft Office to XML formats that play nicely server side and in having those formats well documented and standardised so that we can all know how they work.”
100% Microsoft marketing speak. Let’s agree to disagree on the subject.
Nope. Memories of trying to do this with RTF.
Sure.
Tim
“But Microsoft Office is popular and there is real business value in migrating Microsoft Office to XML formats that play nicely server side and in having those formats well documented and standardised so that we can all know how they work.”
“100% Microsoft marketing speak.”
Knowledge engineering, text mining, indexing of corporate documents, integrating documents into intranet portals, extending the reach of the Semantic web to corporate information held in fileshares or SharePoint servers…all this coming from a Microsoft non-employee.