Group items tagged

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

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?

DOT chief technology officer Tim Schmidt DOT's CIO Daniel Mintz Federal Department of Transportation