Ecma Responds
Saturday, 2007-March-03 at 22:56 1 comment
I’ve been reading the Microsoft-Ecma response document (PDF). I have a few responses so far.
Ecma found that comments submitted during this period were of various natures, including perceived contradictions, comments of a technical nature (which, as such, are best handled during the 5-month ballot and the subsequent Ballot Resolution Meeting), and general-purpose statements expressing concerns or support. (Page 5)
Page 6 notes 12 common issues among the responses, including in general terms most of the areas that were noted on GrokDoc and other places. The one most frequently raised is overlap in scope with ODF (ISO/IEC 26300:2006). Ecma responds that overlap is common & beneficial (Page 6).
They point out some examples that they believe are overlapping file formats.
- ODF, OOXML, PDF/A, and HTML: The first two serve identical purposes in the same domain. The other two serve different purposes, both from each other and from the first two formats. All I can say is "bad example."
- CGM and SVG: As far as I know, SVG has never been brought to ISO for standardization. The W3C says, "SVG is a language for describing two-dimensional graphics and graphical applications in XML." The two formats also serve different purposes and different markets. OOXML and ODF, on the other hand, serve the same purpose in the same market. Again, bad example.
- JPEG and PNG: Lossy compression versus lossless compression. The lossy format (JPEG) is designed primarily for efficient transfer of photographic images, where some of the detail is less likely to be noticed, while the lossless format (PNG) is designed to preserve all of the information in an image (and to be patent-free, given that PNG was a reaction to the sudden enforcement of patents on the compression method used in GIF format files).
Has anyone else noticed that they are recycling the same tired old argument that Microsoft’s blogging team has been using for months? Wouldn’t you think that they could come up with something new? I’m sure that they had their best minds working on this with Ecma International, trying to come up with a rebuttal and perhaps even a proposal for modification to smooth over some of the rough spots. My goodness, even Orcmid has written a better defense of their specification than this.
The OpenXML format standardization effort represent a very focused effort to write down in a standardized way the sum of information used in the already proven domain of existing binary formats while preparing for future enhancements and evolution
.
Yes, we have noticed that OOXML/ECMA 376 is an attempt to take most of the information in the binary formats anddirectly translated it into a sort-of-XML format. It makes no allowance for interoperability between office application suites or operating systems. Neither does it appear (to my untrained-in-XML eyes) to be designed to work with XML tools such as Cocoon and eXist.
Although OpenXML and ODF are both intended to describe office documents, each is designed to satisfy different user requirements. OpenXML has been designed to be capable of faithfully representing the majority of existing office documents in form and functionality. It is designed to replace existing binary document formats with easily accessible, open formats to meet a wide variety of user needs, formats which capture identical information yet are extensively documented, and can be implemented on a wide variety of operating systems and devices. Meeting this objective, while also satisfying many other goals, imposes stringent requirements on the overall design and architecture of the format. (Page 8 )
"OpenXML has been designed to be capable of faithfully representing the majority of existing office documents in form and functionality." A format that does not define how to save macros and scripting cannot "faithfully represent … functionality." It just cannot, because it cannot do all that the original binary formats could do. That’s the reason that there is a second format (based on OOXML) that is used in Microsoft Office 2007, but which includes compiled binary blobs for the macros. And while OOXML may indeed have compatibility flags to represent all of the legacy behaviors (the "form" in the above quote) encapsulated in their older versions of their office software, even their own office applications (as of 2003) cannot read or write some of the older formats. Thus, I consider the value of this "faithful representation" to be equivalent to that of used toilet tissue.
They then give three use cases meant to illustrate the importance of including all of the compatibility flags to enable the retention of information that might be captured in the way a certain software version laid out footnotes on a page. However, if that is the case, why are there not compatibility flags for Electric Pencil, WordStar, WordExpress, or their old home-user suite Works? At my community college, we wrote our student body constitution using WordStar. Of course, I am certain it has long-since been re-entered in Microsoft Word, but that is just an example of an important document that could be lost.
The problem with this argument is that they have not given even one example of a legacy behavior that cannot be stored in OpenDocument Format. If one has knowledge of the way that a certain version of a particular application handled something, it is not necessary to say "doItTheWayWeUsedToDoIt." Instead, we say "Center header, with 1.5x spacing between the heading and the following text." Poof! Like magic, we just "faithfully represented" legacy behavior without having to include the cruft of past implementations. Instead, OOXML’s approach is to have an unexplained compatibility flag and to recommend not using it. This promotes interoperability and compatibility in exactly what way?
If the use case represented by national libraries and archives is not served by the use of unspecified compatibility flags, maybe this can be supported by the use of another use case: mission-critical business systems. The idea is that an enterprise cannot risk changed functionality when file formats change. This is actually a good argument for keeping the existing binary formats, except that Microsoft changed its binary formats like a normal individual changes his underwear. Thus, those who have such processes are used to suddenly finding that they need to update their processes to work with the newer software and file formats.
In some cases, enterprises use Microsoft’s own software (through its APIs) to escape such issues with file formats. If your executive dashboard software uses Word and Excel, through Visual Basic for Applications, to do its data input and much of its processing, then as long as VBA and the APIs are stable, your dashboard should work. This gives an enterprise some protection from software upgrades. However, we have to wonder what happens when VBA gets deprecated in favor of VB.Net and C#, or the more frequent case, that an update patch from Microsoft suddenly breaks the functionality your application depends upon.
Shortly before I received my Master’s Degree, an update to IE broke our online campus’s e-mail system. I discovered that I could still access the system if I used Mozilla, but the only official browser support was IE. This made it more difficult to exchange information between team project members–we wound up using our personal e-mail addresses. A few weeks after the graduation, their workaround was in place, but for my class, it was too late.
I recall how a patch to remove functionality due to the Eolas suit caused a number of users to grow frustrated. It now took an extra click to accomplish tasks that involved a browser-loaded plugin. Other changes took place because of menu-hiding in Microsoft’s 2003 version of their office applications suite, where spreadsheet data for a weekly report was hand-massagedand the users were not able to find the functionality they needed.
The point is, these kinds of disruptions happen as a normal course of business. It is part of the cycle of upgrades and patches. If your enterprise has not had a business-critical process disrupted by a software upgrade or patch, then software isn’t a part of your business-critical processes. These situations are the reason why companies purchase support contracts.
The truth is, unless your application hooks into a built-in API of Microsoft’s office applications suite, you will have to rewrite portions of your application to work with the newer file formats. Just as one cannot read this year’s files with the software of a decade ago, neither can one use OOXML file formats in an application built for the older binary formats. And this is why any cries of "compatibility" are a smokescreen.
OpenXML meets user requirements that are distinct from those of ODF and of significant material importance to corporations and government organizations worldwide. (Page 10)
This has not been shown. Making this assertion assumes facts not in evidence. Show us some examples of data and formatting that cannot be faithfully represented by ODF, but which can be faithfully represented by OOXML without resorting to compatiblity flags.
Powered by Bleezer
Entry filed under: ODF, Open Standards.
Opportunity Knocks 
1.
Stephane Rodriguez | Sunday, 2007-March-04 at 02:46
Yep, the ECMA responses are nothing more than a rehash of Brian Jones anti-ODF posts. Too bad they don’t also include what this guy and his team did in Massachussets since 2005.
You said “That’s the reason that there is a second format (based on OOXML) that is used in Microsoft Office 2007, but which includes compiled binary blobs for the macros.”
In fact, that’s a little more complicated than that. Among binary parts are VBA macros and OLE objects. It so happens that I have documented some of this stuff elsewhere. The fact that Microsoft has a different ‘m’ suffix for those documents’ names is just one of their typical false sense of security answers to information workers. It’s not for interoperability reasons. And it’s false security because once you create such ‘m’ files, you can run macros that will sabotage one’s computer.
No, the real problem to me is that Microsoft wants to position OOXML as just a base format that their implementation is based on. And that the implementation adds all the other parts that are supposed to be non-XML, which includes VBA macros, OLE, DRM, password-protection, …
Doing so they create FUD because by that regime, none of business documents out there that include VBA macros are strict OOXML documents. They are extensions.
In other words, a third-party client application that instantiates OOXML based on the public specs cannot be used to process business documents.
And we are back to square one, with a single vendor holding the keys to those business documents, the ability to accurately r/w, calculate, print, render such files. On the premise that their products is always superior, and that any competition will always be by this definition inferior. In fact, Microsoft’s own covenant not to sue does not apply to what’s non-OOXML, meaning that a competitor that tries to do what Office 2007 does (like supporting VBA macros) is in direct violation. If that’s not anti-competitive, I don’t know what it is.
Besides this, I am under the feeling (I am getting in touch with AFNOR in France to see what’s going on) that much of the national bodies of P-countries have been “retrained” by Microsoft people lately. Let’s not forget that a number of national bodies have Microsoft employees as their members. In France, there are no less than 3 Microsoft employees. I don’t know their names, perhaps even the famous Jean Paoli (Brian Jones’s boss) is one of them…
I thing this battle is going to be lost, because there is way too much stuff going on behind the scene, and Microsoft has all the people in the right place to influence both the discussion (they are redefining terms at every turn) and the votes (by having Microsoft employees all over the place). I mean, getting the ECMA to approve a paper where they say that ODF and OOXML have different purposes is speaking volume of the shit stream they are sending…
I think the battle is going to be lost by Microsoft in the long run however because their own applications are both too fat and too integrated (with their servers) to be able to compete with Office 2.0
There are accelerating signs of major disruptions occuring in the Office document space. This year alone is going to be interesting.
To be accurate, what’s in full swing right now is Office 2.0 __applications__. It’s not about just Office file formats anymore.
I think that Microsoft will try to spin this threat (at least in the short term) by saying that those alternatives don’t support all of the huge functionalities of MS Office own apps. By saying so however, they are indeed telling why they are not relevant anymore. No one needs so many features just to write word documents, calculate complete spreadsheets or create presentations.
Therefore it is the beginning of the end for them anyway.