The ODF-Converter translates OpenXML documents (.DOCX) to Open Document Format (.Open Document Format)
(and conversely) for Open XML processing applications. You will find below the list of
unsupported features which may be due to standard compatibility issues, or to the
translator itself (see rendering issues as discussed in the blog)...
Group items tagged
Odf - Converters & the ODF Zero Interop problem - 0 views
-
Explosive compatibility - interoperability study concerning ODF and MOOXL! This has Florian's signature written all over it, and it goes right to the heart of the matter.
David A. Wheeler submitted a comment to the OASIS ODF TC outlining his concerns with this publication. He suggests that a few minor changes to ODF could greatly improve compatibility - interop issues. He also figures out that OpenOffice - ODF has more features than MSOffice - MOOXML. Wha the doesn't ge is that it is these new and innovative features that continue to increase the difficulties of implementing ODF in real world business process workgroups!
David also ignores the fact that the TC jus tvoted down the Novell "LIt Enhancement Proposal" which was specifically designed to address the compatibility - interop issues outlined in this odf-converter blog! Given a choice, the ODF TC members chose the new and innovative features of the interop breaking Sun-KOffice "List Enhancement Proposal".
The List Enhancement Proposal discussion was so contentious and focused on personal destruction as to represent a total break down of the ODF concensus process. There is no way that either the Foundation or Novell will ever contribute another compatibility - interop enhancement proposal given the personal assault and determined oppostion of Sun to compatibility - interoperability initiatives.
The hard lesson the Foundation learned is that if you oppose Sun, you'll get booted out of OASIS!
The lesson Novell learned is that they are better off working through Ecma 376 to resolve these issues that the public demands be addressed.
Notice the last line in David's comment, "In any case, the MUCH, MUCH longer list of problems with Microsoft XML format isn't our problem."
During the contentious List Enhancement Proposal and the compatibility - interop related Metadata RDF/XML discussions, ODF members freque -
These are the same guys who just voted against the Novell List Enhancement Proposal that did exactly what the odf-converter blog claims needs to be done if the compatibility-interop problems are to be resolved!
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
The trap is set! Phony OASIS Messaging standard OK'd for Web services - 0 views
-
OASIS considers WS-ReliableMessaging critical for SOA, in that it can handle a variety of SOA requirements. WS-ReliableMessaging can be extended to enable integration with capabilities such as security. SOAP binding for interoperability is included. WS-ReliableMessaging is part of a series of Web services specifications dubbed WS-* that have been championed by companies such as Microsoft.
-
Check out the comments below this article. There are links to Ian Foster of Globus and to the Marbux license disseration posted with the OpenDocument Foundation's NO VOTE at OASIS.
An Antic Disposition: Cracks in the Foundation - IBM takes over ODF - 0 views
-
You must admire their tenacity. Gary Edwards and the pseudonymous "Marbux". The mythology of Silicon Valley is filled with stories of two guys and a garage founding great enterprises. And here we have two guys, and through blogs, interviews, and constant attendance at conferences, they have become some of the most-heard voices on ODF. Maybe it is partly due to the power of the name? The "OpenDocument Foundation" sounds so official. Although it has no official role in the ODF standard, this name opens doors. The ODF Alliance , the ODF Fellowship, the OASIS ODF TC, ODF Adoption TC (and many other groups without "ODF" in their name) have done far more to promote and improve ODF, yet the OpenDocument Foundation, Inc. seems to score the panel invites. Not bad for two guys without a garage.
-
An eMail went out today, October 24th, 2007, nominating IBM's Rob "Show me your garage!" Weir to be the new Co Chairman of OASIS ODF TC. So it's looks like it's true; IBM is moving to take over ODF and OpenOffice.
Not that that's bad. In the long run this is perhaps the best thing that ever happened to ODF and OpenOffice. There is no way IBM's Lotus Notes business plan for ODF-OOo could be any worse than Sun's plan has turned out to be.
~ge~
5 Things Microsoft Must Do To Reclaim Its Mojo In 2008 -- InformationWeek - 0 views
-
Instead of fighting standards, Microsoft (NSDQ: MSFT) needs to get on board now more than ever. With open, Web-based office software backed by the likes of IBM (NYSE: IBM) (think Lotus Symphony) and Google (NSDQ: GOOG) now a viable option, users—especially businesses frustrated by Microsoft's format follies (many are discovering that OOXML is not even fully backwards-compatible with previous versions of Microsoft Word)--can now easily switch to an online product without having to rip and replace their entire desktop infrastructure.
-
This article discusses how Microsoft might change their ways and save the company. This particular quote concerns Microsoft support for standards, and their fight to push MS OOXML through ISO as an alternative to ISO approved ODF 1.0.
The thing is, ODF was not designed for the conversion of MSOffice documents, of which there are billions. Nor was ODF designed to be implemented by MSOffice. ODF was designed exactly for OpenOffice, which has a differnet model for impementing basic docuemnt structures than MSOffice.
So a couple of points regardign this highlight:
The first is that IBM's Lotus Symphony is NOT Open Source. IBM ripped off the OpenOffice 1.1.4 code base back when it was dual licensed under both SSSL and LGPL. IBM then closed the source code adding a wealth of proprietary eXtensions (think XForms and Lotus Notes connections). Then IBM released the proprietary Symphony as a free alternative to the original Open Source Community "OpenOffice.org".
If Microsoft had similarly ripped off an open source community, there would be hell to pay.
Another point here is the mistaken assumption that users can easily switch from MSOffice to an on-line product like Google Docs or ZOHO "without having to rip our and replace their entire desktop infrastructure."
This is a ridiculous assumption defied by the facts on the ground. Massqchusetts spent two years trying to migrate to ODF and couldn't do it. Every other pilot study known has experienced the same difficulties!
The thing about Web 2.0 alternatives is that these services can not be integrated into existing business processes and MSOffice workgroup bound activities. The collaborative advantages of Web 2.0 alternatives are disruptive and outside existing workflows, greatly marginalizing their usefulness. IF, and that's a big IF, MSOffice plug-ins were successful in the high fidelity round trip conversion of wor
-
-
Microsoft in 2008 could make a bold statement in support of standards by admitting that its attempt to force OOXML on the industry was a mistake and that it will work to develop cross-platform compatibility between that format and the Open Document Format
-
It's impossible to harmonize two application specific file formats. The only way to establish an effective compatibility between ODF and OOXML would be to establish a compatibility between OpenOffice and MSOffice.
The problem is that neither ODF or OOXML were developed as generirc file formats. They are both application specific, directly reflecting the particular implementation models of OOo and MSOffice.
Sun and the OASIS ODF TC are not about to compromise OpenOffice feature sets and implmentation methods to improve interop with MSOffice. Sun in particular will protect the innovative features of OpenOffice that are reflected in ODF and stubbornly incompatible with MSOffice and the billions of binary documents. This fact can easily be proven be any review of the infamous "List Enhancement Proposal" that dominated discussions at the OASIS ODF TC from November of 2006 through May of 2007.
So if Sun and the OASIS ODF TC refuse to make any efforts towards compatibility and imporved interop with MSOffice and the billions of binary docuemnts seekign conversion to ODF, then it falls to Microsoft to alter MSOffice. With 550 million MSOffice desktops involved in workgroup bound business processes, any changes would be costly and disruptive. (Much to the glee of Sun and IBM).
IBM in particular has committed a good amount of resources and money lobbying for government mandates establishing ODF as the accepted format. this would of course result in a massively disruptive and costly rip out and replace of MSOffice.
Such are the politics of ODF.
-
Harmonizing ODF and OOXML: The DIN - ISO "Harmonization" Project - 0 views
-
Contact: Gerd Schürmann Fraunhofer Institute FOKUS Tel +49 (0)30 3463 7213 gerd.schuermann@fokus.fraunhofer.de Berlin
-
At a recent meeting in Berlin, The DIN Fraunhoffer Institute pushed forward with the EU project to harmonize ODF and OOXML. Microsoft and Novell attended the harmonization effort. Sun and IBM did not. This in spite of invitations and pleas to cooperate coming into Sun and IBM from government officials across the European continent. We've long insisted that inside the OASIS ODF Technical Committee walls there have been years of discussions concerning ODF compatibility with the billions of MS binary documents, and ODF interoperability with MSOffice. Sun in particular has been very clear that they will not compromise OpenOffice application innovations to improve interoperability with MSOffice and MSOffice documents. The infamous List Enhancement Proposal donnybrook that dominated OASIS ODF discussions from November 20th, 2006, to the final vote in April of 2007, actually begins with a statement from Sun arguing that application innovation is far more important than market demands for interoperability. The discussions starts here: Suggested ODF1.2 items The first of many responses declaring Sun's position that innovation trumps interop, and that if anyone needs to change their application it should be Microsoft: see here DIN will submit a "harmonization" report with recommendations to ISO JTC1. I wonder if IBM and Sun will continue to insist on government mandated "rip out and replace" solutions based on their ODF applications when ISO and the EU have set a course for "harmonization"?
OASIS OpenDocument Adoption TC Pending Requests - 0 views
-
Pending Requests for OASIS OpenDocument Format (ODF) Adoption TC
OASIS OpenDocument TC Pending Requests - 0 views
-
Pending Requests for OASIS Open Document Format for Office Applications (OpenDocument) TC
Microsoft Closer on \'Office Open\' Blessing - 0 views
-
Opponents to OOXML, which include IBM (Quote) and the Open Document Foundation, have argued that Microsoft's specifications are unwieldy and that the standard application is redundant with the Open Document Format (ODF), which already exists. Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address different needs in the marketplace," the company wrote in an open letter published earlier this month.
-
Internet News is reporting that Ecma has submitted to the ISO/IEC JTC1 their repsonsess to the 20 "fast track" for Ecma 376 (OOXML) objections. Nothing but blue skies and steady breeze at their back for our friends at Redmond, according to Ecma's rubber stamper in chief, Jan van den Beld.
Once again there is that ever present drum beat from Microsoft that ODF can't handle MSOffice and legacy MSOffice features - including but not mentioned the conversion to XML of those infamous billions of binary documents:
"Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address diffe
No REST in CMIS » Untangled by Roy Fielding - 0 views
-
REST creator Roy Fielding weighs in on CMIS, the Content Management Interoperability Services standard proposed by pay-to-play OASIS members and big RDBMS vendors; EMC, IBM and Microsoft. Note, Roy works for Day Software, which has been acquired by Adobe. The CMIS proposal is suspiciously similar to the Sursen UOML OASIS Standard that ISO rejected!!! excerpt: CMIS is a thin veneer on RDBMS-based data repositories that provides a data model for document-like objects within filesystem-like folders, basic file versioning, and access via SQL queries and local object references. It is exactly the kind of document model one would expect within a legacy document management system that is backed by a large relational database and authored via Microsoft Office applications. No surprise, given the sponsors, and there are plenty of good reasons why folks would want to support such data models.
ODF - the state of play - The future of ODF under OASIS, now that the... - 1 views
-
"ODF - open document format - is an open, XML-based rich document format that has been adopted as the standard for exchanging information in documents (spreadsheets, charts, presentations and word processing documents), by many governments and other organisations (see, for example, here), including the UK Government. This is despite strong opposition by Microsoft; but I have seen Microsoft's proposed "open XML" standard and, frankly, it is huge and horrid (in the word of standards, these go together). If I remember correctly, the early draft I saw even incorporated recognition of early Excel leap-year bugs into the standard. ODF is now a pukka ISO standard, maintained by OASIS, under the proud banner: "The future is interoperability". My personal thoughts, below, are prompted by an ODF session at ApacheCon Core titled "Beyond OpenOffice: The State of the ODF Ecosystem" held by Louis Suárez-Potts (community strategist for Age of Peers, his own consultancy, and the Community Manager for OpenOffice.org, from 2000 to 2011), and attended by very few delegates - perhaps a sign of current level of interest in ODF within the Apache community. Nevertheless, and I am talking about the ODF standard here, not Apache Open Office (which is currently my office software of choice) or its Libre Office fork (which seems to be where the excitement, such as it is, is, for now), the standards battle, or one battle, has been won; we have a useful Open Document Format, standardised by a recognised and mature standards organisation, and even Microsoft Office supports it. That's good. So what could be the problem? Well, I don't care whether I use ODF from Open Office, Libre Office or even Office 365, I just want to be sure that everyone else can read my ODF documents (with a .odt, .ods or .odp extension, for text, presentation or spreadsheet, respectively), with whatever software they like; and that they'll either see exactly the functionality and formatting I see; or a well defined (an
XML Production Workflows? Start with the Web and XHTML - 0 views
-
Challenges: Some Ugly Truths The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition. Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper. A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition. And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5] But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.
-
Practical Challenges In 2009, there is still no truly likeable—let alone standard—editing and authoring software for XML. For many (myself included), the high-water mark here was Adobe’s FrameMaker, substantially developed by the late 1990s. With no substantial market for it, it is relegated today mostly to the tech writing industry, unavailable for the Mac, and just far enough afield from the kinds of tools we use today that its adoption represents a significant hurdle. And FrameMaker was the best of the breed; most of the other software in decent circulation are programmers’ tools—the sort of things that, as Michael Tamblyn pointed out, encourage editors to drink at their desks. The labour question represents a stumbling block as well. The skill-sets and mind-sets that effective XML editors need have limited overlap with those needed by literary and more traditional production editors. The need to think of documents as machine-readable databases is not something that comes naturally to folks steeped in literary culture. In combination with the sheer time and effort that rich tagging requires, many publishers simply outsource the tagging to India, drawing a division of labour that spans oceans, to put it mildly. Once you have XML content, then what do you do with it? How do you produce books from it? Presumably, you need to be able to produce print output as well as digital formats. But while the latter are new enough to be generally XML-friendly (e-book formats being largely XML based, for instance), there aren’t any straightforward, standard ways of moving XML content into the kind of print production environments we are used to seeing. This isn’t to say that there aren’t ways of getting print—even very high-quality print—output from XML, just that most of them involve replacing your prepress staff with Java programmers.
-
Why does this have to be so hard? It’s not that XML is new, or immature, or untested. Remember that the basics have been around, and in production, since the early 1980s at least. But we have to take account of a substantial and long-running cultural disconnect between traditional editorial and production processes (the ones most of us know intimately) and the ways computing people have approached things. Interestingly, this cultural divide looked rather different in the 1970s, when publishers were looking at how to move to digital typesetting. Back then, printers and software developers could speak the same language. But that was before the ascendancy of the Desktop Publishing paradigm, which computerized the publishing industry while at the same time isolating it culturally. Those of us who learned how to do things the Quark way or the Adobe way had little in common with people who programmed databases or document-management systems. Desktop publishing technology isolated us in a smooth, self-contained universe of toolbars, grid lines, and laser proofs. So, now that the reasons to get with this program, XML, loom large, how can we bridge this long-standing divide?
- ...44 more annotations...
-
I was looking for an answer to a problem Marbux had presented, and found this interesting article. The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML. From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article. Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML. Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
-
I was looking for an answer to a problem Marbux had presented, and found this interesting article. The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML. From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article. Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML. Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. As an after thought, i was thinking that an alternative title to this article might have been, "Working with Web as the Center of Everything".
-
I was looking for an answer to a problem Marbux had presented, and found this interesting article. The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML. From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article. Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML. Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
GullFOSS: It's our way or the highway. So what if new cool features = Zero Interop? D... - 0 views
-
When such new features that enhance the interoperability require enhancements to the Open Document file format we will propose the necessary changes to the OASIS Open Document TC. This way not only OpenOffice.org but also Open Document benefits from our efforts. Florian Reuter, who now works for Novell, lists some of the changes we have in mind in his blog . So there are a lot of common ideas how we can improve the interoperability between OpenOffice.org and Microsoft Word documents and I hope we can work together with Florian here.
-
The chuckleheads at Sun's StarOffice/OpenOffice Hamburg office respond to Florian's comprehensive lis tof suggestions to greatly improve ODF interoperability.
-
Make no mistake about it. Microsoft is absolutely right about three things: .... Compatibility with existing file formats is not an ODF concern. .... Sun controls the OASIS ODF TC. .... Sun makes certain that ODF is bound tightly to the OpenOffice feature set. Sun's view of interoperability is that of a one way street. Documents can be converted into ODF-OOo/SO, but they are guaranteed to break during any kind of document routing or round tripping. This is also the reason why the Sun "external" plugin for MSOffice fails. One way conversion simply isn't enough to crack the hold MSOffice has on critical day to day business processes. The only way to that is with a conversion process able to maintain high level fidelity while round tripping. As the EU IDABC has figured out, the ODF-OOo/SO specification is loaded with interoperability break points. That's why they are turning to ODEF, which can be seen as a version of ODF that is truly application independent and optimized for interoperability. ~ge~
LOL :: Microsoft's Jean Paoli on the XML document debate - 0 views
-
What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive. I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.” What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”
-
“Open Document Format and Office Open XML have very different goals”, says Paoli, responding to the claim that the world needs only one standard XML format for office documents. “Both of them are formats for documents … both are good.”
-
The door should have been slammed shut on OOXML near five years ago when, on December 14th, 2006, at the very first OASIS ODF TC meeting, Stellent's Phil Boutros proposed that the charter include, "compatibility with existing file formats and interoperability with existing applications" as a priority objective.
-
-
I put it to Paoli that OOXML is hard to implement because of all its legacy support, some of which is currently not well documented. “I don’t believe that at all. It’s actually the opposite,” he says. He make the point that third parties like Corel, which have previously implemented support for binary formats like .doc and .xls, should find it easy to transition to OOXML. “We believe Open XML adoption by vendors like Corel will be very easy because they have already been doing 90% of the work, doing the binary formats. The features are already there.”
-
WordPerfect does an excellent import of MSWord .doc documents. But there is no conversion! It's a read only rendering. Once you start editing the document in WP, all kinds of funny things happen, and the perfect fidelity melts away like the wicked witch of west in a bucket full of water.
-
- ...5 more annotations...
-
Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF. Jean Paoli of course has the predictable set of answers. But Tim anderson provides us with some interesting insights and comments of his own. There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.
The bottom line for Microsoft has not changed. MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents. He claims that ODF is not compatible, and offers the "page borders" issue as an example.
Page borders? What's that got to do with the ODF file format? These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice. The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice.
So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML. But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!! No problem!!!!!!!!!!
The problem is opening up that same da Vinci MSWord document in OpenOffice. That's where the page borders are dropped. The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.
If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!
Now i will admit that this is one very difficult issue to understand. If not f -
Great interview. Tim can obviously run circles around poor Jean Paoli.
[office] List Proposal Vote Deadline on Wednesday - 0 views
-
The List Proposal donnybrook refuses to go away. In a recent argument concerning Rick Jellife's controversial post, "Harmonization by augmenting ODF with OOXML elements", ODF defender Bruce D'Arcus pointed to his own OASIS ODF TC message thread in an effort to defend Sun.
The issue is that Rick Jellife and others are wondering why it is that Sun opposes interoperability enhancements to ODF that would solve the problem of converting MS binary and XML documents to ODF, and back.
Bruce's reference introduces the incredibly acrimonious "List Proposal Vote Deadline" thread. He also brings up a really important problem. The ODF Charter does not reference compatibility with existing file formats as a key objective.
The consequences of this neglect in the ODF Charter is that every time the issue of compatibility with existing MS binary or xml documents comes up, Sun claims it's, "Outside the Charter and Out of Scope".
I've been hearing that excuse for the last five years!! Meanwhile, the world has discovered it's impossible to implement ODF without also having to totally rip out and replace MSOffice. And that means a costly re engineering all existing business processes, line of business integrated apps, and assistive technology add-ons.
ODF failed in Massachusetts because Sun and OASIS TC refused to recognize the importance of an ODF plugin for MSOffice offering the same high fidelity "round trip" conversion as the OOXML plugin for MSOffice.
For one reason or another, big ODF vendors are locked into a "rip out and replace - legislative mandate" strategy. A strategy to limit the interoperability of ODF with MS documents, applications, and processes has only one consequence. As Massachusetts proved to the world, ODF is impossible to implement if you have workgroups and business processes based
Between a rock and a hard place: ODF & CIO's - Where's the Love? - 0 views
-
So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence. After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators. And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
-
Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled Microsoft trounces pro-ODF forces in state battles over open document formats.
Andy believes that it is the failure of state legislators to do their job that accounts for these failures. He provides three reasons for this being a a failure of legislative duty. The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors.
The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.
Andy puts it this way, "
And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats. You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe
But can they implement ODF? South African Government Adopts ODF (and not OOXML) - 0 views
-
That said, it goes on to acknowledge that “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.
-
So, South Africa was watching closely the failed effort in Massachusetts to implement ODF? And now they are determined to make it work? Good thing they left themselves a "pragmatic" out; "there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects."
Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice. In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications. At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications. Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made. So what happened?
Over a year later,
Novell adds fuel to the fire in OOXML feud - News - Builder AU - 0 views
-
Microsoft has created its own proprietary document format, Office Open XML (OOXML), as a rival to the community-developed OpenDocument Format (ODF). OOXML is used in Microsoft's latest applications suite, Office 2007. Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format. According to Novell's vice president of developer platforms, Miguel de Icaza, the situation won't change in the foreseeable future. Want to know more? For all the latest news, analysis and opinion on open source, click here "There's no end in sight to the ongoing disputes between the two camps," said de Icaza, speaking at XML 2007, a Microsoft-sponsored event, on Tuesday. "In 2006, there was lots of FUD [fear, uncertainty and doubt] about the problems behind OOXML and it went downhill from there," Icaza said. "Neither group is willing to make the big changes required for real compatibility," de Icaza added.
-
What efforts are you talking about? The last time any effort was made to accomodate interoperability was in 2003 with the establishment of the ODF "Compatibilty clause" (Section 1.5). "Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format......" Section 1.5 authorizes the use of "foreign elements" and "alien attributes". These techniques were specifically written into ODF for handling unknown characteristics of existing MSOffice documents (binary and/or xml) on conversion to ODF. Since the Section 1.5 addition in 2003, every other suggestion to improve interop between ODF and MSOffice documents has been rejected by the OASIS ODF TC and Sub Committees. There are three problems with Section 1.5. The first is that there is only so much that can be done with foreign elements and alien attributes. There are still remaining compatibility issues relating to the basic structures of lists, tables, fields, sections and page dymnamics. The OpenDocument Foundaiton spent over a year trying to get approval for five generic elements relating to these structures, without success. As i said, there has not been a single successful comatibility - interoperability effort since 2003, although many have been proposed. The second reason for the failure of Section 1.5 is that OpenOffice only partially implements the "Compatibility Clause". OOo only recognizes "foreign elements and alien attributes" with text spans and paragraphs. The third reason is that "compatibility" is optional in ODF. The clause does not have any teeth. Applications can implement only those aspects of the spec they feel like implementing, and still be in total "compliance". This creates serious interop problem not only for MSOffice plug-in comverted documents, but also renders as
-
Can IBM save OpenOffice.org from itself? - 0 views
-
This quote from Chalres Schultz is ridiculous. Because Novell is not allowed to commit code to OpenOffice, they must maintain a separate code base of extensions and improvements. With each build of OpenOffice, Novell must reintegrate their changes into the code base, making for a managerial nightmare. When Novell does have improvements that Sun wants though, there is no end to the hoops of fire the Sun developers will jump through to get it. The Field Enhancement routine written by Novell's Florian Router is one of those improvements that Sun had to have. Sun even went so far as to arguing for changes in the way ODF implements fields to accomodate the Novell improvements! It's important to note however that Sun did not support the ODF Field Enhancements UNTIL Novell agreed to donate Florian's code to OpenOffice!!!!!! Proving conclusively what i have been arguing for years: Sun does not allow for any changes to ODF unless and until those changes can be implemented by OpenOffice. The ODF Field Enhancements needed by Florian's fix to OpenOffice were originally proposed on July 12th, 2006, when Florian was the CTO of the OpenDocument Foundation. These changes to the way ODF implements fields were needed by the da Vinci plug-in as part of our efforts to save ODF in Massachusetts. so here we have a rather direct example of Sun refusing improvements to ODF when needed by another application (da Vinci), but supporting those exact same changes when it is OpenOffice that can be improved!!! The arguments that the OpenOffice.org Community isn't open also apply to the OASIS ODF TC work!!!!!!
-
Good catch by Eric!
This link is to the infamous Sun statement of support for MS OOXML issued by Jon Bosak when ISO DIS 2900 was voted on by the US delegation to ISO.
The statement is important because it directly references the core issue: MS OOXML was written for MSOffice and the billions of binary docuemnts bound to that application suite. ODF on the other hand was written to OpenOffice.
Because ODF was not designed for the conversion of those billions of MSOffice documents, conversion is next to impossible. The implementation of ODF in MSOffice is next to impossible. The loss of information, especially the presentation-layout information, is so severe as to be intolerable in the real world.
This leaves the real world, where MSOffice dominates over 550 million desktops, unable to implement ODF. In light of this real world problem, Sun's Bosak urges support for MS OOXML as an ISO standard!!!
So we have this situation at OASIS ODF where Sun is in control of both ODF and OpenOffice, refusing in all cases to compromise the linkage or accomodate the much needed interoperability enhancemnts seeking to improve the conversion of billions of documents to ODF. And publicly supporting MS OOXML as the only pragmatic alternative to the situation Sun is responsible for!
‹ Previous
21 - 40 of 166
Next ›
Last »
Showing 20▼ items per page
If MEOOXML (Microsoft-ECMA Office Open XML) can pass through the contradiction without complaint, the 6,000 page specification describing XML encoding of MSOffice specific binary processes gets to move on to the fast track phase.
This is very sneaky stuff. Micrsoft tried to submit MEOOXML to ISO in mid December. Perhaps in hopes of catching an extra 20 or so days of holiday right in the midst of the critical 30 day contradiction review period. Apparently the USA representative to ISO JTSC1 refused the submission until after the hollidays. Still, with near zero publicity, and 6,000 pages of crap to sludge through, the review phase has begun.
IMHO, only the ODF experts can effectively point out the ocntradictions and inconsistencies with the MEOOXML submission. So this is a call for Rob Weir, Florian Reuter, Patrick Durusau, Sam Hiser, David A Wheeler, Bruce D'Arcus, the legendary Daniel Vogelheim, and the infamous Marbux to step forward with the full force of their expertise.
Since Florian has the most experience with the hapless and tragically deceptive MS-Novel-CleverAge Translator Project, where the glaringly obvious contradictions and inconsistencies are being hastily pasted over, i'm anxious to see where his blog takes us:
http://florianreuter.blogspot.com/
~ge~