Group items tagged

An eWEEK must read.  I think the recent aquisition is having a positive impact on the eWEEK journalist and reporters.   What a great series they've put together on SOA. SaaS and the Web 2.0

Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio

Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft.  As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life.  At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser.  It's 100% web ready, but only the MS Stack of applications gets to play.  Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice.  da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys.  It can achieve the same high fidelity "round trip" conversion that OOXML is capable of.  Maybe even better. 

The problem for da Vinci isn't conversion fidlelity.  Nor is it capturing  business process important VBa scripts, macros, OLE, and security settings.  da Vinci can do that just fine.  The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!!  For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF

Will the real universal document format please stand up! Comments on the recent article posted by the Universal Interoperability Council: "Putting Andy Updegrove to bed without his supper". The UIC article is well worth your time. It is extremely well referenced and researched. The arguments put forth counter claims by IBM and OASIS that the W3C's CDF format can not be used to represent desktop productivity environment documents. Not surprisingly, IBM and OASIS argue that the OpenOffice specific ODF is the only alternative to Microsoft Office specific OOXML. The UIC argues that the full range of MSOffice legacy binary documents and emerging XML documents can fully be represented in CDF - something that not even the most ardent of ODF jihadists would claim as an ODF capabilitiy. The truth is that ODF was not designed for the conversion of MSOffice binary and xml documents.

Since December 16th, 2002, or day one on the OASIS Open Office XML Technical Committee, now "ODF", the challenge has been to suceed in the marketplace as the best XML format for desktop productivity environments. Success was seen as a technical challenge. Could we make an XML format capable of universal interoperability? Capable of universal implementation across the domains of desktop, server, device and web platform usage?
All that changed in May of 2005, when ODF 1.0 was approved by OASIS and sent on it's way to ISO for consideration as an international standard. Following that approval, IBM led a swarm of large corporate vendors who invaded the cozy confines of serious universal docuemnt format work. No longer was the goal to perfect the most useful and lasting structured format the world had ever seen. The IBM led wave of corporate invaders seized on a new use of ODF - the use of ODF as a government mandate to rip out and replace MSOffice!
The politics of using standards to compete against Microsoft trumped the traditions of seeking market success through technical excellence.
Sadly, ODF would never recover from the anti trust veiled politics of IBM. The one thing ODF absolutely had to have to technically succeed is ability to convert legacy MS binary documents. Something it was never designed to do. Somethign that clearly is not in IBM's game plan.
As if the interoeprability problems of ODF wer not enough, IBM forged ahead with their interoeprability plan. Instead of movign interop to the forefront of ODF technical issues, IBM openned up an ODF Interoperability Sub Committee at the OASIS ODF Adoption TC. A group dedicated to the marketing and promotion of ODF.
Incredibly IBM sees ODF interop as a marketing issue, and not the technical challenge that continues to defy application implementation efforts.

Thanks for the insightful commentary Joe. I see things a bit differently. Maybe my tin foil hat is wearing a bit tight these days, but i see MSOffice XML (MOOXML and the MOOXML binary InfoSet) as a very important aspect of how Microsoft integrates and leverages their desktop office monopoly power into server side and device systems. It is the combination of MOOXML and .NET that creates the integration mesh between desktop, server systems, and devices. Imagine every application or service participating in either a loosely coupled or carefully crafted information processing chain, being fluent in MOOXML, and able to process internal data structures and processing instructions unique to .NET. Enterprise systems and services from ORACLE, IBM and SAP will not have this same integration fluency. The design of ISO MOOXML is such that it would be impossible for <b>non Microsoft server and device systems</b> to match the quality and depth of integration with the 500 million desktops running MSOffice bound business processes. Given that MOOXML will probably succeed at getting ISO/IEC approval, removing the last "legal" barrier for this MOOXML Stack, were looking at a massive migration of MSOffice bound workgroup - workflow business processes to a new lockin point; The Exchange/SharePoint Hub. With the real estate industry, this migration to to E/S hosted applications only took six months to completely replace years of desktop productivity shrinkware dominance. The leap in productivity was spectacular. The downside of this migration is that the real estate industry is now tied into Microsoft at the critically important business process level. A binding that will perhaps last through the next fifteen years.

Internet News is reporting that Ecma has submitted to the ISO/IEC JTC1 their repsonsess to the 20 "fast track" for Ecma 376 (OOXML) objections.  Nothing but blue skies and steady breeze at their back for our friends at Redmond, according to Ecma's rubber stamper in chief, Jan van den Beld.

Once again there is that ever present drum beat from Microsoft that ODF can't handle MSOffice and legacy MSOffice features - including but not mentioned the conversion to XML of those infamous billions of binary documents:
"Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address diffe

Excellent discussion of XML languages, how they are created, and what needs to be considered for a language to be successful

Excellent discussion of XML languages, how they are created, and what needs to be considered for a language to be successful

Excellent discussion of XML languages, how they are created, and what needs to be considered for a language to be successful

I doubt that MSOffice ODF will make a difference. ODF was not designed to be compatible with MSOffice, and conversion from native binary to ODF will result in a serious loss of fidelity and business process markup. If the many ODF pilots are an indication, the real killer is that application specific processing logic will be lost on conversion even if it is Microsoft doing the conversion to ODF. This logic is expressed as scripts, macros, OLE, data binding, media binding, add-on specifics, and security settings. These components are vital to existing business processes. Besides, Microsoft will support ISO 26300, which is not compatible with the many aspects of ODF 1.2 currently implemented by most ODF applications. The most difficult barrier to entry is that of MSOffice bound business processes so vital to workgroups and day-to-day business systems. Maybe the report is right in saying that day-to-day business routines become habit, but not understanding the true nature of these barriers is certain to cloud our way forward. We need to dig deeper, as demonstrated by the many ODF pilot studies.

"Clearly the Press Announcement today from Microsoft will bring about another wave of discourse on the future of document formats. " Jason Matusow presents the long-term view of the announcement's significance.

Quote: Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made. "We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents," Jon Bosak, a Sun representative to V1, wrote in an e-mail to other committee members over the weekend. "Sun voted No on Approval because it is our expert finding, based on the analysis so far accomplished in V1, that DIS 29500 as presently written is technically incapable of achieving those goals, not because we disagree with the goals or are opposed to an ISO Standard that would enable them." Sun "found itself in the unexpected position of stating its support for ratifying OOXML"?  What???? This is the official position of Sun?

For the near five years that i have been a member of the OASIS ODF TC, Sun has opposed

Great article series from eWeek.  A must read.  But it all comes down to interoperability across two stack models:  The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!

Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.

I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da".  Joe hit hard on the connection between OOXML and the Vista Stack.  He missed the implications this will have on MS SOA solutions.  Open Source SOA solutions will be locked out of the Vista Stack.  And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace.  Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions.  The only reason they've held back is that they need to first have all the Vista Stack pieces in place.

I don't think Microsoft is being held back by OOXML approval at ISO either.  ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement.  For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated. 

All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML.  The only question is, "Which XML?  OOXML, ODF or XHTML+".

The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process. <br

Now you're talking!

A mus tread.  Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO.  ODF is the main issue, with clark casting all his answers in the context of business decisions.  Carol o fcourse is asking the best questions of any journalist alive.

Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts.  They got access to all the eMail, documnetation, and conferencing notes concerning ODF  and Microsoft.  Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.

The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board.  Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML.  And that's the heart of any SOA strategy, "First, get everything into XML".

With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML. 

They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO. 

They now have their XML Hub in place; the Exchange4/SharePoint Hub.  This is also an essential part of any SOA strategy.  You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved.  The XML must also provide an end user interface to these information flows.  One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface.  The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, c

Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard.  MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007.  Just a bit over 60 days from today.

Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:

MS XML-PDF Scope: The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.   Programme of Work: Produce a formal standard for an XML-based electronic paper format and XML-based page description language which is consistent with existing implementations of the format called the XML Paper Specification,…[in each case, emphasis added]

If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh