Group items tagged

This is the full response to Swapnil's seven questions.  It's long.  But we hold back nothing!  Thanks again to Marbux.  He is a peach!

This discussion is part of a much larger response to a series of questions from a LiNUX magazine in India.  The mighty Marbux helped answer the questions, so please don't mistake his eloquence for my customary thundering.

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

Check out the comments below this article.  There are links to Ian Foster of Globus and to the Marbux license disseration posted with the OpenDocument Foundation's NO VOTE at OASIS.

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.

This is a screen shot of the new business process interface for MSOffice 2007. Writing add-ons, scripts, and line of business integration apps was never so easy. This is also how Smart Document based metadate, data binding, services binding, and workflow binding can quickly be added to any document object. Very cool. The ODF alternative to the highly proprietary Smart Documents functionality is the open XForms implementation model and, the new Metadata RDF/XML RDFa enhancements. True to form, ODF has chosen to reuse existing W3C standards. Smart Documents is proprietary, and it is set to be a Lotus Notes "intelligent document" killer. It's also the way Microsoft will slam the door on Google search. The Smart Documents metadata model will provide Microsoft network share croppers with the kind of search, re-use and re-purpose tools Googlers only dream about.

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

Microsoft is closing off the exits!  MSOffice 2003 is the only application suite capable of producing Ecma 376 documents, and now it's getting EOL'd. 

The ISO vote on Ecma 376 isn't scheduled until September. 

Yoon Kit brings up an interesting point about the ISO consideration of MSOOXML (Ecma 376);  ISO approval of MSOOXML would backdoor a good many MS proprietary technologies that compete directly with W3C XML standards.

YK gives the example of MS VML, which competes with the W3C SVG standard used by ODF.  He could have also cited that legacy versions of MSOffice (98-2003) make use of VML as the default graphic format, while MSOffice 2003 9with XML plugin) and MSOffice 2007 (by default) implements DrawingML as the replacement for VML. 

So, would ISO approval of Ecma 376 backdoor VML and DrawingML in as "standards"?  Or MSOffice MathML?   One has to wonder since they are essential to MSOOXML.

The first post in the ZDNet series discussing the many deals Microsoft is cutting with prominent LiNUX vendors.  My point is that interoperability plays a prominent role in each of these deals, and, the deals also involve partners supporting Microsoft directed interop between OpenOfficeXML and OpenDocument.  Coincidence? 

I think not!

More in that same "LiNUX Leaders plot counter attack on Microsoft" thread at ZDNet.  This time the issue is what has caused IBM to sing a differnet tune?  The tune known as "harmoniation".

This is a follow up comment to a question cocerning my previous post, "commercialization of interoperability".  The question from "mosborne" is as follows:

A different viewI'm not on the ODF TC, but I have followed its evolution through the information publicly available at Oasis.

My outside view of some of the various interoperability discussions you mention is different than yours. I saw a resistance to adoption of features if the sole reason was because OOXML did it that way. The dissenting members wanted a more substantial reason, not simply to add OOXML "features" to ODF.

If the goal is to simply make ODF like OOXML, then what is the point? You would have conceded all control to Microsoft since they have effective control of OOXML.It's an interesting question, but not well informed.  The threads at OASIS ODF having to do with interoperability are focused on efforts to have our cake and eat it too. 

The List Enhancement Proposal thread played out over a six month period.  And yes, it is true that Sun fought the Novell proposal because they felt new and innovative features for OpenOffice/StarOffice were more important than the interoperability CIO's and IT departments are demanding.   But that misses the more important point that Novell was able to craft their interoperability proposal exactly so that the precious advanced feature sets of applications that command les sthan 1% marketshare would be accommodated.

What Sun and most others on the ODF TC don't get is that the markets have no use for these new and innovative feature sets unless and until they can transition their documents and business processes out of MSOffice.  If workgroup bound end users can't do that first, it won't matter how

The battle to break ODF away from being limited to only those features supported by Sun's OpenOffice/StarOffice continues.  This eMail thread sets the stage for the upcoming presentation of the metadata proposal to the ODF mainline TC.

SEction 1.4.3 of the metadata proposal is a list of existign ODF elements that developers can apply RDF to.  And the reason given fo rwhy the list is so constrained?  Svante Schubert, co-editor and Sun employee has claimed on more than a few occassions that the reason for limiting the lis tis that Sun will only support RDF on those particular ODF elements in OpenOffice/StarOffice.  Therefore, everyone is similarly limited!

I kid you not. 
~ge~

Eric Lai keesp pokign at that Massachusetts hornets nest. One of these days he's going to crack it open, and it will be back to square one for the ODF Community.  Still missing from his research is the infoamous 300 page pilot study and accompanying web site where comments and professional observations document a year long study concernign the difficulties of implementing ODF solutions and making the migration.  <br><br>

The study was focused on OpenOffice, StarOffice, Novell Office, and a IBM WorkPlace prototype.<br><br>

The results of the year long pilot have never seen the public light of day.  But ComputerWorld is one of the media orgs that successfully filed a court action to invoke the freedom of information act in Massachusetts.  How come they can't find the Pilot Study?<br><br>

At the end of the pilot study period, Massachusetts issued their infamous RFi; the request for information regarding the possiblity of a ODF plugin for MSOffice!  Meaning, the Pilot Study did not go well for the heroes of ODF - OpenOffice, StarOffice, Novell Office and WorkPlace.  Instead, Massachusetts sought an ODF plugin that would no doubt extend the life of MSOffice for years to come.  No rip out and replace here folks!<br><br>

~ge~

Public posturing in overdrive.  Warp speed overdrive. 

The "Backwards Compatibility" issue is all the rage at ISO, with the September vote on MS OOXML just a month away.

Microsoft and Sun (We've Been Had!) are arguing that ISO should approve MS OOXML (Microsoft OfficeOpenXML) because OOXML offers a backwards compatibility with the legacy of existing billions of binary documents.

This oft sighted history of Microsoft's reprehensible business practices is worth citing once again before the nations of the world go down that treacherous path towards ratifying Microsoft's proprietary systems and products as international standards.