Group items tagged

EU settlement will alter Microsoft's stance on interoperability By Kurt Mackie Dec 21, 2009 Microsoft provided more details about its settlement with the European Commission (EC), particularly with regard to interoperability agreements. In a blog post on Thursday, Dave Heiner, Microsoft's vice president and deputy general counsel, claimed that the company has pledged to implement a threefold approach to interoperability that EC Commissioner Neelie Kroes outlined in past speeches. Heiner summarized that approach: companies should disclose technical information, provide a remedy if the information is inadequate and charge equitable royalty rates for associated intellectual property. Kroes had also specifically called for companies to follow open standards as one of the best ways to achieve interoperability. However, Heiner omitted the word, "open," from his comment. He said that "products from different firms can work well together when they implement common, well-designed industry standards." Microsoft's interoperability pledge announced this week appears to continue ideas the company put forth in February 2008. At that time, the company announced broad interoperability principles as well as APIs for software developers working with Microsoft's mainline products, including Windows client and server operating systems, Exchange, Office and SharePoint, among others. Microsoft has been releasing documentation for that purpose, with "hundreds of Microsoft developers" devoted to the effort, according to Heiner. The new elements to Microsoft's interoperability pledge appear to be warranty and patent-sharing templates. Those documents, and more, can be accessed at the end of a statement about the settlement by Brad Smith, Microsoft's senior vice president and general counsel.

While the candidate Media Queries specification is interesting and a small step in the right direction, W3C continues to butcher the meaning of "interoperability." In this latest sleight of hand, we now have "interoperable" *user agents*, a term of art used by W3C for implementations that only receive and cannot return data, e.g., web browsers. But under competition law, "interoperability" requires implementations that can exchange data and *mutually* use data that has been exchanged. See e.g., European Commission v. Microsoft, European Community Court of First Instance (Grand Chamber Judgment of 17 September, 2007), para. 230, 374, 421, http://tinyurl.com/23md42c (rejecting Microsoft's argument that "interoperability" has a 1-way rather than 2-way meaning; "Directive 91/250 defines interoperability as 'the ability to exchange information and *mutually* to use the information which has been exchanged'") (emphasis added). W3C --- the World Wide Web Conspiracy --- continues down its rut of broadcasting information whilst denying the world the power to round-trip the data received. Incredibly, in its latest assault on the meaning of "interoperability", W3C no longer defines "conformance" but redefines the term "interoperability" as its substitute for "conformance." As though W3C could redefine the law?

The king of clicks returns!  No doubt there was a time when the mere mention of ODF and the now legendary XML "document" format wars with Microsoft could drive click counts into the statisphere.  Sorry to say though, those times are long gone. It's still a good story though.  Even if the fate of mankind and the future of the Internet no longer hinges on the outcome.  There is that question that continues defy answer; "Did Microsoft win or lose?"  So the mere announcement of supported formats in MSOffice XX is guaranteed to rev the clicks somewhat. Veteran ODF clickmeister SVN does make an interesting observation though: "The ironic thing is that, while this was as hotly debated am issue in the mid-2000s as are mobile patents and cloud implementation is today, this news was barely noticed. That's a mistake. Updegrove points out, "document interoperability and vendor neutrality matter more now than ever before as paper archives disappear and literally all of human knowledge is entrusted to electronic storage." He concluded, "Only if documents can be easily exchanged and reliably accessed on an ongoing basis will competition in the present be preserved, and the availability of knowledge down through the ages be assured. Without robust, universally adopted document formats, both of those goals will be impossible to attain." Updegrove's right of course. Don't believe me? Go into your office's archives and try to bring up documents your wrote in the 90s in WordPerfect or papers your staff created in the 80s with WordStar. If you don't want to lose your institutional memory, open document standards support is more important than ever. "....................................... Sorry but Updegrove is wrong.  Woefully wrong. The Web is the future.  Sure interoperability matters, but only as far as the Web and the future of Cloud Computing is concerned.  Sadly neither ODF or Open XML are Web ready.  The language of the Web is famously HTML, now HTML5+

Bingo!  Took five years, but finally someone gets it: excerpt:  Great question. After 10 years, OpenOffice hasn't had much traction in the enterprise - supported by under 10% of firms, and today it's facing more competition from online apps from Google and Zoho. I'm not counting OpenOffice completely out yet, however, since IBM has been making good progress on features with Symphony and Oracle is positioning OpenOffice for the web, desktop and mobile - a first. But barriers to OpenOffice and Web-based tools persist, and not just on a feature/function basis. Common barriers include: Third-party integration requirements. Some applications only work with Office. For example, one financial services firm I spoke with was forced to retain Office because its employees needed to work with Fiserv, a proprietary data center that is very Microsoft centric. "What was working pretty well was karate chopped." Another firm rolled out OpenOffice.org to 7,00 users and had to revert back 5,00 of them when they discovered one of the main apps they work with only supported Microsoft. User acceptance. Many firms say that they can overcome pretty much all of the technical issues but face challenges around user acceptance. One firm I spoke with went so far as to "customize" their OpenOffice solution with a Microsoft logo and told employees it was a version of Office. The implementation went smoothly. Others have said that they have met resistance from business users who didn't want Office taken off their desktop. Other strategies include providing OpenOffice to only new employees and to transition through attrition. But this can cause compatibility issues. Lack of seamless interoperability with Office. Just like third-party apps may only work with Office, many collaborative activities force use of particular versions of Office. Today's Web-based and OpenOffice solutions do not provide seamless round tripping between Office and their applications. Corel, with its

JUDGMENT OF THE COURT OF FIRST INSTANCE (Grand Chamber) 17 September 2007 (*) (Competition - Abuse of dominant position - Client PC operating systems - Work group server operating systems - Streaming media players - Decision finding infringements of Article 82 EC - Refusal of the dominant undertaking to supply and authorise the use of interoperability information - Supply by the dominant undertaking of its client PC operating system conditional on the simultaneous acquisition of its media player - Remedies - Appointment of an independent monitoring trustee - Fine - Determination of the amount - Proportionality) In Case T-201/04, Microsoft Corp., established in Redmond, Washington (United States), represented by J.-F. Bellis, lawyer, and I. Forrester QC,

Lengthy discussion about Cloud computing innovation and interoperability.  Lots of quotes.  Looks like the consulting space for cloud computing is exploding.  No mention though of the great transition from Desktop/WorkGroup Productivity to Cloud/Web Productivity Platforms.  Obviously we need more experts :) excerpt: As the hype over cloud computing evolves into a more substantive discussion, one thing has become clear -- customers do not want to be locked into a single cloud provider. They would like the freedom to move among the clouds -- ideally from public to private and back again. This would give customers the freedom to switch providers as their computing needs grow or shrink, and the ability to move applications and workloads around as their business requirements change.

Custom Document Format Interoperability You may have heard that Office 2007 SP2 will now support editing files in the OpenDocument 1.1 (ODF) format. This document format was added to Office's long list of supported documents formats to give customers more choices for the format they use to save their documents. In addition to allowing you to edit the ODF 1.1 format within Office 2007, SP2 also supports a new External File Format API that can be used to edit other document formats as well. With this API, users can choose to save their documents in any format they want. In this post we will explore how to use the API to enable Office 2007 to edit our own custom document format. We will then use Office 2007 to save our custom format as DOCX, ODT and HTML. Our Custom Document Format For the purpose of this article, we have a company who needs to manage their sales pipeline information. The data is available as XML, but they do not want to spend the money to build a custom editor. They just want to let their users edit the pipeline data in Word, as a table. They give these files an extension of SPLX (i.e. Sales PipeLine Xml) The sales pipeline information is made up of a series of SalesItem tags, each with a unique id that represents the index of the item. They track the name of the customer (CustomerName), how much the deal represents (DealValue) and a percent that represents how confident they are that the sales opportunity will close (ConfidencePercent).

wikiWORD and SPoint get the go ahead!

While trying to help a friend understand the issues involved with exchanging MSOffice documnets between the many different versions of MSOffice, I stumbled on this oldy but goody ......... "A group of software developers have created a program to make Microsoft Office work with files in the OpenDocument format, a move that would bridge currently incompatible desktop applications. Gary Edwards, an engineer involved in the open-source OpenOffice.org project and founder of the OpenDocument Foundation, on Thursday discussed the software plug-in on the Web site Groklaw. The new program, which has been under development for about year and finished initial testing last week, is designed to let Microsoft Office manipulate OpenDocument format (ODF) files, Edwards said. "The ODF Plugin installs on the file menu as a natural and transparent part of the 'open,' 'save,' and 'save as' sequences. As far as end users and other application add-ons are concerned, ODF Plugin renders ODF documents as if (they) were native to MS Office," according to Edwards. If the software, which is not yet available, works as described, it will be a significant twist to an ongoing contest between Microsoft and the backers of OpenDocument, a document format gaining more interest lately, particularly among governments. Microsoft will not natively support OpenDocument in Office 2007, which will come out later this year. Company executives have said that there is not sufficient demand and OpenDocument is less functional that its own Office formats. Having a third-party product to save OpenDocument files from Office could give OpenDocument-based products a bump in the marketplace, said Stephen O'Grady, a RedMonk analyst. OpenDocument is the native format for the OpenOffice open-source desktop productivity suite and is supported in others, including KOffice, Sun Microsystems' StarOffice and IBM's Workplace. "To the extent that you get people authoring documents in a format that is natively compatible with

Interesting chart describes the massive transition of small and medium sized businesses to the Cloud.  Cloud based eMail and messaging leads the way.  Top two reasons for the great transition?  Cost reduction and productivity improvement. Unfortunately this article fails to describe what this great transition to the Cloud means to legacy productivity systems - most of which are provided and provisioned by Microsoft.  What happens to desktop and workgroup based business systems when the local data and transaction processing server systems are moved to the Cloud?  How are desktop and workgroup systems re written or migrated? Another factor missing from this article is any discussion of what happens to productivity when communications, content and collaborative computing are interoperably entwined throughout the application layer?  We know that the legacy Windows productivity platform seriously lacked communications capabilities.  This fact greatly reduced expected productivity gains.   excerpt: Microsoft commissioned the study of 3,000 small and medium sized businesses in 13 countries. The survey was conducted by Wayland, Mass.-based research firm Edge Strategies. The most commonly used cloud services are email, instant messaging, voice communications, and backup. Edge also looked at SMB cloud plans over the next three years and the same cloud services also are in the IT plans of those embracing the cloud. From this data, it certainly could be argued that SMBs seem to be quick to embrace the cloud in order to enhance communication. It makes sense: in small business, communication is key to ensure rapid growth. The biggest motivators for migration to the cloud among SMBs is to save money (54 percent), followed by increases in productivity. Decision makers also mentioned flexibility as a fairly common response. Of those already using the cloud, 59 percent reported productivity increases as a result. SMB cloud adoption begins to acclerate, study finds http:/

Is Intel right?  Is there a "compatibility-interoperability" problem between Windows RT Office (ARM) and legacy (x86) Windows MS Office productivity environments?  It seems to me that the entire reason iPAD, Android and other ARM based tablet systems want MSOffice and MSOffice Visual Document Viewers is exactly because they want and expect a high level of compat-interop with legacy Windows productivity workgroups and client/server systems. What's the truth?  And is there anything x86 providers like Intel and AMD can do about compat-interop and the unstoppable cloud-mobility revolution? excerpt: The Asus tablet has a quad-core Tegra 3 processor from Nvidia. Windows RT comes preloaded with Office 15, a group of widely used productivity applications. Microsoft has said it had to re-engineer Windows RT to deal with expectations for ARM based devices, which include all-day connectivity and low power consumption. The tablet also has an 8-megapixel camera at the rear with LED flash, and a 2-megapixel camera at the front. It has 2GB of RAM, 32GB of storage, Wi-Fi and Bluetooth 4.0. Intel has already started the war of words against ARM around Windows 8, with Intel's CEO Paul Otellini saying that ARM devices will be incompatible with existing Windows applications and drivers. But analysts have said that Windows RT devices will likely be attractive to users who have few ties with legacy Windows PCs. Low prices could also attract users to Windows on ARM devices.

In this interview with Microsoft's Chris Capossela, he admits that OOXML is not an interoperable format - that using OOXML will result in a loss of productivity.   excerpt: "The collaboration experience end users are going to have with Office 2010 and the Web applications in the browser and Office on the phone is far superior to anything out there, whether it's from Google or anybody else. And the increase in costs to do what they're suggesting and the decrease in productivity that's going to result is something that customers will see, and then they'll choose Microsoft. The best example of that is just sharing a document. Just taking an Office document that was built in the rich client that has a piece of smart art and a watermark or a header or a footer, and then when I share that with you and you open it in the Office Web app, it looks absolutely identical to what I created. When you make edits to it and save it and I open it back up, I see exactly the edits you made and all the stuff I had in there originally. If you do that exact same thing with Google or Zoho or OpenOffice, you lose stuff. And that means loss of productivity."

This event speaks loudly to how little interest browser developershave in interoperable web solutions. One-way compatibility wins and the ability of web applications to round-trip data loses. For those that did not realize it, the Compound Document by Reference Framework not only allowes but requires that more featureful implementations round-trip the output of less featureful implementations without data loss. See http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance ("A conformant user agent of a superset profile specification must process subset profile content as if it were the superset profile content"). 

Comments from Sam Hiser, Gary Edwards and Paul Merrill.  Excellent review of the OOXML-ODF-CDF argument.  W3C CDF work was officially cancelled, July of 2010.  The long awaited "interoperability" version of ODF, known as ODF 1.2, was released to final consideration by the OASIS community in July of 2010.  That's about three years late.  Also, they did not fix the ordered list problem :)  ha ha ha.  Broken, impossible to fix with the OOo - KDE dual application approach.  Just like we said it would be.  Morons.

We can all learn a lot of lessons from the history of DDE/OLE/ OLE3/COM /ActiveX/DCOM /COM+ (you can start reading up on Wikipedia to get some background) and how we went from everyone using best-of-breed standalone apps to one integrated, nearly monolithic Office. It basically all started with copy and paste. People who never spent a lot of time in singletasking, character-mode operating environments like the DOS command line don't recall that simply copying-and-pasting information between apps was difficult at the time. And part of the revelation of Windows for mainstream users (or Mac, for leading-edge tech fans), was being able to easily share data in that way. This was different than what Unix users were used to with the command-line pipe, or from what most applications do with feeds today, in allowing structured information flows between applications. There's a desire to combine data from different sources in an arbitrary way, and to have the user interface display the appropriate tools for whatever context you're in. The dominant model here, probably because of the influence of the early PARC demos, is to have toolbars or UI widgets change depending on what kind of content you're manipulating. Microsoft was really into this in the early 90s with OLE2, where your Word toolbars would morph into Excel toolbars if you double-clicked on an embedded spreadsheet. It was ungainly and ugly and slow, especially if you had less than an exorbitant 8MB of RAM, but the idea was pretty cool. And it still is. People are so focused on data formats and feeds that they're ignoring consensus around UI interoperability. The Atom API and Metaweblog API give me a good-enough interface if I want to treat a discrete chunk of information (like a blog post) as an undifferentiated blob. But all the erstwhile spec work around microformats and structured blogging (I forget which one is for XML and which one's for XHTML) doesn't seem to have addressed user experience or editing behavior