Document Wars

Florian Reuter has published another video demonstrating his LibOPC work; this time with his LibOPC library running in WebKit.

Web - Browser based desktop productivity suite.  

excerpt: OffiSync offers a a plugin for Microsoft Office that serves as a bridge between Office and Google Docs. When it first launched, the app's primary feature was to save Office documents to your Google account. It's since integrated Google Image Serach into Office, and added support for Google Sites. The application allows you to do Office-to-Office collaboration, and you can also have users editing the same document from Google Docs' online interface. Changes aren't synced as you type in each character, but rather each time you hit the 'save' button. Offisync is offered under a freemium model, but recently tweaked its pricing to offer more free features. Jive's CEO Tony Zingale says that this is a game changing acquisition for Jive, which combines computing with social collaboration to offer fully-featured social networks for businesses. Its suite of applications help businesses collaborate on a variety of tasks, including holding discussions, communication, sharing documents, blogging, running polls, and social networking features and more. "With OffiSync, Jive has the opportunity to become the most widely adopted Social Business platform for over 600 million Microsoft users, giving them the ability to bring social to the way they work.

excerpt:  This could be Apple's new internet strategy that thrusts more of us into the next phase of what is now known as the Post-PC era. In my view, this breakthrough could be a game changer.   The Problem to Solve The recent proliferation of web browsers and computer networks has made it easy to display the same document on different computing platforms. However, inconsistencies in the way fonts are rendered across different computing platforms could cause the same document to be rendered differently for users of different computing platforms. More specifically, for a given font, the way in which metrics for various font features are interpreted, such as character height, width, leading and white space, can differ between computing platforms. These differences in interpretation could cause individual characters in a document to be rendered at different locations, which could ultimately cause the words in a document to be positioned differently between lines and pages on different computing platforms.   This inconsistent rendering could be a problem for people who are collaborating on a document. For example, if one collaborator points out an error on a specific line of a specific page, another collaborator viewing the same document on a different computing platform may have to first locate the error on a different line of a different page. Hence, what is needed is a technique for providing consistent rendering for documents across different computer systems and computing platforms. Apple's patent application describe a system that typesets and renders a document in a platform-independent manner. During operation, the system first obtains the document, wherein the document includes text content and associated style information including one or more fonts. The system also generates platform-independent font metrics for the one or more fonts, wherein the platform-independent font metrics include information that could be used to determine the positions of i

Now that's what i'm talking about!  Business documents published in an advanced Web Productivity RIA format.  Roambi Flow targets the iPAD with business reports based on SalesForce.com and other business productivity platforms hosting basic business intelligence and information.  Roambi packages the reports in the increasingly popular visually immersive webzine style similar to FlipBoard, Zite, TreeSaver, OnSwipe, Push Pop, Instapaper, Readability, Pulse, PressJack, TweetMag, Sports Illustrated and the NYTimes iOS editions.  Beautifully done.   My guess is that the underlying format is the visually rich and interactive HTML+ (HTML5-CSS3-JSON-JavaScript-Canvas/SVG). excerpt:  After revolutionizing the way companies can interact with their business data on the go with its Roambi app, San Diego-based startup Mellmo is now aiming to let you use that data to create gorgeous interactive reports and presentations with its new iPad app and publishing platform Roambi Flow. The move is the next step in Mellmo's plan to make business intelligence (BI) more accessible, and dare I say it, sexy. Mellmo's initial Roambi app integrates with existing BI systems, including Salesforce and SAP, letting business owners and executives easily make sense of their data with interactive charts, graphs and more. Now with Roambi Flow, that data can be used to create magazine-quality reports and presentations that can be shared more easily with any iPad user.

Interesting report from Forrester on Desktop Productivity.  It seems everyone is asking about alternatives to MSOffice, but coming away empty handed.  Sounds like everyone would like to drop MSOffice, but find the alternatives wanting.  IMHO, the Web based alternatives are long on collaboration but short on productivity.   Compound Documents, Reports and Forms are the fuel that powers legacy workgroup productivity environments.  Web Productivity platforms have a long way to go before they can provide effective, worker facing authoring systems capable of replacing binding and messaging internals such as OLE, ODBC, MAPI, ActiveX, COM and DCOM.   There also seems to be considerable confusion about the difference between Web based authoring alternatives to MSOffice, and Web based Productivity Platforms.  MSOffice is the authoring system for desktop/WorkGroup productivity environments.  But having this authoring system wouldn't mean much if not for the workgroup connectivity and exchange platform behind it that makes highly productive digital business processes and systems possible. Linked Data, messaging, collaboration, and connectivity API's and HTML+ (HTML5, CSS3, JSON, Canvas/SVG, JavaScript) are  showing up everywhere.  But they are not exclusive to Web based authoring systems.  Any desktop authoring system should be able to take advantage of the emerging productivity platform.   So what's the problem with OpenOffice, Symphony, Zoho and gDocs?  OOo and Symphony can't speak language of the Web; HTML+.  Browser based Zoho and gDocs lack the completeness of a Web productivity environment capable of hosting the business processes currently bound to the Windows WorkGroup productivity environment.  There is no indication that the experts at Forrester understand what should be obvious.   excerpt: According to a new Forrester Research report, IT orgs are still choosing Microsoft Office over its competitors.   Two factors appear to be stumbling bloc

Good review of Florian's work on the libOPC project!  Sadly i wrote a lengthy comment on this, but then made the mistake of sending it to Facebook where they clipped off 80% of what i had written.  Huge mistake on my part.  Facebook continues to piss me off in ever new and innovative ways.

Although you need Chrome for the new Google Docs pagination feature, the key here is that gDocs now supports the CSS3 pagination module!   excerpt: Today, we're doing another first for web browsers by adding a classic word processing feature-pagination, the ability to see visual pages on your screen. We're also using pagination and some of Chrome's capabilities to improve how printing works in Google Docs. Native Printing: Pagination also changes what's possible with printing in modern browsers. We've worked closely with the Chrome team to implement a recent web standard, CSS3, so we can support a feature called native printing. Before, if you wanted to print your document we'd need to first convert it into a PDF, which you would then need to open and print yourself. With native printing, you can print directly from your browser and the printed document will always exactly match what you see on your screen.

Classic argument about ODF vs OOXML.  Need to send Rick an explanation about how the da Vinci plug-in works.  It is entirely possible to capture everythign MSOffice editors do in ODF using namespace extensions compliant with ODF 1.1 standard.   What was impossible was to round-trip those MSOffice ODF documents to OpenOffice.org.  And as it turns out, replacing MSOffice/Windows on new workgroup desktops with OpenOffice/Linux was one of the primary objectives behind the Massachussetts effort to standardize on ODF.  They believed the hype that ODF was cross platform interoperable.  It wasn't then, and it still isn't five years later. As for capturing all the complexities and nuances of the very robust MSOffice productivity environment and authoring system?  Sure, ODf could easily be extended for that. What an incredible discussion!

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.

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

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.

ODF was created on the principles that interoperability and innovation were paramount, and that these are based on open standards. Not coincidentally, ODF's creation coincided with the growing support of open ICT architectures, which grew from the Web model where the standardization of HTML, an open, royalty-free standard, enabled the Web to be an open platform that enabled much innovation on top of it. The key was interoperability, or the ability of multiple parties to communicate electronically, without the need to all run the same application software or operating system. Also critical to the development of ODF was the introduction of OpenOffice.org, the open source office suite that first implemented the format, and the rise of XML as a widely supported foundational standard for describing structured data.

Like most people i've been looking for a clear statement from Oracle concerning the future of MySQL and OpenOffice.  Although the title is promising, this article is short on facts, long on speculation and actually raises more doubts than it answers questions.  Some of the "assumptions" made by the author, Samara Lynn, are incredible.  And apparently unfounded.  I'll highlight with diigo the hyperbole statements.  Maybe someone else has the answers?  And where was Phil Boutros? intro:  Although eclipsed by Apple's iPad announcement, Oracle announced yesterday its intentions with Sun products, now that the acquisition of Sun Microsystems is complete. The announcement, which was actually a planned webcast, reassured those worried over the fate of two open-source Sun products for small business: the database software, MySQL and the productivity suite, OpenOffice.org. The acquisition might make MySQL and OpenOffice.org even more competitive against costly Microsoft counterparts (SQL Server and Microsoft Office).

"Prepending "really" to "open standard" in context is simply preposterous. "