ODF on the web
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 <office:styles> and
<office:automatic-styles> 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.
One of the more important control points Sun insists on is that of commit rights and project managers. Only Sun employees have these rights and can hold these important positions..
The more important point is made by Marbux (below: ODF is an application specific format designed exactly for OpenOffice. While other applications might partially implement ODF, interoperability and successful ODF document exchange require the OOo code base!
From Marbux: This is the only article I've found to date where IBM (Heintzman) flat out says IBM wants changes in OOo licensing, more in line with the Eclipse and Apache licenses. See pg. 2. Significant because it feeds the meme that IBM's own ODF-based development goal is proprietary closed source built on the OOo code base, e.g., Symphony, et cet.
And that has huge signficance once you realize that ODF is not the real standard; the OOo code base is the real ODF standard. Look around the world and you see that ODF adoption decisions by governments are all in reality decisions to go with StarOffice, OOo, or OOo clones. I haven't, for example, seen a single instance where a government decided to ride with KOffice. Why would they, with the interop issues between KOffice and OOo? The fact that OOo's code base is the real ODF standard will figure strongly in the comments. Couple it with Sun's iron-fisted control of the OOo code base, and you have vendor lock-in with a Microsoft partner.
But with 70 developers committed in China, where developers salaries are inexpensive, IBM will soon be in a position to threaten to fork the OOo code base using proprietary extensions. Is that their real tactic to force changes in licensing and gov