Group items tagged

This is certainly a big win for IBM hardware and Services.   I wonder how IONA plans to compete against IBM when IBM hardware and services can combine a one tow enterprise punch usign IONA open source efforts?

I hope the IONA guys know what they're doing.  Or this could get ughly.

1

A big 1

Uh, the diffusion we really should be focused on involves the OOXML plug-in for MSOffice, IE 7.0, MSOffice 2007, and the Exchange/SharePoint Hub. 

The Exchange/SahrePoint juggernaught is now at 65% marketshare, with Apache servers in noticeable decline.

So it seems the improtant "diffusion" is going forward nicely.  The exploitation of the E/S Hub has also started, and here the Microsoft deelopers have an uncahllenged advantage.  Most of the business processes being migrated to the E/S Hub are coming off the MSOffice bound desktop.  Outsiders to the MS Stack do not have the requisite access to the internals that drive these MSOffice bound business processes, so they have little hope of getting into the "exploitation" cycle.

This aspect was on full display at the recent Office 2.0 Conference in San Francisco.  The only way a O2 provider can position their service as a collaborative addon to existing business processes is to have some higher level of interop-integration into those processes beyond basic conversion to HTML.

Most O2 operatives struggle to convince the market that an existing business process can be enhanced by stepping outside the process and putting the collaboration value elsewhere.  While this approach is disruptive and unfriendly, it tends to work until a more integrated, more interoperable coolaboration value becomes available.

And that's the problem with O2.  Everyone is excited over the new collaboration possibilities, but the money is with the integration of collaborative computing into existing business processes.  This is a near impossible barrier for non Microsoft shops and would be competitors.  If you're Microsoft though, and you control existing formats, applications and processes, the collaboration stuff is simple value added on.  It's all low hanging fruit that Microsoft can get paid to deliver while O2 players struggle to f

What is he talking about? Does a developer write to Vista? Or do they write to MS Stack ready .NET - OOXML-Smart Documents, XAML, Silverlight stuff?

The announcement of the new API for others to use for plug-ins is not new news. It was originally made when Microsoft claimed to have gotten religion on interoperability a few months ago. The wookie is that the only conceivable reason for a new API for use by others is that Microsoft does not want to disclose the specs for its existing API. That in turn suggests that the API for use by others will have functionality different from the API used by Microsoft itself, almost certainly far less.

A "touch limited in scope"? Youv'e got to be kidding. ODF was not defined to be compatible with the billions of MSOffice binary (BIN) documents. Nor was it designed to further interoperability with MSOffice.
Given that there are over 550 million MSOffice desktops, representing upwards of 95% of all desktop productivity environments, this discrepancy of design would seem to be a bit more than a touch limited in scope!
Many would claim that this limitation was due to to factors: first that Microsoft refused to join the OASIS ODF TC, which would have resulted in an expanded ODF designed to meet the interoperability needs of the great herd of 550 million users; and second, that Microsoft refused to release the secret binary blueprints.
Since it turns out that both IBM and Sun have had access to the secret binary blueprints since early 2006, and in the two years since have done nothing to imptove ODF interop and conversion fidelity, this second claim doesn't seem to hold much water.
The first claim that Microsoft didn't participate in the OASIS ODF process is a bit more interesting. If you go back to the first OASIS ODF Technical Committee meeting, December 16th, 2002, you'll find that there was a proposal to ammend the proposed charter to include the statemnt that ODF (then known as Open Office XML) be compatible with existing file formats, including those of MSOffice. The "MSOffice" reference was of course not included because ODF sought to be application, platform and vendor independent. But make no mistake, the discussion that day in 2002 was about compatibility and the conversion of the legacy BIN's into ODF.
The proposal to ammend the charter was tabled. Sun objected, claiming that people would interpret the statement as a direct reference to the BIN's, clouding the charter's purpose of application, platform and vendor independence. They proposed that the charter ammendment b

Will harmonization work? I don't think so. The problem is that the DIN group is trying to harmonize two application specific formats. OpenOffice has one way of implementing basic document structures, and MSOffice another. These differences are directly reflected in the related formats, ODF and OOXML. Any attempts to harmonize ODF and OOXML will require that the applications, OpenOffice and MSOffice, be harmonized! There is no other way of doing this unless the harmonized spec has two different methods for implementing basic structures like lists, tables, fields, sections and page dynamics. Not to mention the problems of feature disparities. If the harmonized spec has two different implementation models for basic structures, interoeprability will suffer enormously. And interoperability is after all the prupose of the standardization effort. That brings us to a difficult compromise. Should OpenOffice compromise it's "innovative" features and methods in favor of greater interoperability with MSOffice and billions of binary documents? Let me see, 100 million OpenOffice installs vs. 550 MSOffice installs bound to workgroup-workflow business processes - many of which are critical to day to day business operations? Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice innovation! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset. Events in Massachusetts prove otherwise! On July 2nd, 2007, Sun delivered to Massachusetts the final version of their ODF plug-in for MSOffice. That night, after reviewing and testing the 135 critical documents, Massachusetts made a major change to their ETRM web site. They ammended the ETRM to fully recognize OOXML as an acceptable format standard going forward. The Massachusetts decision to overturn th

Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!" This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications. Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format. Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not. Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF. ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity. The three under specified areas of ODF are: Lists (numbered), F

Another big endorsement for the W3C's CDF as the universal file format!

Then why is Microsoft dragging us through this standardization nonsense? Is this nothing more than thinly veiled assault on open standards in general?

The battle between OOXML and ODF is very much about two groups of big vendor alliances. Interestingly, both groups seek to limit ODF interoperability, but for different reasons.

See: The Plot To Limit ODF Interop