Document Wars

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.

The ripples from the European Commission v. Microsoft decision continue to flow. The catch, of course, is that the patent rights will almost certainly be subject to the Microsoft Open Specification Promise, a weasel-worded document that actually grants no rights. http://law.bepress.com/unswwps/flrps/art71/ But someone with some clout will push that issue sooner or later.

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.

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:

referred from http://identi.ca/notice/15194816

WebODF...   An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo.

At the height of the Document Wars, Doug Mahugh posted this year end, month to month, blow by blow list of blog assaults. I stumbled upon Doug's collection following up on a recent (December 20th, 2010) eMail comment from Karl.  Karl had been reading the infamous "Hypocrisy 101" blog written by Jesper Lundstocholm:  http://bit.ly/hgCVLV Recently i was researching cloud-computing, following the USA Federal Government dictate that cloud-computing initiatives should get top priority first-consideration for all government agency purchases.  The market is worth about $8 Billion, with Microsoft BPOS and Google Apps totally dominating contract decisions in the early going.  The loser looks to be IBM Lotus Notes since they seem to have held most of systems contracts. So what does this have to do with Hypocrisy 101? To stop Microsoft BPOS, IBM had to get a government mandate for ODF and NOT OOXML.  The reason is now clear.  Microsoft BPOS is dominating the early rounds of government cloud-computing contracts because BPOS is "compatible" with the legacy MSOffice desktop productivity environment.  Lotus symphony is not.  Nor is OpenOffice or any other ODF Office Suite.   This compatibility between BPOS and legacy MSOffice productivity environments means less disruption and re engineering of business process costs as governments make the generational shift from desktop "client/server" productivity to a Web productivity platform - otherwise known as "cloud-computing". IMHO, neither ODF or OOXML were designed for this cloud-computing :: Web productivity platform future.  The "Web" aspect of cloud-computing means that HTML-HTTP-JavaScript technologies will prevail in this new world of cloud-computing.  It's difficult, but not impossible, to convert ODF and OOXML to HTML+ (HTML5, CSS3, Canvas/SVG, JavaScript).  This broad difficulty means that cloud-computing does not have a highly compatible productivity authoring environment designed to meet the transition needs

Presentation Schedule for OpenDocuemnt PlugFest in Berlin, Germany.

Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!
And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.
Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.
For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.
Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!
So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!
This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.
It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this ro