Why does Microsoft want another standard, what's the rationale?
There are at least 4 good reasons why:
*ODF started out and was completed as an XML format, specifically supporting OpenOffice with a tight scope around that product.
*It wasn't until 2005 that the spec was offered up as a general XML office document format and consequently renamed to ODF.
*No opportunity existed for Microsoft to actually participate in this full process - given the original scope, the 6 months between the re-naming of the spec to ODF, and its subsequent approval by OASIS as a standard.
*The scope of the ODF spec never included even the basic requirements that Microsoft required to support a fully open format, and nor did the OASIS technical committee want to include these requirements.
Group items tagged
The Age of OOXML Computing - thanks a pant load Sun! - 0 views
-
Erwin's StarOffice Tango has an exhaustive response to this Microsoft Q&A. Correcting false statements by Microsoft
OpenForum Europe - EU Conclusions from Open Document Exchange Formats Workshop - 0 views
-
here was strong consensus among Member State administrations on the necessity to use ODEF on "openness" being the basic criteria of ODEF and resulting requirements towards industry players / consequences for public administrations There is a general dissatisfaction with the perspective of having competing standards; One format for one purpose: Administrations should be able to standardize (internally) on a minimal set of formats; No incomplete implementations, no proprietary extensions; Products should support all relevant standards and standards used should be supported by multiple products; Conformance testing and document validation possibilities are needed -> in order to facilitate mapping / conversion; Handle the legacy / safeguard accessibility
-
There must be something in the air. The end user inspired idea that applications should be able to exchange documents perfectly preserving the presentation (man percieved appearance as opposed to machine interpreted layout-rendering) is gaining a rabid momentum.
Yesterday it was the Intel ODF Test Suite results falling into the hands of Microsoft, who is now using the results to argue that OpenOffice doesn't fully support - implement ODF. The Intel ODF Test Suite is notable in that the test is near 100% about comparative "presentation" :: an object to object ocmparison of a KOffice document to an OpenOffice rendering of that document and vice versa.
Today we have the EU IDABC hosting a continent wide conference discussing the same issue :: the "exchange" of ODF documents. They've even gone so far as to coin a new term; ODEF - OpenDocument Exchange Format!
This morning i also recieved an invite to join a new OASIS discussion list, "The DocStandards Interoperability List". The issue? The converision and exchange of documents between different standards.
And then there is the cry for help from Sophie Gautier. This is an eMail that has worked it's way up to both the OASIS ODF Adoption TC and OASIS ODF Mainline TC discussion lists. The problem is that Microsoft is presenting the Intel ODF Test Results to EU govenrments. Sophie needs a response, and finds the truth hard to fathom.
Last week the legendary document processing expert Patrick Durusau jumped into the ODF "Lists" embroglio with his concern that the public has a different idea about document exchange - interoperability than the ODF TC. A very different idea. The public expects a visual preservation of the documents presentation qual
LinuxWorld | Game over for OpenDocument? - 0 views
-
Wow, what a story! Slashdotted twice:
http://ask.slashdot.org/comments.pl?sid=258073&threshold=1&commentsort=0&mode=thread&pid=20064251#20153479
Does ODF Have a Future? - 0 views
-
This section of the Slashdot discussion of the LinuxWorld "Game Over" article concerns itself with RTF and Microsoft. ACME 376 "decodes" and converts MS RTF to XML encoded RTF. The full da Vinci process follows this chain: imbr<>MS RTF<>ACME 376<>InfoSet = output target file format MS RTF is the internal structuring stage that all in-memory-binary-representation are sent through with any conversion. Including the conversion of imbr to OOXML The OOXML plugin process looks like this: imbr<>MS RTF<>OOXML The da Vinci ODF process looks like this: imbr<>MS RTF<>ACME<>InfoSet<>ODF The da Vinci CDF process outputs to CDF instead of ODFThe reason we need to output to something other than ODF is that the OASIS ODF TC has no interest in provisioning the ODF specification with much needed iX "interoperability eXtensions". the iX eXtensions were designed to accomodate the high fidelity "round trip" conversion of existing MS documents to ODF while establishing a high level of interoperability with existing MS applications and workgroup processes.
Serious Accessibility Issues with OOXML! Adaptive Technology Resource Centre Analysis ... - 0 views
-
Whoa, another must read analysis of OOXML. This one is provided by the University of Toronto, with a focus on "accessibility" issues. Not surprisingly, OOXML fails on nearly all counts.
The authors recommend that we go back to work on improving ODF and the accessibility of ODF ready applications.
Groklaw - Microsoft, antitrust and innovation, by Georg Greve - 0 views
-
Interoperability: The second abusive practice the Commission found Microsoft guilty of is the deliberate obstruction of interoperability, generally achieved through arbitrary and willful modification of Open Standards. This makes it impossible for competitors to write interoperable software. This is to the detriment of customers, who find themselves locked into the products of one vendor, the antithesis of competition.
-
It might look much worse in the light of public statements that Microsoft will not even commit to standards that it has proposed itself, such as the recent Microsoft OfficeOpenXML (OOXML) format it wants approved by ISO. The less people talk about the interoperability side of the case, the better for Microsoft. Otherwise people might connect MS-OOXML to the fact that Microsoft initiated the standardisation effort in the workgroup server area to open the market and later started obstruction of interoperability on its own standard to drive the innovator out of the market.
-
Great point. I think tha tanytime a big vendor embraces an open standard they should committ to full public documentation and explanation of any eXtensions to their implementaiton of that standard. Interoperability matters!
-
-
Excellent explanation of Microsoft's problems in Europe. One can only hope that the successor to the Bush Administration is paying attention.
ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for... - 0 views
-
AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
-
Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years. Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
-
Here's the meat of the French convergence proposal.
-
-
French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?
The plan has four parts:
"Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."
"Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."
"Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."
Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."
So there you go. A solution that removes ODF and OOXML from the clam
INTERVIEW: Craig Mundie -- Microsoft's technology chief, taking over from Bill Gates - 0 views
-
In this exclusive interview with APC, Mundie says the notion of all software delivered entirely through the web browser is now widely recognised as being 'popular mythology'. He also stakes the claim that Google's existence and success was contingent on Microsoft creating Windows. He talks about what's coming down the pipeline for future versions of Windows, and his belief that Windows can get still more market share than it has today. He also discusses the issues around the recent controversy over the Office Open XML file format.
-
So Vista is in its diffusion cycle and until there is enough of it out there, you won't really see the developer community come across.
-
Uh, the diffusion we really should be focused on involves the OOXML plug-in for MSOffice, IE 7.0, MSOffice 2007, and the Exchange/SharePoint Hub.
The Exchange/SahrePoint juggernaught is now at 65% marketshare, with Apache servers in noticeable decline.
So it seems the improtant "diffusion" is going forward nicely. The exploitation of the E/S Hub has also started, and here the Microsoft deelopers have an uncahllenged advantage. Most of the business processes being migrated to the E/S Hub are coming off the MSOffice bound desktop. Outsiders to the MS Stack do not have the requisite access to the internals that drive these MSOffice bound business processes, so they have little hope of getting into the "exploitation" cycle.
This aspect was on full display at the recent Office 2.0 Conference in San Francisco. The only way a O2 provider can position their service as a collaborative addon to existing business processes is to have some higher level of interop-integration into those processes beyond basic conversion to HTML.
Most O2 operatives struggle to convince the market that an existing business process can be enhanced by stepping outside the process and putting the collaboration value elsewhere. While this approach is disruptive and unfriendly, it tends to work until a more integrated, more interoperable coolaboration value becomes available.
And that's the problem with O2. Everyone is excited over the new collaboration possibilities, but the money is with the integration of collaborative computing into existing business processes. This is a near impossible barrier for non Microsoft shops and would be competitors. If you're Microsoft though, and you control existing formats, applications and processes, the collaboration stuff is simple value added on. It's all low hanging fruit that Microsoft can get paid to deliver while O2 players struggle to f
-
-
So far, we have delivered about 60 million copies. That would represent about six per cent of the global Windows install base. So it has probably got to get up another few percentage points before you will start to see a big migration of the developer community.
-
What is he talking about? Does a developer write to Vista? Or do they write to MS Stack ready .NET - OOXML-Smart Documents, XAML, Silverlight stuff?
-
- ...2 more annotations...
-
Great inteview, i'll comment as i make my way down the page. Hopefully others will do the same.
Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views
-
To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
-
OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.
The binding model for OOXML is "Smart Documents", and it is proprietary!
Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.
Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.
Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.
I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.
Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.
One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.
This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
-
-
Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
-
The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.
Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!
So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.
So where is an Open Stack model to turn to?
Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.
OOXML is unfi as a UFF becuase it is application - platform and vendor bound.
For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.
XHTML+ (XHTML + CSS3 + RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML+. Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML+?
I think so. But we can't be sure until the da Vinci proves this conclusively.
One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.
So why not try it with XHTML+, or ODEF (the eXtended version of ODF en
-
-
Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
-
This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.
The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.
The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!
This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.
Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.
It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.
With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF +), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.
MSOffice 2007 i
-
- ...6 more annotations...
Butcher this! -- Microsoft legislatively TKO's open document formats. - 0 views
-
The question we should be asking is why State CIO's and IT divisions are not backing the legislative proposals? It's not the lobbying that is killing ODF. It's the lack of support from those who would have been left with the challenge of implementing ODF solutions. The silence of the CIO's is deafening.
-
The title here has nothing to do with the content. The original title is, "Politics is only a small part of this story".
It's been a while since i last posted to the ZDNet TalkBack, and was totally thrown by the TalkBack formating needs. My first post dropped all line breaks, and came out as one long run on sentence.
Now maybe that's the way i write, (and think), but at least with some formatting i can hide that fact!
Still, "Butcher This!" is not a bad title.
~ge~
Game Over! Latest Draft of Mass. ETRM Includes OOXML - 0 views
-
this new draft includes Microsoft's OOXML formats as an acceptable "open format."
-
Game Over? Probably. I've been expecting Massachusetts to publicly revise the ODF mandate to include OOXML ever since Louis Gutierrez resigned in early October of 2006. That was as clear a signal that ODF had failed in Massachusetts as anyone needed.
The only surprise is that it took the new CIO, Beth Pepoli so long to make the announcement that OOXML would be recognized as an officially recognized open XML file format going forward.
Andy UpDegrove of course does his best to downplay the significance of this announcement. But how can this not be the deathnell for ODF?
The failure of ODF in Massachusetts has resulted in a world wide recognition that it is impossible to implement ODF.
This is exactly what happened to ODF mandate legislature in California. The CIO's in California uniformly rejected both ODF legislation and Sun's hapless effort to set up an ODF Pilot Study based on what had happened in Massachusetts. If Mass couldn't implement ODF, than they saw no reason for them to try.
And it does come down to "implementation".
Most people think the implementation of ODF is as easy as downloading OepnOffice and converting your legacy docuemnts to ODF as they are used. Simply fix the artifacts of conversion in process, and never look back. OOo is free. So what's not to like?
Well, the problem is that the world has fifteen plus years of building business processes, line of business integrated applications and other client/server integration on top of the MSOffice application suite. These business processes are bound hard to MSOffice.
So the barrier for OpenOffice and ODF is twofold. Any implementation of ODF must overcome both the binary documents conversion barrier, and, the MSOffice bound business process barrier.
The cost and disruption of a <font
The Microsoft Document Juggernaut: ECMA to Begin Drafting XPS as Alternative Standard t... - 0 views
-
"Be that as it may," Updegrove continues, "perpetuating one monopolistic market position after another seems wholly incompatible with the role of a global standards body, tasked with protecting the interests of all stakeholders. If OOXML, and now Microsoft XML Paper Specification, each sail through ECMA and are then adopted by ISO/IEC JTC1, then it may be time to wonder whether the time has come to declare 'game over' for open standards."
-
More on Andy UpDegrove's "Game Over for open standards" comment.
Frankly Speaking: Microsoft's Cynicism - Flock - 0 views
-
In July, Jones was asked on his blog whether Microsoft would actually commit to conform to an officially standardized OOXML. His response: “It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. ... Since it’s not guaranteed, it would be hard for us to make any sort of official statement.”
-
Then why is Microsoft dragging us through this standardization nonsense? Is this nothing more than thinly veiled assault on open standards in general?
-
-
To at least some people at Microsoft, this isn’t about meeting the needs of customers who want a stable, solid, vendor-neutral format for storing and managing documents. It’s just another skirmish with the open-source crowd and rivals like IBM, and all that matters is winning.
-
The battle between OOXML and ODF is very much about two groups of big vendor alliances. Interestingly, both groups seek to limit ODF interoperability, but for different reasons.
See: The Plot To Limit ODF Interop
-
-
Good commentary from Frank Hayes of Computerworld concerning a very serious problem. Even if ISO somehow manages to approve MS-OOXML, Microsoft has reserved the right to implement whatever extension of Ecma-OOXML they feel like implementing. The whole purpose of this standardization exercise was to bring interoperability, document exchange and long term archive capability to digital information by separating the file formats from the traditions of application, platform and vendor dependence.
If Microsoft is determined to produce a variation of OOXML that meets the needs of their proprietary application-platform stack, including proprietary bindings and dependencies, any illusions we might have about open standards and interoeprability will be shattered. By 2008, Microsoft is expected to have over a billion MS-OOXML ready systems intertwined with their proprietary MS Stack of desktop, server, device and web applications.
How are we to interoperate/integrate non Microsoft applications and services into that MS Stack if the portable document/data/media transport is off limits? If you thought the MS Desktop monopoly posed an impossible barrier, wait until the world gets a load of the MS Stack!
Good article Frank.
~ge~
Indecision in Redmond as Web apps charge : Office 2.0 and Google Apps - 0 views
-
the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.
-
Great quote from Eric Knorr. He hits the nail on the head here, pointing out the problem Office 2.0 Web Apps and SaaS apps face: If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios. If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process. The only way to overcome that kind of a split is to take the entire process. Which is difficult for lightweight mashup happy web wonders to do.
Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft. As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life. At any time Microsoft can swoop in and take it all.
Today, the MSOffice OOXML file format displays perfectly in a browser. It's 100% web ready, but only the MS Stack of applications gets to play. Web wonders are not likely to recieve a Redmond invite now or ever.
Which brings us to the issue of the da Vinci plug-in for MSOffice. da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys. It can achieve the same high fidelity "round trip" conversion that OOXML is capable of. Maybe even better.
The problem for da Vinci isn't conversion fidlelity. Nor is it capturing business process important VBa scripts, macros, OLE, and security settings. da Vinci can do that just fine. The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!! For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF
Why Can't We All Just Get Along? - 0 views
-
My response to Tiffany's eWEEK article, Office file formats fail to communicate, and the GCN article, Can't we just get along?. good articles both.
My comments are the first time i've responded directly to Sun's proprietary eXtensions allegation. The truth is that we refused to release the da Vinci plug-in with the must have iX "interoperability enhancements". Sun of course totally opposed our iX proposals, insuring that ODF would fail in Massachusetts, California, Denmark, Belgium and with the EU-IDABC.
Nice work Sun! Yeah, that's the ticket. Limit ODF's interoperability so much so that it is impossible to implement ODF, and the world willl beat a path to your door.
Right!
~ge~ ~ge~
Can't We All Just Get Along? - 0 views
-
Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.
IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.
With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.
Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.
In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.
Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing doc
Once More unto the Breach: Office Open XML Conformance (A Lesson in Claiming Standards ... - 0 views
-
-
Presentation fidelity and round tripping? Looks like someone has been attention to what happened in Massachusetts.
-
-
As far as I can tell in the Massachusetts poster-child case, ODF has simply come to mean whatever OpenOffice.org does
-
Keep in mind orchmid that it is the OpenOffice code base that ODF is bound to. There are many instances of the OOo code base pushed by various vendors. Sun provides OpenOffice.org and StarOffice versions of the code base. Novell Open Office is the same code base. Same with Red Hat Office and IBM WorkPlace. Outside this common code base, ODF has near ZERO interoperability.
-
-
unfortunately the MS argument that support for OOXML equals "conformance" is also the same argument used by OpenDocument supporters to prove multi vendor, multi platform, multi application support.
BetaNews | Microsoft Will Support ODF If It Doesn't 'Restrict Choice Among Formats' - 0 views
-
None of this is to say that OpenDocument is perfect. Far from it. OpenDocument at present is crippled from an interoperability standpoint. I'm a member of the OASIS OpenDocument Technical Committee and I think the resistance of the big vendors to fixing the interoperability warts is simply outrageous, particularly because they are fairly trivial changes. But the advancement of software users' interests are not advanced by painting OOXML as other than deeply flawed. It is vendor-specific and far from "open." The lesser of the two evils is clearly OpenDocument, which is at least open even if not yet interoperable. The sooner folks can start discussing practical methods of convergence, the better. See e.g., http://ec.europa.eu/idabc/servlets/Doc?id=27956 That set of slides summarizing a conference of some 20 European national governments' IT types says a lot more about the future of office document formats than Mr. Asellus has to offer.
-
Marbux hits a homerun! Right ON!
-
‹ Previous
21 - 40 of 60
Next ›
Showing 20▼ items per page