-
-
Cherry on Linux
John Cherry is a long-time Linux advocate dedicated to facilitating the adoption of Linux in various markets. John has held positions with the OSDL and Linux Foundation.
OOXML - vote “No, with comments”
August 29, 2007 |
The Linux Foundation, with the backing of the Desktop Architects community, is calling upon those ISO National Bodies that have not yet cast their votes to vote “No, with comments” on DIS29500 “Office Open XML” (OOXML). Those comments should reflect your best, neutral, technical judgment, based upon OOXML in its current form.
In the official Linux Foundation Statement on OOXML, the LF describes how OOXML is simply not ready to become an ISO standard from a process perspective, as well as a technical perspective. While we have been greatly disturbed by reports coming from many countries around the world that involve the deliberate delivery of misinformation, efforts to exclude or suppress negative comments, “stacking” the membership of voting committees, and last-minute upgrading of membership by nations that have previously sought to exercise such privileges, the fact remains that there simply has not been sufficient time to review over 6000 pages of documentation and to address the technical issues that have surfaced.
“The Case Against OOXML” is a reference which describes why DIS29500 “Office Open XML” (OOXML) does not meet the criteria defined by ISO and others for an International Standard. Although the OOXML specification provides a formidable framework in which Microsoft can represent its own documents, this ability does not translate into anything approaching equal access for others to obtain these same benefits. OOXML is a direct port of a single vendor’s binary document formats. It avoids the re-use of relevant existing international standards (e.g. several cryptographic algorithms, VML, etc.). It lists a large number of “Compatibility Settings” for legacy applications (e.g. footnoteLayoutLikeWW8, autoSpaceLikeWord95, useWord97LineBreakRules, etc.) which would be difficult for other developers to implement and hardly what you would find in an aspirational, consolidated best practices document. There are literally 100s of technical flaws that should be addressed before standardizing OOXML including continued use of binary code tied to platform specific features, propagating bugs in MS-Office into the standard, proprietary units, references to proprietary/confidential tags, unclear IP and patent rights, and much more.
OOXML is simply not ready to become an ISO standard.
The Linux Foundation supports the adoption of open standards as a catylist for innovation and to define common frameworks for new development. With ODF (Open Document Format) as an existing ISO document standard, we do not consider it beneficial to introduce an alternative document standard. Since ODF and OOXML are both designed as formats for editable documents, computer users would greatly benefit from multiple implementations of a single standard rather than suffer the confusion, conversions, and incompatibilities involved with multiple standards.
The Linux Foundation also supports the activities of the Desktop Architects and they have spoken out on why DIS29500 “Office Open XML” (OOXML) does not meet the criteria defined by ISO and others for an International Standard. In a Grocklaw posting, Google provided their position on OOXML as a Proposed ISO Standard. They suggest that if Microsoft wishes to create a document format that is better able to address the problems of the many editable legacy documents created in their older proprietary formats that they are welcome to help extend the existing ODF ISO standard in order to add the capabilities they require.
For reference, here are some links and references used in this blog and a few that were not:
- Standards News Portal
- Google’s Position on OOXML as a Proposed ISO Standard
- OOXML is defective by design
- Microsoft OOXML / ECMA376 - Get The Facts
- Standards BLOG
- The Case Against OOXML
Popularity: 100% [?]
Comments
13 Comments so far
[…] una declaración oficial publicada hoy, la fundación Linux está animando a los miembros de la ISO que voten en contra de la aprobación […]
[…] OOXML - Vote NO, with comments - The Linux Foundation. […]
[…] quieren saber mas: Linux Foundation Blog (vía Ars Technica) ¿Tiene futuro el formato ODF? Microsoft compra el voto sueco para Open Office […]
Microsoft can’t even seem to get their own software (Office 2007) to use OOXML consistently (or even elegantly):
http://www.slideshare.net/funnybroad/office-2007-compatibility-mode-confusion/
I Vote NO!!
Microsoft needs development of the Office format as it is vital to it’s core business, and the world is going to open standards, so Microsoft needs control over an open document standard. ODF have a broader group of development support (incl. Sun Microsystems) but this group not include to Microsoft, and OOXML is only supported by Microsoft.
[…] Y desde la Free Sotfware Foundation indican como se debe votar: “No, con comentarios“. […]
NO !!!! por favor …
[…] Foundation, publica un post rogando a los países que aun no han votado, a que le digan no a OOXML. La batalla por la […]
[…] de los organismos más prestigiosos relacionados con Linux publicó en su blog una entrada en la que ruegan a los países que aún quedan por votar a que voten “No” a la estandarización […]
“OOXML is a direct port of a single vendor’s binary document formats.”
It has to be that way, otherwise it would not be 100% compatible.
“It lists a large number of “Compatibility Settings” for legacy applications (e.g. footnoteLayoutLikeWW8, autoSpaceLikeWord95, useWord97LineBreakRules, etc.) which would be difficult for other developers to implement and hardly what you would find in an aspirational, consolidated best practices document.”
Look at the Compatiblity tab of Options in Word and it will be obvious why these are needed. Don’t forget, OOXML is supposed to be 100% compatible with the current Office binary formats.
Regarding 100% compatibility…
Ideally, it would be great to have 100% compatibility in an open document format with all the legacy proprietary applications (and their formats). However, as soon as an application developer hits something in the spec that requires him/her to be compatible with some feature in Office 95, they are dead in the water. At this point, ONLY Microsoft can implement that particular compatibility feature. This is hardly an aspirational, consolidated best practices documents.
So what can be done?
Without referencing proprietary interfaces, libraries, or binaries, the “capabilities” needed for compatibility could be specified. AND, the most efficient and widely acceptable mechanism for these extensions would be to enhance an exiting standard.
[…] Linux Foundation Blog (vía Ars […]