What is Digg?Sponsored by Dragon Age: Origins
Can't get enough Dragon Age: Origins? Play the flash game. view!
DragonAgeJourneys.com - Play the free companion flash game to Dragon Age: Origins.
1 Comments
- garyedwards, on 10/12/2007, -0/+0Over the years Microsoft has perfected many ways to lock digital consumers into their Windows and MSOffice application platform. The forced march - upgrade treadmill Redmond has perfected is perhaps the most extraordinary profit machinery ever unleashed. The most innovative mesh of lockin schemes ever conceived. At the core of this machinery is the user digital dilemma of user owned information and information processes being bound to the Microsoft applications and platform services used to "work" that information.
When the OASIS Open Office XML file format, now known as ODF or OpenDocument, was first ratified as an international standard, many thought it was the beginning of the end for Redmond monopolist and the great treadmill machinery they had established. XML is after all the language of future Internet. It's the way data, content, and streaming media traverse the Web 2.0, with a surrounding galaxy of solutions and services from SaaS to SOA to desktop productivity environments, to backend transaction and information processing systems, to enterprise publication, content and archive management systems. The promise of XML is that of application and platform independent global transport, exchange, and crystal clean transformation. In this maw of emerging universal connectivity and collaborative computing solutions, the OpenDocument XML standard promised to merge the legacy of desktop productivity information and processes into the larger stream of Internet ready services and systems. The future looked good.
Microsoft however was not to be denied or left behind. The threat of the Internet to their monopolist enterprise was and is very real. First they stopped Netscape from establishing the ubiquitous cross platform browser as an Internet application platform. Then they stopped Java from becoming an Internet - enterprise systems application platform. It took a few years, much litigation, some time served, but finally Microsoft is ready to make their run at the many Internet interlopers who dare challenge their empire. Brace yourselves for a whole new era of massive lockin. A stack based lockin machinery that, if successful, will bind business processes to the Vista stack of desktop, server and device systems for years to come.
Matt Asay's article is one of the first to signal the alarm and describe the early parameters of what's at stake. He sights the rising dominance of the Microsoft SharePoint server, pointing out that behind it all is a new lockin strategy at work. One far more insidious and breathtaking in it's reach than anything ever imagined with binary file formats. File formats bind information to specific applications and platform services. SharePoint is designed to bind information processes to the Vista Stack.
At the heart of the Vista Stack is the recently approved MS – ECMA Open Office XML file format. Oooops. That's MS-ECMA Office Open XML file format, not to be confused with the OASIS Open Office XML file format now known as OpenDocument; ODF and EOOXML for short.
What Microsoft has done is to fully leverage their application control over the billions of legacy binary documents locked into the applications used to work this user owned content. EOOXML was written to provide backwards compatibility with the BoBs (billions of binary documents). In 2002, when asked why they didn't join the OASIS Open Office XML standardization effort, Microsoft responded that OpenDocument (then Open Office XML) was unable to handle the application specific vagaries of the BoBs. ODF was said by Redmond to be inadequate. And that was before the technical committee work on ODF even began.
Without Microsoft's participation, most felt it would be impossible for ODF to “accommodate” and fully reflect the application specific BoBs. After all, only Microsoft understood the years of arbitrary and treadmill accelerating changes to the binary file formats causing users to upgrade to ever new versions of MSOffice applications. The version madness we are all so familiar with. They, and they alone had the blueprint able to unlock the BoBs.
So Microsoft set out to develop a whole new generation of application/platform bound XML file formats. The Vista generation. OpenDocument was of course developed as an application and platform independent XML file format. Internal document dependencies are based on other open and internationally recognized XML standards (XHTML, CSS, XForms, SVG, SMiL, XSLT, etc.) MSXML and MS-ECMA OOXML on the other hand were developed in the great treadmill traditions of being bound to Microsoft applications and platforms, bound through a cascading entanglement of system specific and very proprietary dependencies. Nothing new to report here except that the documentation for this mash is over 6,000 pages.
The short description for EOOXML is that it's an XML wrapper of binary encodings unique to the legacy of Microsoft Office applications.
Still, many held out hope that with EOOXML, Microsoft would finally release the secret blueprint and fully document the conversion of BoBs to clean XML. With the EOOXML ratification and release in December of 2006, perfectly timed by the way to coincide with the release of Vista, MSOffice 2007, VSTO 2005, and a new version of the Exchange/SharePoint Hub, we can now see that this was anything but full disclosure and documentation. With EOOXML, Microsoft concedes nothing while leveraging the BoBs into a launch of a future lockin strategy that is breathtaking in scope and ambition.
Here's something interesting. We now know that EOOXML wraps the difficult to transform binary encodings of BoBs in exactly the same way as the OASIS Open Office XML Technical Committee described in February of 2003! In February of 2003, Phil Boutros, the legendary reverse engineer expert from Stellent, submitted to the technical committee the XML binary and processing instruction wrapping model affectionately known as the tags. To avoid any hint of application specific references, in the ODF specification (section 1.5) these tags are referred to as . Other casual references include and tags.
Another interesting point, courtesy of the inexhaustible Rob Weir, is that MSOffice 2007 has the unique ability to produce two kinds of EOOXML. I've never seen an application do this before, and one has to wonder why?
What Rob discovered is that if you import a legacy BoB into MSOffice 2007, the application will convert it to EOOXML fully preserving the originating application binary encodings – even doing so within laughably and descriptively colorful named XML tags. Fine. We can easily do that with ODF using the infamous tag model. No inadequacy to be found here. (Damn, if only we had patented that technique. Phil Boutros must be lapping this up :) One of the examples Rob pointed out is the use of the long since deprecated VRM encoding. Good work MSOffice 2007!
Next Rob re created that same legacy document “natively” in MSOffice 2007. Exactly the same! Saved it as EOOXML. Then examined the XML, comparing the two EOOXML files. Well well well. They are substantially different! Same application. Same file format. Same document content and presentation. Different EOOXML! Interestingly, for one thing there is no VRM encoding. It's been replaced by the proprietary application/platform dependent but forward Vista ready DrawingML.
Some will argue that this is the only way to preserve backward compatibility. I would argue that this will result in an information nightmare. Only one of the EOOXML files is backwards compatible. The other is ready for the Vista bound information processing chain centered on the Exchange/SharePoint Hub. How are organizations going to keep things straight?
IMHO, the better way of handling this backward compatibility dilemma is to write a plugin for the legacy applications. Let the plugin do the nasty dark work of conversions, and do so without disruption or confusion to end users. All the files should of course be converted to clean, open and highly transportable/transformable XML, and stored in that state. (uh, that would be ODF instead of EOOXML :) This is the optimal workflow and exchange “state”. Let the plugins do the application specific “user interface” only conversion back to the proper in-memory-binary-representation when needed.
So why did Microsoft choose this strange dual XML file format role for MSOffice 2007? Why not provide a useful binary EOOXML plugin for legacy applications instead of mashing up an XML file format specification with legacy application version specific madness?
IMHO, Matt is right. SharePoint is the future lockin point. The Vista Stack and Vista information processing chain model will probably convert without exception all those legacy specific EOOXML files to Vista specific EOOXML. You may not have to upgrade MSOffice 97, 98, 2000, or 2003 to MSOffice 2007, unless and until you find yourself participating in an Exchange/SharePoint Hub based process. So maybe this isn't a traditional force march to MSOffice 2007? Although it remains to be seen, this may in fact be a lockin and upgrade strategy designed to strongly encourage users to move from Win2k and XP to Vista. A move designed to demand both the desktop and server versions of Vista applications and systems.
For more information, try this web site: Office Business Applications Developer Portal, with special attention to this document: White Paper: Building Office Business Applications
Brace yourselves. It's game time.
~ge~
© Digg Inc. 2009
— Content created and posted by Digg users is