- About Us
XHTML + CSS is the base. Add XForms, SVG and SMiL where needed. Study the work being done on microformats. Like most modern portable XML file formats, the basic packages are those of content and presentation. In CDF speak, this is XHTML content and CSS as the portable presentation package. ODF and MS-OOXML both struggle with the legacy tradition of the presentation package being application specific. Meaning, the portability is limited to other applications that are either of the same version, or, share the same layout and rendering model so that the exchange of the presentation package is lossless.
Document processing experts like a clean separation of content and presentation because they expect each application to preserve content but replace presentation. Think of sending desktop office suite documents to an enterprise publication, content and archive management system. In most cases a pre written template must be used at the desktop level to facilitate the exchange. In a document processing experts ideal world, they would prefer to skip the application specific template management, focus on the end user expertise with content (not presentation), and simply re purpose that content at the enterprise level.
End users on the other hand are always chomping on the controls, wanting to have more say in the larger document exchange process. They expect preservation of both content and presentation, across many application exchanges, with presentation approaching PDF like qualiity. And so it goes.
As a backdrop to these discussions, there is the movement of everything to the web platform. Instead of the traditional application to application problem, we now have to consider the desktop-device-web application to web platform issue. This is where CDF shines.
Imagine the question being framed in terms of converting desktop office suite ODF to CDF versus converting MSOffice MS-OOXML to CDF. Meaning, which one is web platform ready?
IBM, the W3C, and the OASIS Lawyer now argue that CDF was never designed for this role. That it is impossible to do. They are the experts. They must be right.
Microsoft on the other hand has no intention whatsoever of implementing a web platform solution based on W3C technologies. MS-OOXML was designed exactly to work across the desktop, server, device and web platforms. The MS Stack of applications includes MSOffice at the desktop, the Exchange/SharePoint Hub, the IE browser, with MS Dynamics, MS Live, MS Office Communication Server, MS SQL Server, Silverlight, etc. In fact, the MS Stack flows wherever .NET Foundations Libraries are used.
MS-OOXML is a MS Stack solution negating the need to ever consider a W3C technology such as CDF, HTML, XHTML, XForms, SVG, RDF, etc. Nor do they need PDF. The swarm of MS-OOXML - Smart Tags - XPS -XAML combinations is fundamental to those .NET Foundation Libraries. Meaning, there is no need for W3C technologies.
Given the recent statements by IBM, the W3C and the OASIS lawyer, even if Microsoft was pressured to use CDF as a container of compliant W3C technologies, they can now argue that this file format framework was not designed to meet the needs of desktop office suite conversions.
This brings us to an interesting dilemma. On the one hand we have ODF leader Sun claiming that we need multiple file formats, and ISO should approve MS-OOXML because ODF was not designed to be compatible with MSOffice documents, applications and processes. And on the other hand we now have IBM, the W3C and the OASIS lawyer claiming that you can't use CDF for the resonant reasons that CDF was not designed to meet the conversion needs of desktop office suites. Hummmm.
That leaves 550 million MSOffice desktops wanting to migrate to XML, and fully embrace the collaborative web platform of the future with what? MS-OOXML! And MS-OOXML leads to one thing and one thing only. A web platform dominated by the proprietary MS Stack of MSOffice to MS-OOXML to Exchange/SharePoint and beyond.
One of the reasons i think the world struggles to understand the problems of coming up with an alternative to MS-OOXML and the emerging MS Stack, is that the file format issue is cover for the real problem. It's the perfect camouflage. If the only problem was that of having your information locked into a proprietary file format, the world would have gracefully moved to ODF years ago. The OpenOffice conversion process is more than good enough for that task. But that's not the core problem. The real barrier is that of MSOffice bound business processes. The binary file format is only one aspect of business process lock-in. The other challenge is that of a MSOffice developer platform binding created through years of line of business, VBa scritping and add-on development. How do you crack that?
One way to deal with this MSOffice bound workgroup-workflow business process challenge is seize upon the rare opportunity that came about as Microsoft started to migrate these MSOffice bound business processes to the Exchange/SharePoint developers hub. The transition of existing MSOffice documents, applications and processes to MS-OOXML has a purpose; to use the web platform as an end game strategy effectively extending the monopolist desktop marketshare to servers, devices and the web. The first stage of this leveraging is the transfer of MSOffice business processes to the Exchange/SharePoint Hub, where newly designed collaborative processes quickly replace the comparatively limited, inefficient and brittle desktop generations. The productivity rewards alone make this transition beyond valuable to end users.
Is it possible to intercept this transition of business processes, and re direct them to open source Exchange/SharePoint alternatives? I think so. But to pull this off one has to either neutralize and re purpose MSOffice with an in process conversion facility (an ODF or CDF plug-in clone of the MS-OOXML Compatibility Pack would be one approach, but only if these file formats could be specifically tailored and adapted for that purpose). Or, one could go the disruptive and costly rip out and replace of MSOffice route. A choice Munich has made that is now costing them over $3500 per desktop. Liberating but kind of costly.
Imagine though if you were able to intercept MSOffice business processes at the head point, and push them to open source Exchange/SharePoint alternatives where they could be re written with explosive collaborative value? The key here would be to neutralize the extreme advantage Exchange/SharePoint has over competitors - the advantage of document level integration into existing MSOffice bound business processes. Microsoft perfects this integration through the MS-OOXML Compatibility Pack plug-in. Using this, they control the migration of existing business processes by limiting the server side - collaborative computing choices end users have. It's not that there aren't open source alternatives to the Exchange/SharePoint hub. There are great alternatives out there. What they lack is interop with MSOffice at the business process level. And Microsoft is not about to make it easy by offering up that interop. Least ways not until the migration is complete, and new lock-in established. One that will last for years to come, stretching across a new monopolist empire of desktops,servers, devices and the web.
In the end, users will select the most pragmatic solution available. The real challenge is providing them with alternatives to the MS-OOXML Compatibility Pack plug-in and the certain migration of business processes to Exchange/SharePoint Hub and the MS Stack that goes with it.