Group items tagged

"For some time I've been considering writing a book about what has become a standards war of truly epic proportions.  I refer, of course, to the ongoing, ever expanding, still escalating conflict between ODF and OOXML, a battle that is playing out across five continents and in both the halls of government and the marketplace alike.  And, needless to say, at countless blogs and news sites all the Web over as well. Arrayed on one side or the other, either in the forefront of battle or behind the scenes, are most of the major IT vendors of our time.  And at the center of the conflict is Microsoft, the most successful software vendor of all time, faced with the first significant challenge ever to one of its core businesses and profit centers - its flagship Office productivity suite. The story has other notable features as well:  ODF is the first IT standard to be taken up as a popular cause, and also represents the first "cross over" standards issue that has attracted the broad support of the open source community.  Then there are the societal dimensions: open formats are needed to safeguard our culture and our history from oblivion.  And when implemented in open source software and deployed on Linux-based systems (not to mention One Laptop Per Child computers), the benefits and opportunities of IT become more available to those throughout the third world. There is little question, I think, that regardless of where and how this saga ends, it will be studied in business schools and by economists for decades to come.  What they will conclude will depend in part upon the materials we leave behind for them to examine.  That's one of the reasons I'm launching this effort now, as a publicly posted eBook in progress, rather than waiting until some indefinite point in the future when the memories of the players in this drama have become colored by the passage of time and the influence of later events. My hope is that those of you who have played or are n

Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio

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!

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.

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~

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~

I've got to give this one extra points for creativity!  All anyone has to do is visit the W3C web sites for CDF WICD Full 1.0 to realize that there is in fact a CDf profile for desktops.  CDF WICD Mobile is the profile for devices.

My guess is that Chris Lilley is threading the needle here.  IBM, Groklaw, and the lawyer for OASIS have portrayed the Foundation's support for CDF WICD Full as a replacement for ODF - as in native file format for OpenOffice kind of replacement.  Mr. Lilley insists that CDF WiCD Full was not designed for that purpose.  It's for export only!  As in a conversion of native desktop file formats.

Which is exactly what the da Vinci group was doing with MSOffice.  The Foundation's immediate interest in CDF WICD was based on the assumption that a similar conversion would be possible between OpenOffice ODF and CDF WICD.

The Foundation's thinking was that if the da Vinci group could convert MSOffice documents and processes to CDF WICD Full, and, a similar conversion of OpenOffice ODF documents and processes to CDF WICD could be done, then near ALL desktop documents could be converted into a highly interoperable web platform ready format.

Web platform ready documents from OpenOffice?  What's not to like?  And because the conversion between ODF and CDF WICD Full is so comparatively clean, OpenOffice would in effect, (don't go native file format now) become ahighly integrated rich client end user interface to advancing web platforms.

The Foundation further reasoned that this conversion of OpenOffice ODF to CDF WICD Full would solve many of the extremely problematic interoperability problems that plague ODF.  Once the documents are in CDF WICD Full, they are cloud ready and portable at a level certain to diminish the effects of desktop applications specific feature sets and implementation models.

In Massachusetts, the Foundation took

More bad information, accusations and smearing innuendo.  Wrong on the facts,  Emotionally spent on the conclussions.  But wow it's fun to see them with their panties in such a twist.

The truth is that ODF is a far more "OPEN" standard than MS-OOXML could ever hope to be.  Sam's Open Standards arguments for the past five years remain as relevant today as when he first started makign them so many years ago.

The thing is, the Open Standards requirements are quite different than the real world Implementation Requirements we tried to meet with ODF.

The implementation requirements must deal with the reality of a world dominated by MSOffice.  The Open Standards arguments relate to a world as we wish it to be, but is not.

It's been said by analyst advising real world CIO's that, "ODF is a fine open standards format for an alternative universe where MSOffice doesn't exist".

If you live in that alternative universe, then ODF is the way to go.  Just download OpenOffice 2.3, and away you go.  Implementation is that easy.

If however you live in this universe, and must deal with the impossibly difficult problem of converting existing MSOffice documents, applications and processes to ODF, then you're screwed. 

All the grand Open Standards arguments Sam has made over the years will not change the facts of real world implmentation difficulities.

The truth is that ODF was not designed to meet the real world implmentation requirements of compatibility with existing Microsoft documents (formats) and, interoperability with existing Microsoft Office applications.

And then there are the problmes of ODF Interoperability with ODF applications.  At the base of this problem is the fact that compliance in ODF is optional.  ODF applications are allowed to routinely destroy metadata information needed (and placed into the markup) by other applications.<b

Aha!  I mentioned in an earlier bookmark that Sun was involved in the Belgium ODF - OOXML Pilot Study.  It was disclosed by Peter V. (Belgium Consultant to Peter Strick's group) that Sun was proposing changes to the ODF 1.2 specification, after the close date, to improve the conversion fidelity problem their plug-in is having in the trials.  We tried to do the same thing to save ODF in Massachusetts.  Sun didn't have a plug-in for the Massachusetts trials, and opposed our iX interop enhancements and extensions.  I guess they are beginning to understand why the iX proposals are so important? 

If you can't convert MS binaries and xml to ODF, then there is no use in the real world for ODF.  It's that simple.   In California, the CIO's routinely refer to this problem as, "ODF is impossible to implement".

~ge~

Summary of First ODF Summit held in Armonk, organized by IBM and Sun. List of names for all attendees

Summary of First ODF Summit held in Armonk, organized by IBM and Sun. List of names for all attendees

Well, this is interesting.

What part of "Executive Board" makes you think they read 6,000 page XML specifications? <ge>

I think, in the best bureaucratic tradition, they argued definitions until they convinced themselves that they didn't need to do anything.  They decided that one standard contradicts another standard only if the proposed standard causes the existing standard not to work.  This is from analogy with the Chinese WAPI WiFi networking standard last year that was defeated because the protocol caused radio interference with existing 801.11 networks.  So they said that OOXML did not contradict ODF because both files could exist on the same disk without interfering with each other.   You will note that thiss argument can be used for every XML format, every programming language, every operating system, in fact every software standard, since software is ultimately data, and data can be segregated on disks.  So they essentially chose a definition so narrow that it nullified the concept of "contradiction" for most of what JTC1 has authority over.<!-- D(["mb","<div><br><span style\u003d\"color:rgb(0, 0, 153)\"><ge>  Wait a second.   You cannot have a OOXML document and a ODF document sitting on the same disk without having them interfer with each other.  We just proved that with our tests of both ACME 374 and ODF Da Vinci plugin on the latest release of MSOffice Word 2007.\n</span><br style\u003d\"color:rgb(0, 0, 153)\"><br style\u003d\"color:rgb(0, 0, 153)\"><span style\u003d\"color:rgb(0, 0, 153)\">OOXML clearly does interfere with the loading of an ODF file into MSWord 2007.  In prior versions of MSWord (98, 2000, XP, 2003

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

A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes".  Lots of comments, pro and con, as to whether or not the applications specific tags used so extensibvely by MOOXML are needed, or not.

Many argue that the application bound tags should have been fully described.  That every tag in the specification should also include the informaiton needed to implement it.  Agreed!  Otherwise, the specification does not qualify as a standard.  It's simply a vendor specific, and in this case highly proprietary and encumbered file format.

Others argue that the app bound tags are the only way for Microsoft to provide backwards compatibility with the billions of binary documents bound to MSOffice through proprieatry and secret binary file formats.  These people argue that embedding an application specific binary in the XML file format, instead of converting it to proper XML, is the only way to insure backwards compatibilty.  BS.  There is no technical reason not to convert it to proper XML.  But that would mean fully describing the binary objects, including the nature of their application dependency.  Something Microsoft is quite reluctant to do.

The truth of the matter is that if the binary object is to be part of a specification submitted to ISO for standards consideration, then it should be fully described, including how to implement it.  Otherwise, MOOXML is just a standard for one.  A standard for Micrsoft only since they are  the only ones with the secret blueprint as to how to implement these binary objects.

A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes". Lots of comments, pro and con

A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes". Lots of comments, pro and con

Rick Jellife weighs in on the OpenOffice ODF- MSOffice OpenXML interop embroglio. His take is to focus on Classes of Fidelity, providing us with a comparative table of fidelity categories. I wonder though if this über document processing approach is anywhere near consistent with the common sense meaning of interoperability to average end-users? IMHO, end-users interpret "interoperability" to mean that compliant applications can exchange documents without loss of information. "..... In my blog last year Is ODF the new RTF or the new .DOC? Can it be both? Do we need either? I raised the question of whether ODF would replace RTF or DOC. I think this issue has come back with a bang with the release of Office 2007 SP2, and I'd like to give another pointer to it for readers who missed it first time around.... "...... OASIS ODF TC has some kind of conformance and testing wing at work, but it is not at all clear that they will deliver anything in this kind of area. Without targetting these classes, ODF's breezy conformance requirements means that ODF conforment software can deliver vastly different kinds of fidelity, yet still accord to the letter of the law (and, indeed, to the spirit of the ODF spec, which allows so many holes) which will cause frustration all-around....." Ouch!

What Web business systems really need are advanced desktop editors capable of producing business process rich compound documents in the language of the Web: HTML5/CSS3/JavaScript........

How Does Word Web App Get Better With Silverlight? Faster load performance, since typically fewer bytes need to be downloaded before showing the document. Improved text fidelity at 100% zoom. This includes better text spacing and rendering. Greatly improved text fidelity at other zoom levels not 100%. Text will respect settings set in cleartype tuner, so you're able to determine how much (if any) cleartype you'd like to see. The cleartype tuner is available on the web for older versions of Windows, and is included in Windows 7. Improved accuracy of hit highlighting in Find.