Group items tagged

The First Law of the Interent is that of interoperability. Interop ALWAYS comes first.
Interop trumps innovation!!!
This is why the Interent changes everything. Innovation takes place within the bounds of ineroperabiltiy. Vendors of course rely on innovation as the primary means of market differentiation. They would of course champion innovative features. Interop on the other hand is a leveling force.

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

For a Web 2.0 application, Buzzword is very slick.  It's more sophisticated and feature rich than Glide Writer, which is also written on Adobe Flex.  Glide however offers an incredible array of portable office 2.0 features.  It's the whole enchilada.  And, Glide runs on iPhone!

Another interesting plus for Glide is that Google uses Glide Presentations for their on line PowerPoint alternative.  Which is to say, Google is likely to purchase Glide while Adobe tries to build on Buzzword.

One of the disturbing things for me is that Buzzword uses a proprietary file format!  In the future they will provide conversion to ODF, but that will probably be based on the OpenOffice conversion engine.  Which everyone in the Web 2.0, Office 2.0, enterprise 2.0 space uses.  Including Google.

The thing is, the OpenOffice conversion engine lacks the conversion fidelity to crack into existing MSOffice bound business processes.

Because they can't crack into these existing MSOffice bound business processes, the entire Office 2.0 sector is at risk.  All it takes is a competing entry from Microsoft, and the entire sector will ge twiped out by the superior interoperability - integration advantage to the MSOffice - Outlook desktop that Microsoft owns and carefully guards.

Oh wait.  That just happened today with the announcement of MSOffice Live!  Suspiciously timed to take the oxygen out of Adobe's announcement too.

~ge~

Whoa, those government desktops add up quickly.  This Vista ban will immediately effect over 50,000 desktops, with tens of thousands more possibly impacted by the IE 7.0 ban.  The MS Exchange/SharePoint Hub juggernaut is based on IE 7.0, which is not available for Windows 2000 - MSOffice 2000 desktops.

Lack of Vista Stack compatibility with non Microsoft application is given as the reason for the ban.  But notice the "alternatives" to Vista mentioned; Novel SuSE and Apple Mac.  What kind of interop - compatibility do they offer?  My guess is ZERO!

The reality is that the DOT is trapped.  My advice would be stay exactly where they are, keeping the current MSOffice desktop installs running.  Then, install the Foundation's daVinci ODF plugin for MSOffice. 

This will insure that Windows OS and  MSOffice bound business processes can continue to function without disruption.  Win32 APi based applications like those mentioned in the article can continue.  Critical day to day business processes, workgroup and workflow related activities can continue without disruption or costly re engineering demanded by a cross platform port.

What daVinci doe sdo is move the iron triangle that binds Windows-MSOffice applications to business processes and documents, to an ODF footing.  Once on a ODF footing, the government can push forward with the same kind of workgroup - workflow - intelligent docuemnt - collaborative computing advnaces that the Vista Stack was designed to deliver.  Only this push will involve the highly competitive "the customer is sovereign" environment of ODF ready desktop, server, device and Web 2.0 systems.  End of Redmond lock-in.  End of the costly iron triangle and the force march upgrade treadmill that so enriches Microsoft.

So what's not to like?  We can do this.
~ge~

http://docs.google.com/View?docID=dghfk5w9_20d2x6rf&revi

The primary difference between ODF and MOOXML is that ODF was designed to be a universal file format.  MOOXML was designed to be an XML file format for MSOffice, the Win32 API, and the Vista Information Processing Chain API (.NET 3.0). 

ODF is application and platform independent.  MOOXML is application and platform specific.  It's bound to the Windows - Vista platform. 

Microsoft's Brian Jones recently got caugh tup in a argument with the heavily armed WMD ODF expert and combatant Sam Hiser (WMD=Words of Massive Destruction).  In their exchange, Brian got confused over this very important distinction between ODF and MOOXML.  ODF allows specific applications to place their configurations and requirements in a settings file that is separate from the content, presentation and metadata containers.  MOOXML on the other hand makes no distinction whatsoever between application specific (MSOffice only) configuration, settings, processsing instructions and systemm dependencies and the rest of the file format contents.  Application settings are bound to content, presentation, and schema containers.  So bound that Brian is seemingly unaware of what ODF has achieved.  Sam caught him by surprise, as did many others posting comments:

Brian Jones on MOOXML support for older versions of MSOffice:  Coments by Sam the WMD Man are below.

Marbux has done some heroic work here, using the GrokDoc Wiki.  The Title is "EOOXML Objections", and it's primary purpose is to help ISO National Body Memebers evaluate the 0ver 6,000 pages of the Microsoft - ECMA Office Open XML Specification for MSOffice. 

On January 5th, 2007, Microsoft officially submitted EOOXML to ISO under the fast track rules.  Before EOOXML can hit the fast track though, ISO provides members with a 30 day "Contradition Review Phase".   During this brief phase, ISO NB's (national standards body members) muct evaluate the proposal and post their allegations concerning contradictions and inconsistencies with other ISO products - like ODF.

What Marbux is assembling here is a one stop shop for ISO NB's strugglign to understand the issues at stake.  It's incredible wha the has accomplished in such a short time.  But then, the clock is ticking.  February 5th is a hard and unmovable deadline. 

The basic contradiction is thatt EOOXML is a subset of ISO existing product, ODF.  Both attempt to do the exact same thing:  provide an XML file format for desktop productivity environments such as MSOffice, OpenOffice, and WordPerfect Office.  What seriously differentiates the two is that ODF was designed expressly to be a universal file format, application and platform independent, able to transition across many different information domains connecting the legacy of desktop productivity to near everything else.  MOOXML on the other hand was designed for MSOffice and the legacy of billions of binary documents that only Micrsoft knows the secrets to converting to XML.  As such, MOOXML is designed to be application and platform bound, with these proprietary dependencies written right into the specification.

One of the more important elements of the Marbux arguments is that the OpenDocument Foundation's daVinci Plugin and InfoSet Engine - API prove conclusively

"aimed at achieving an optimum degree of order .... and .... aimed at the promotion of optimum community benefits:. Uh, excuse me Mr. Robinson, tha tsecond part of your statement, the one concerning optimum community benefits - that would also disqualify ODF!! ODF was not designed to be compatible with the 550 million MSOffice desktops and their billions of binary docuemnts. Menaing, these 550 million users will suffer considerable loss of information if they try to convert their existing documents to ODF. It is also next to impossible for MSOffice applications to implement ODF as a fiel format due to this incompatbility. ODF was designed for OpenOffice, and directly reflects the way OpenOffice implements specific document structures. The problem areas involve large differences between how OpenOffice implments these structures and how MSOffice implements these same structures. The structures in question are lists, fields, tables, sections and page dynamics. It seems to me that "optimum community benefits" would include the conversion and exchange of docuemnts with some 550 million users!!!! And ODF was clearly not designed for that purpose!

I don't agree with this statement from Microsoft's Oliver Bell. As someone who served on the OASIS ODF Technical Committee from it's inception in November of 2002 through the next five years, i have to disagree. It's not that Microsoft wasn't welcome. They were. It's that the "welcome" came with some serious strings. Fo rMicrosoft to join OASIS would have meant strolling into the camp of their most erstwhile and determined competitors, and having to ammend an existing standard to accomodate the implementation needs of MSOffice. There is simply no way for the layout differences between OpenOffice and MSOffice to be negotiated short of putting both methodologies into the spec. Meaning, the spec would provide two ways of implementing lists, tables, fields, sections and page dynamics. A true welcome would have been for ODF to have been written to accomodate these diferences. Rather than writing ODF to meet the implementation model used by OepnOffice, it would have been infinitely better to wrtite ODF as a totally application independent file format using generic docuemnt structures tha tcould be adapted by any application. It turns out that this is exactly the way the W3C goes about the business of writing their fiel format specifications (HTML, XHTML, CSS, XFORMS, and CDF). The results are highly interoperable formats that any applciation can implement.

You can harmonize an application specific format with a generic, applicaiton independent format. But you can't harmonize two application specific formats!!!!
The easy way to solve the document exchange problem is to leave the legacy applications alone, and work on the conversion of OOXML and ODF docuemnts to a single, application independent generic format. The best candidate for this role is that of the W3C's CDF.
CDF is a desription of how to combine existing W3C format standards into a single container. It is meant to succeed HTML on the Web, but has been designed as a universal file format.
The most exciting combination is that of XHTML 2.0 and CSS in that it is capable of handling the complete range of desktop productivity office suite documents. Even though it's slightly outside the W3C reach, the most popular CDF compound is that of XHTML, CSS and JavaScript. A combination otherwise known as "AJAX".

This is the report John Cody worked on.  I spent four months answering his questions but was unable to adequately explain to him the difference between an "Office Suite" and a workgroup-workflow centric "Productivity Environment".   John insists that it's entirely possible to rip-out-and-replace the MSOffice editors with the free OpenOffice Suite without disrupting important workflows and business processes.  I explained to him what happened in Massachussetts, including the 300 page pilot study report Sam wrote.  What he needs to do i think is pay close attention to the Burton Group coverage of what is now known as the SharePoint Foundation platform;  SharePoint 2010 having totally swallowed the MSOffice 2010, leaving the venerable desktop productivity office suite as an important end user interface into information rich business systems centered on the SharePoint "Unified Productivity" platform.

This is amazing stuff. With all the talk about OpenOffice ODF compatibility problems with existing MSOffice productivity environments and documents, this comparison is stunning. I stumbled across this Compatibility Comparison reading this article: ThinkFree Set to Launch The First Complete Android Office Suite. Documents To Go is currently the only provider of Word and Excel documents on Android. The ThinkFree Office comparisons to OpenOffice cover a number of familiar compatibility issues, with layout at the top of the list. ThinkFree Write 3.5 vs OpenOffice Writer 3.0 ".....When using a word processor to create documents, you really shouldn't have to worry about whether your client will be able to see the document as you intended." ".... However, if you use a low-cost solution like OpenOffice, you should be prepared for frustrations and disappointments....."

A mus tread.  Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO.  ODF is the main issue, with clark casting all his answers in the context of business decisions.  Carol o fcourse is asking the best questions of any journalist alive.

Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts.  They got access to all the eMail, documnetation, and conferencing notes concerning ODF  and Microsoft.  Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.

The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board.  Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML.  And that's the heart of any SOA strategy, "First, get everything into XML".

With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML. 

They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO. 

They now have their XML Hub in place; the Exchange4/SharePoint Hub.  This is also an essential part of any SOA strategy.  You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved.  The XML must also provide an end user interface to these information flows.  One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface.  The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, c

Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.

Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.

This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.

In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.

It's a devastating argument.

Will ISO follow either the AFNOR or Brittish proposals to merge ODF and OOXML? I think so. If they continue on their current path of big vendor sponsored document wars, ISO will beocme irrelevant. Sooner or later the ISO National Bodies must take back the standards process from corporate corruption and influence. One thing is clear. Neither Microsoft or IBM is about to compromise. IBM has had many chances to improve ODF's interoperability with Microsoft Office and the Office documents, but has been steadfast in their stubborn refusal to concede an inch. Microsoft hides behind their legacy installed base of over 550 million MSOffice desktops. There simply isn't a pragmatic or cost effective way of transitioning the installed base to ODF without either seriously re writing and replacing those applications, or, changing ODF to be compatible. The marketplace is clear on what they intend on doing. Pragmatism will rule. Productivity trumps standards initiatives whenever they are out of sink. In the face of this clear marketplace intent, one would think IBM might compromise on ODF. No way! They are intent on using ODF to force a market wide rip out and replace of MSOffice. Most people assume that there are two opposing groups at war here; the Microsoft OOXML group vs. the IBM ODF group. This isn't an accurate view at all. There is a third, middle group of developers working the treacherous space of conversion - the no man'sland between OOXML MSOffice and ODF OpenOffice. The conversion group know the problems involved, and are actually trying to dliver marketplace facing solutions. The vendors of course are in this war to the bitter end, and could care less about the damage they cause to end users. It's also true that the conversion group seeks to bridge desktop productivity into the larger, highly interoeprable web platform. It's also possible that ISO will chose to merge

If there were any doubts left as to how far along Microsoft is in their efforts to create a proprietary version of the Web for Office Productivity and Business Systems, the recent SharePoint Conference should put these doubts to rest.   excerpt:  InfoPath 2010 and InfoPath Forms Services ....... Forms capability in Office and SharePoint is maturing rapidly. With the inclusion of BCS in SharePoint 2010 and Office 2010, InfoPath becomes even more powerful as a tool for aggregating, presenting and gathering information. Why? - People are now discovering how easy it is to bind BCS entities to a SharePoint list, and then present that list data to users in a rich InfoPath form. Because InfoPath does a great job of making complex data interaction simple for end users, it is becoming a critical component of LOB solutions managed in the SharePoint environment. Surfacing InfoPath solutions via the browser, InfoPath mobile forms, through Outlook, SharePoint Workspace or other interfaces makes the rich InfoPath experience portable and flexible. People on the floor certainly responded positively; InfoPath was a smashing success. Visit the InfoPath team blog to read about some of the solutions they were previewing. Below is an excerpt from the post:

Good article from Aaron Ricadela. The focus is on Java, Sun's hardware-Server business, and Oracle's business objectives. No mention of OpenOffice or ODf though. There is however an interesting quote from IBM regarding the battle between Java and Microsoft .NET. Also, no mention of a OpenOffice-Java Foundation that would truly open source these technologies.

When we were involved with the Massachusetts Pilot Study and ODF Plug-in proposals, IBM and Oracle lead the effort to open source the da Vinci plug-in. They put together a group of vendors known as "the benefactors", with the objective of completing work on da Vinci while forming a patent pool - open source foundation for all OpenOffice and da Vinci source. This idea was based on the Eclipse model.

One of the more interesting ideas coming out of the IBM-Oracle led "benefactors", was the idea of breaking OpenOffice into components that could then be re-purposed by the Eclipse community of developers. The da Vinci plug-in was to be the integration bridge between Eclipse and the Microsoft Office productivity environment. Very cool. And no doubt IBM and Oracle were in synch on this in 2006. The problem was that they couldn't convince Sun to go along with the plan.

Sun of course owned both Java and OpenOffice, and thought they could build a better ODF plug-in for OpenOffice (and own that too). A year later, Sun actually did produce an ODF plug-in for MSOffice. It was sent to Massachusetts on July 3rd, 2007, and tested against the same set of 150 critical documents da Vinci had to successfully convert without breaking. The next day, July 4th, Massachusetts announced their decision that they would approve the use of both ODF and OOXML! The much hoped for exclusive ODF requirement failed in Massachusetts exactly because Sun insisted on their way or the highway.

Let's hope Oracle can right the ship and get OpenOffice-ODF-Java back on track.

"......To gain

Yesterday Google announced dramatic price reductions for their Cloud Computing platform. This announcement was followed immediately by a similar announcement from Amazon. But what about Microsoft? The truth is that Microsoft doesn't need to reduce prices, and they are forcing both Google and Amazon reductions. My guess is that there are more reductions to come too. The answer is in this review of SharePoint OnLine and Office 365, where the author points out the fact that Google Drive / Apps totally mangles an MSOffice document. Once Google converts the documents, they are useless. "I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format. And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space." In 2006-2007, when we were in the middle of the great ODF vs OOXML document wars, I had a conversation with Google's Open Source - Opoen Standards guru, Chris DiBona. It was during the Massachusetts crisis, and we were trying to garner Google Corporate support for ODF. Chris listened to my pitch and summarized his position that conversion methods were very advanced, and going forward, file formats really didn't matter. He famously said, "Let a thousand formats bloom". I wonder if he still thinks that?

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!

Homepage for EIOffice, a complete JAVA clone of MSOffice.  This stuff is excellent!  Easily surpasses OpenOffice in terms of file format conversion and compatibilitiy.  EIOffice is fully capable of "round tripping" documents with MSOffice users without compromising fideltiy.  Supports UOF but not ODF or MOOXML

Quote: Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made. "We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents," Jon Bosak, a Sun representative to V1, wrote in an e-mail to other committee members over the weekend. "Sun voted No on Approval because it is our expert finding, based on the analysis so far accomplished in V1, that DIS 29500 as presently written is technically incapable of achieving those goals, not because we disagree with the goals or are opposed to an ISO Standard that would enable them." Sun "found itself in the unexpected position of stating its support for ratifying OOXML"?  What???? This is the official position of Sun?

For the near five years that i have been a member of the OASIS ODF TC, Sun has opposed

Eventually i suspect the truth will come out concerning ODF and the events in Massachusetts.  Migration is difficult and our friends in Redmond are not about to lend a hand.  The problem is the starting point, the MSOffice desktop productivity environment.  A starting point owned and controlled entirely by Microsoft.  The challenge is to get from the overwhelming dominance of proprietary Microsoft binary documents and into an open XML universal file format that any application, running on any platform can interactively read, render and write to.

Microsoft has decided to keep secret the blueprint to these billions of binary documents, reserving exclusively for themselves the right to convert then to XML.  Of course, the only version of XML Microsoft will convert them to is the wholly owned and controlled OOXML file format. 

Microsoft refuses to cooperate in any way with the conversion of these legacy binary documents to the only truly open XML universal file format, OASIS OpenDocument.  Which leaves the world with a near insolvable problem; how to get from where we are today, with the boot of a ruthless monopolist on the neck of our information and information processes, to where we really desire to be -  with our digital civilization in the hands of open standards, and out of the control of proprietary applications and platform vendors.

This document describes what the OpenDocument Foundation learned in Massachusetts about the challenge of migrating to ODF.