Marino Marcich, executive director of the OpenDocument Format Alliance, retorted via e-mail that many users are taking "a buyer-beware attitude" toward Open XML because that format "is not interoperable and will tie them to the upgrade path of a single vendor."
For example, he noted that Becta, the U.K. government's educational technology agency, last week released a report of its own advising, among other things, that to ensure the widest compatibility of files between different applications, Office 2007 users shouldn't save documents in Open XML. Instead, Becta recommended the continued use of Microsoft's older and proprietary .doc, .xls and .ppt formats.
2More
Open XML trumps ODF in document format fight, consulting firm says - 0 views
-
-
It's true, OOXML is not interoperable. It was designed for MSOffice and MSOffice only. The problem is that there is no interoperable" alternative to OOXML!!!! ODF itself has serious interoperability problems fully demonstrated at the October 2007 ODF Interoeprability Workshop held in Barcelona Spain. If users want interoperbility with ODF, they must settle on a single ODF vendor. So how is that different from the interop problems imposed by OOXML?
-
3More
shared by Gary Edwards on 12 Dec 07
- Cached
Microsoft Hit By U.S. DOT Ban On Windows Vista, Explorer 7, and Office 2007 - Technolog... - 0 views
www.informationweek.com/...showArticle.jhtml
exchange/sharepoint government msoffice odf opendocument standards vista vistachain vistastack
![](/images/link.gif)
-
» E-Mail » Print » Discuss » Write To Editor late last year -- can be resolved. "We have more confidence in Microsoft than we would have 10 years ago," says Schmidt. "But it always makes sense to look at the security implications, the value back to the customer, and those kind of issues." The DOT's ban on Vista, Internet Explorer 7, and Office 2007 applies to 15,000 computer users at DOT proper who are currently running the Windows XP Professional operating system. The memo indicates that a similar ban is in effect at the Federal Aviation Administration, which has 45,000 desktop users. Compatibility with existing applications appears to be the Transportation Department's major concern. According to a separate memo, a number of key software applications and utilities in use in various branches of the department aren't Vista compatible. Among them are Aspen 2.8.1, ISS 2.11, ProVu 3.1.1, and Capri 6.5, according to a memo issued by staffers at the DOT's Federal Motor Carrier Safety Administration. Any prolonged ban on new Microsoft technologies by the federal government could have a significant impact on the software maker's bottom line, as Microsoft sells millions of dollars in software to the feds annually. http://as.cmpnet.com/event.ng/Type=count&ClientType=2&AdID=125682&FlightID=75634&TargetID=2625&SiteID=222&AffiliateID=283&EntityDefResetFlag=0&Segments=1411,3108,3448,11291,12119&Targets=2625,2878,7904,8579&Values=34,46,51,63,77,87,91,102,140,222,227,283,442,646,656,1184,1255,1311,1405,1431,1716,1767,1785,1798,1925,1945,1970,2217,2299,2310,2326,2352,2678,2727,2767,2862,2942,3140,3347,3632,3636,3638,3890,3904,4080,448
-
Whoa, those government desktops add up quickly. This Vista ban will immediately effect over 50,000 desktops, with tens of thousands more possibly impacted by the IE 7.0 ban. The MS Exchange/SharePoint Hub juggernaut is based on IE 7.0, which is not available for Windows 2000 - MSOffice 2000 desktops.
Lack of Vista Stack compatibility with non Microsoft application is given as the reason for the ban. But notice the "alternatives" to Vista mentioned; Novel SuSE and Apple Mac. What kind of interop - compatibility do they offer? My guess is ZERO!
The reality is that the DOT is trapped. My advice would be stay exactly where they are, keeping the current MSOffice desktop installs running. Then, install the Foundation's daVinci ODF plugin for MSOffice.
This will insure that Windows OS and MSOffice bound business processes can continue to function without disruption. Win32 APi based applications like those mentioned in the article can continue. Critical day to day business processes, workgroup and workflow related activities can continue without disruption or costly re engineering demanded by a cross platform port.
What daVinci doe sdo is move the iron triangle that binds Windows-MSOffice applications to business processes and documents, to an ODF footing. Once on a ODF footing, the government can push forward with the same kind of workgroup - workflow - intelligent docuemnt - collaborative computing advnaces that the Vista Stack was designed to deliver. Only this push will involve the highly competitive "the customer is sovereign" environment of ODF ready desktop, server, device and Web 2.0 systems. End of Redmond lock-in. End of the costly iron triangle and the force march upgrade treadmill that so enriches Microsoft.
So what's not to like? We can do this.
~ge~
http://docs.google.com/View?docID=dghfk5w9_20d2x6rf&revi
2More
BetaNews | Microsoft: Office Format War Over - 0 views
-
"Over the past few years, we've had two important file formats come into the market, OpenXML and ODF. Both were designed for different purposes, and both have been valuable additions to the market. Now we can also say that we have multiple implementations of both formats."
-
The war is over? When did Microsoft surrender? And when did they sign the official terms of surrender?
The terms of surrender are simple. Microsoft must agree to fully support and implement ODF as a native file format in all versions of MSOffice qualified for the current OOXML compatibility kit. Furthermore, MSOffice must offer end users the choice of selecting ODF as the default MSOffice file format.
Those are the terms of surrender, and i for one don't see how the Microsoft or Novell Translator plugin's qualify? These things are garbage!
What if an MSOffice user was to work on a document, save it to OOXML only to open it later to find a near totally useless and corrupted document with a conversion fidelity equal to that achieved by the hapless MCN Translator Plugins?
Right. What's good for the goose is good for the gander. Until these idiotic MCN Translators can achieve a conversion fidelity between ODF and OOXML acceptable to MSOffice users - comparable to native documents use and expectations, they should be regarded for what they are: an experimentation proving conclusively that OOXML is not even close to being interoperable with ODF.
~ge~
3More
shared by Gary Edwards on 12 Dec 07
- Cached
PlexNex: HUMOR: Interoperability, Choice and Open XML - 0 views
fussnotes.typepad.com/...interoperabilit.html
iso microsoft msoffice oasis odf ooxml opendocument openxml xml
![](/images/link.gif)
-
It is important to recognize that ODF and Open XML were created with very different design goals and that they are only two of many document format standards in use today, each of which has characteristics that are attractive to different users in different scenarios
7More
untitled - 0 views
-
Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work
-
Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work That is the way quality specifications are written. For example, ISO/IEC's JTC 1 Directives (link to PDF) requires that international standards designed for interoperability "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." With that clarity, conformance is testable and can provide confidence of interoperability. A suite of tests may be developed and applied to an implementation to determine which tests pass, which fail, and hence arrive at an objective pronouncement on conformance of an implementation against the entirety of the specification.
-
In a quality specification, it should be feasible to select a normative paragraph, identify a conformance test for it, and make a clear statement that this test proves that an implementation meets (or fails to meet) that requirement. Call it a test plan: define the tests (test specification), define the expected set of results, and define what constitutes a "pass" of each test that establishes conformance. The plan then provides the matrix of test spec against requirement. Simple.
- ...4 more annotations...
-
Rob Weir of IBM chaired (apology for the misuse of that last word) the formation list and then simply announced what the charter would be rather than seeking consensus among the list participants. As part of this process before that charter was produced and while I still naively believed that consensus was a goal, I sat down with ODF 1.1 and did a paragraph-by-paragraph review for testability. The numbers were quite revealing. I completely reviewed only the first four major sections and found very few clear requirements. The majority were mere statements with no normative language used to identify what was required or optional. Implementors would have to make their own interpretation.
-
It's ironic that the chair viewed as good news the fact that there were far fewer testable paragraphs than he had predicted. But his prediction of 10,000 test cases is probably far closer to how many testable paragraphs there should be; my counts were actually bad news.
-
All of the above leads to the interesting question of just how the chair expects to accomplish much that is useful in regard to ODF conformance testing before the specification is amended to tighten up the language and add clear requirements. The syntax conformity is already handled by validation against the schema, but the semantics are woefully under-specified.
-
Summary: ODF 1.1 isn't verifiable as a specification. From a fairly cursory review of the latest draft, ODF 1.2 will follow the same path. With OASIS now being more demanding regarding conformance requirements on every specification and with ISO/IEC taking a closer interest in liaison with the ODF TC, I find it hard to see how the ODF TC co-chairs can maintain this view toward verification.
2More
OOXML is defective by design: Microsoft's latest aggression on ODF, codenamed "cast lead" - 0 views
15More
Next round of ODF vs OOXML… « CyberTech Rambler - 0 views
- ...10 more annotations...
-
OOXML is fundamentally intended to document a format for a pre-existing technology and feature set of recent proprietary systems.
-
Found myself blocked from commenting on that blog entry for some reason. Here's the comment I tried to post. @ctrambler "Between vendor-heavy or user-heavy, I choose vendor-heavy. It is after all, a office document format designed for office application. Linking with other systems is important, but it is not the ultimate aim." That statement bespeaks lack of familiarity with what an IT standard *IS.* But it is a lack of familiarity shared by all too many who work on IT standards. Standards are about uniformity, not variability. An international standard must by law specify [i] all characteristics [ii] of an identifiable product or group of products [iii] only in mandatory "must" or "must not" terms. WTDS 135 EC - Asbestos, (World Trade Organization Appellate Body; 12 March 2001; HTML version), para. 66-70, http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm And IT standards in particular must "clearly and unambiguously specify all conformity requirements that are essential to achieve the interoperability." ISO/IEC JTC 1 Directives, (5th Ed., v. 3.0, 5 April 2007) pg. 145, http://www.jtc1sc34.org/repository/0856rev.pdf Absent such specifications, a standard is a standard in name only. A standard is intended to establish a market in standardized goods, creating economic efficiency and competition. This is perhaps most simply illustrated with weights and measures, where a pound of flour must weigh the same regardless which vendor sells the product. But we can also see it in the interoperability context, e.g., with standardized nuts, bolts, and wrenches. Absent sufficient specificity to enable and require interoperability, ODF and OOXML create technical barriers to trade rather than promoting competition. And the Agreement on Technical Barriers to Trade unambiguously requires that national standardization bodies "shall ensure that technical regulations [includes international standards] are not prepared, adopted or applied with a v
-
(continuation). . And the Agreement on Technical Barriers to Trade unambiguously requires that national standardization bodies "shall ensure that technical regulations [includes international standards] are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade." http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm#articleII So while I agree that linking IT systems may not invariably be the ultimate goal, sufficient specificity in an IT standard to do so is in fact a threshold user and legal requirement. Otherwise, one has vendor lock-in and definition of the standard is controlled by the vendor with the largest market share, not the standard itself. Neither ODF nor OOXML met than threshold for eligibility as international standards and still do not. In both cases, national standardization bodies voted to adopt the standards without paying heed to fundamental legal and user requirements.
12More
Groklaw - When Would You Use OOXML and When ODF? -- What is OOXML For? - 0 views
-
If you say Groklaw is an echo chamber, for example, it has insulting connotations
-
Groklaw deserves respect
-
on a committee set up to help a national body
- ...2 more annotations...
-
Microsoft (and Alex Brown) are working within JTC1/SC34
-
The more interesting issue to me is whose voice Groklaw echoes. On the document format war, it's seemed since I stopped contributing articles to Groklaw a few years ago that it is the IBM public relations department's voice being echoed. I'll save for another day the topic of whether the echo chamber is self-delusional or deliberately intended to delude readers.
-
... and who it's aimed at. It's not as if Groklaw carries any weight (is it?)
-
Groklaw throws a pretty good punch. E.g., it launched ODF vs. Microsoft XML formats as a public issue. The blog is very influential with trade press reporters who are sympathetic to open source software. And Groklaw has done some good reporting, albeit with evident bias. Its chronicles of the SCO vs. IBM and Novell saga is undoubtedly the most thorough out there. But on ODF and OOXML, the coverage has been presented entirely as a black hat/white hat issue, ODF being perfect and designed for interoperability but OOXML as being pure evil. See e.g., http://www.groklaw.net/article.php?story=20080417104016186 (""If you want true interoperability, you need to implement ODF. Seriously. Any limitations to interoperability are entirely on Microsoft's side of the aisle, and the whole world knows it"). Intended or not, Groklaw justly deserves much credit for forestalling public oversight of the ODF TC's utter failure to deal with interoperability issues effectively and credit for keeping the oversight focus solely on OOXML. You'll find no coverage of ODF bugs on Groklaw, only ODF hugs and kisses. I see the blog as having substantially delayed ODF's repair. Groklaw has an enormous readership and particularly among citizen activists who approach ODF as a political cause rather than as a technical specification. But the Groklaw flavor of ODF v. OOXML propaganda remains consistent with that of IBM VP Bob Sutor.