Group items tagged

You have to read this!  Xandros is taking this interoperability garbage seriously!

Incredible comment by Marbux!  With one swipe he takes out both Ecma 376 and ODF. 

Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard.  ODF was approved by ISO nearly a year ago.

Criticizing Ecma 376 is easy.  It was designed to meet the needs of  a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms.  It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.

Criticizing ODF however is another matter entirely.  Marbux points to the extremely poor ODF interoperability record.  If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.

The "many vendor" aspect of OpenOffice is somewhat of a scam.  The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun.  Which is exactly the case with MSOffice.  With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!

The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory.   Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0.  All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.

Here are some thoughts i wou

This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata.  It's a treasure.

There is one problem with marbux's statement though.  We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC.   This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006.  Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.

The ODF iX enhancements were essential to saving ODF in Massachusetts.  Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.

For nearly a year we tried to push through some semblance of the needed iX enhancements.  We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.

Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition. 

Still rather than fork ODF, we are simply going to move on. 

On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.

In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.

Since then we've moved on to CDF, the W3C Compound Document format.  Incredibly, CDF is able to do what ODF can not.  With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere. 

The challenge for these g

Great coverage from InformationWeek about the emerging Enterprise 2.0 arena.  Author Michael Hoover does not get too deep into the Information Processing Chain, as exampled by the integrated Vista Stack of desktop, server, device,Internet systems and services.  But he provides a more than adequate framework for evaluating chain components.

As the ODF - OOXML battle contiues to expand, engulfing swallowing and swamping near everythign in it's path, the day is not too far off when the battle will move to the center of Enterprise 2.0 considerations.  It has to.  XML Hubs are how these converging technologies are going to be gathered, integrated and configured to impact rapidly changing business processes.  There has to be a universal transport in these systems that all applications can work, and nothig matches the highly portable and interactive document/data capabilities of ODF and OOXML.  They alone own the desktop prodcutivity environment migration to XML.  And it will be through XML - RDF/XML that the Hubs finally integrate the flow of information between desktops, servers, devices and Internet systems.

~ge~

Maybe the most informative article to date regarding the Microsoft-i4i "custom XML" patent infringement case.  Greg Keizer is trying to dig into the trial records and judicial response.  Looks like for Microsoft, it's business as usual. excerpt: Microsoft knew of the patent held by i4i as early as 2001, but instead set out to make the Canadian developer's software "obsolete" by adding a feature to Word, according to court documents.

The FAA issues their "NO ViSTA" mandate, hinting that it might be permanent if they can come up with MSOffice alternatives.  They are looking at Google Apps!

Okay, so plan B does have legs.  The recent failure of ISO/IEC to stand up to the recidivist reprobate from Redmond is having repercussions.  Who would have ever thought ISO would fold so quickly without ceremony?  One day there are 20 out of 30 JTCS1 national bodies (NB's) objecting to Micrsoft's proprietary XML proposal, the MOOX Ecma 376 specfication, and the next ISO is approving without comment the placing of MOOX into the ISO fast track where approval is near certain.  With fast track, the technical objections and contradictions are assumed to be the provence of Ecma, and not the JTCS1 experts group.

Apparently the USA Federal Government divisions had a plan B contingency for just such a case.  And why not?  Microsoft was able to purchase a presidential pardon for their illegal anti trust violations.  If they can do that, what's to stop them from purchasing an International Standard?  Piece of cake!

But Google Apps?  And i say that as one who uses Google Docs every day.

The problem of migrating away from MSOffice and MOOX to ODF or some other "open" XML portable file format is that there are two barriers one must cross.

The first barrier is that of converting the billions of MS binary docuemnts into ODF XML. 

The second is that of replacing the MSOffice bound business processes that drive critical day to day business operabions. 

Google Apps is fine for documents that benefit from collaborative computing activities.  But there is no way one can migrate MSOffice bound business processes - the workgroup-worflow documents to Google Apps.  For one thing Google Apps is unable to facillitate important issues like XForms.  Nor can they round trip an ODF document with the needed fidelity a

Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.

IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.

With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.

Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.

In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.

Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing doc

This the infamous Microsoft letter that many have misconstrued as an announcement of support for OpenDocument.  Only in a Microsoft universe can the statement, "We're not going to attack ODF" be taken as Micrsoft support for ODF.

Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


Andy puts it this way, "
  

And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe

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

The big thing I'm waiting for is other applications like OpenOffice to support custom defined schemas. This would mean that rather than simply sharing wordprocessing or spreadsheet information, we can share actual customer information. For example you c

The big thing I'm waiting for is other applications like OpenOffice to support custom defined schemas. This would mean that rather than simply sharing wordprocessing or spreadsheet information, we can share actual customer information. For example you c

The big thing I'm waiting for is other applications like OpenOffice to support custom defined schemas. This would mean that rather than simply sharing wordprocessing or spreadsheet information, we can share actual customer information. For example you c

Sam really nailsit with this satirical commentary on the spliny whiny letter Microsoft wrote begging the world to reconsider the proprietary application and platform bound Microsoft Office Open XML file format as an international standard for office productivity suites.

Operational  Transforms (OT) is used by Microsoft CustomXML and Google Wave!  The original idea was first presented by Zerox Parc researchers in 1995, prior to the i4i patent.  The Jupiter System  includes the Jupiter Window Tool Kit, wich is all about OT.  XML came much later with the i4i patent for encoding XML with OT positioning. Insert(pos, text)Delete(pos, num-of-chars) See Google Wave API: http://www.waveprotocol.org/whitepapers/operational-transform Credit Florian Reuter for this find!!!!! 

"Microsoft has attacked the UK government's decision to adopt ODF as its standard document format, saying it is "unclear" how UK citizens will benefit. The Cabinet Office announced its new policy yesterday, whereby Open Document Format (ODF) is immediately established as the standard for sharing documents across the public sector, with PDF and HTML also acceptable when viewing documents. SERGIGN - FOTOLIA The decision was a rejection of Microsoft's preference for Open XML (OOXML), the standard used by its Word software, which remains the dominant wordprocessor in government. "Microsoft notes the government's decision to restrict its support of the file formats it uses for sharing and collaboration to just ODF and HTML," said a spokesman for the software giant in a statement to Computer Weekly. "Microsoft believes it is unproven and unclear how UK citizens will benefit from the government's decision. We actively support a broad range of open standards, which is why, like Adobe has with the PDF file format, we now collaborate with many contributors to maintain the Open XML file format through independent and international standards bodies," it added"

"ODF - open document format - is an open, XML-based rich document format that has been adopted as the standard for exchanging information in documents (spreadsheets, charts, presentations and word processing documents), by many governments and other organisations (see, for example, here), including the UK Government. This is despite strong opposition by Microsoft; but I have seen Microsoft's proposed "open XML" standard and, frankly, it is huge and horrid (in the word of standards, these go together). If I remember correctly, the early draft I saw even incorporated recognition of early Excel leap-year bugs into the standard. ODF is now a pukka ISO standard, maintained by OASIS, under the proud banner: "The future is interoperability". My personal thoughts, below, are prompted by an ODF session at ApacheCon Core titled "Beyond OpenOffice: The State of the ODF Ecosystem" held by Louis Suárez-Potts (community strategist for Age of Peers, his own consultancy, and the Community Manager for OpenOffice.org, from 2000 to 2011), and attended by very few delegates - perhaps a sign of current level of interest in ODF within the Apache community. Nevertheless, and I am talking about the ODF standard here, not Apache Open Office (which is currently my office software of choice) or its Libre Office fork (which seems to be where the excitement, such as it is, is, for now), the standards battle, or one battle, has been won; we have a useful Open Document Format, standardised by a recognised and mature standards organisation, and even Microsoft Office supports it. That's good. So what could be the problem? Well, I don't care whether I use ODF from Open Office, Libre Office or even Office 365, I just want to be sure that everyone else can read my ODF documents (with a .odt, .ods or .odp extension, for text, presentation or spreadsheet, respectively), with whatever software they like; and that they'll either see exactly the functionality and formatting I see; or a well defined (an

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.