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