PlexNex

Standards Push-Back in a Nutshell

FT's Richard Waters sums up the Microsoft ISO contradiction situation with a crisp economy on the FT Tech Blog...

...it is at the least inconvenient for Redmond, and potentially more worrying, that the International Standards Organisation has just added another three months to its review of the matter, following representations from the UK (and possibly other countries.)

A perceptive comment to the post gets right to the heart of the matter...

Given that MicroSoft needs the "standard" label to get contracts, but doesn't actually want interoperability (which would increase competition and drive down prices), it shouldn't come as a surprise that they're encountering resistance from the standards bodies. I would expect them to create the worst possible standard they can get away with. It's the rational thing to do, and the people who run Microsoft are very skilled.

- S. Dolgoff

Feel free to go on and comment.

Contradictions of the Compass

It was a week when much turned in the balance. The date, February 5th -- coming up about two weeks from now -- sets the end-point, the close of the contradiction period when ISO members hear from knowledgable sources if there are any problems with a certain standards submission currently on their desks. The public won't know until after Feb 5th whether the voting members of ISO in each country have actually voiced concerns within the body.

This week on Tuesday (23 Jan 2007) an influential document went live on Groklaw, "Deadline Looms to Express Concerns about ECMA 376 Office Open XML"; citizens will use this information to express concerns to their regional voting members at ISO. The document outlines in detail an extensive list of objections found by members of the ODF and software standards communities about the Microsoft Office Open XML specification work that was submitted to ISO last month (Dec 2006) for fast-track approval by Ecma International.

The article's length and depth of technical detail is a deterrent to its consumption by normal folks who haven't time in the Attention Economy to catch up on standards arcana. Allow me to provide a table of contents here that will make the document more accessible as well as summarize its basic points. ("Ecma 376" referrs to the Microsoft Office Open XML specification document, which can be found here.)

Introduction & Summary

Ecma 376 contradicts numerous international standards

Ecma 376 is immature & inconsistent

Ecma 376 uses bitmasks, inhibiting extensibility and use of standard XML tools

Ecma 376 relies on undisclosed information

Ecma 376 cannot be adequately evaluated within the 30-day evanluation period

Ecma 376 cannot be reasonably implemented by other vendors

Ecma 376's full name confuses the marketplace

Related Cases

Ecma 376 raises serious issues as to the Agreement on Technical Barriers to Trade

There is an eerie quiet as all the material supporting these points is digeted by people in every country. Even though February 5th is the close of the contradiction period, many of the meetings by country voting bodies have taken place this week. Communications & decisions are in process.

If ISO members concur that these issues & contradictions are meaningful, it will set Microsoft's process to standardize its document formats back in time because fast-track process will be denied and the company will need to address fundamental restructuring of either the formats or the manner in which it presents them to ISO.

There are a few constructive ideas we've seen that would permit Microsoft to adopt ODF and require the relevent office suite applications to cross-incorporate the necessary missing feature extensions. But Microsoft's headache would extend throughout its software product catalog to the many products in this important new generation which have been designed to use features in the Microsoft Office Open XML formats that are likely to be denied under close scrutiny by the standards bodies. Affected products would include Office, Windows Vista, Internet Explorer, Exchange, Sharepoint, Windows Server, SQL Server, MS Dynamics, VSTO and the many versions of each of these categories as well as others not mentioned.

The setback could be devastating to Microsoft's plans this year. New product launches will go forward, but major architectural alterations will be known to be required even before the first public purchases of products in the catalog.

All this depends upon ISO's disposition to the Ecma 376 formats.

Bub-Bye.

Microsoft's Philanderings & Contradictions

PJ at Groklaw airs out the reasons ISO voters are going to need to consider carefully this month their votes for fast-tracking the not-open Microsoft Office Open XML formats.

She quotes our colleague, Marbux...

JTC-1's role includes ensuring that such vendor favoritism does not creep into the preparation of international open standards. Agreement on Technical Barriers to Trade,supra, section 2.2 ("[m]embers shall ensure that technical regulations are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade"); ISO/IEC JTC-1 Directives, section 11.1.2 (members may may appeal JTC-1 action or inaction that is "[n]ot in the best interests of international trade and commerce"). A single vendor's development requirements do not necessarily create a market requirement for a duplicative standard, particularly when a proposed standard would have "the effect of" granting a single vendor a monopoly in the full-fidelity conversion of billions of legacy files to and from the supposedly open EOOXML.

There is a lot substance here, and very little common sense to support ratification of the Microsoft Office Open XML formats at ISO.

Pamela Jones | "Searching for Openness in Microsoft Office Open XML and Finding Contradictions" (18 Jan 2007)

Press Clips: Ecma

In last week's news about the Ecma vote to sign off and pass OOXML on for a year's (or two years') process at ISO, we'd like to separate the wheat from the chaff. Here are a few selective press clippings to highlight some of the subtler points...

Bob Sutor
IBM

Make sure you follow how well the Novell and Corel implementations do...If they falter, watch out for those who try to blame those companies or open source itself, when the root
of the problem may be with the Microsoft Office OpenXML spec in the first place.

Martin Veitch | IT Week (UK)

Simon Phipps
Sun Microsystems

Ecma is a coin-in-the-slot standards organisation...The OpenXML [submission] is 6,000 pages. Imagine what it takes to implement that specification.

Martin Veitch | IT Week (UK)

Sam Hiser
OpenDocument Foundation

The ECMA spec stacks up on a desk as high as your shoulder...It can cost $1,000 just to print it out.

W. David Gardner | InformationWeek

Microsoft's Alan Yates got to respond a day later to the ODF press blitz-krieg and had this to say...

Clearly OpenXML and ODF serve different requirements...ODF takes more of a Greenfields approach, while OpenXML takes more of a practical approach toward documenting compatibility and interoperability.

Peter Galli | eWEEK

What Mr Yates refers to as OpenXML's 'more-practical approach' follows the reality theme with which government & enterprise customers are very familiar. The reality is that Microsoft owns the document formats today, so we might as well lie down and accept the status quo for another 5 to 15 years, goes the resigned thinking of the CIO (nearing retirement).

Any one taking a sincere evaluation of the goals of ODF -- the universal & portable document format -- could easily draw the contrary conclusion: that ODF is the more practical approach.

Standards Smackdown!

Jeff Kaplan clears some confusion about the file format standards conflict, which is now going PrimeTime.

Ecma's approval of ooXML will increase confusion in the marketplace. Consumers and companies now face two different document standards. One is a proprietary-encumbered standard, the other an open standard. Both are endorsed by standards organizations and industry allies.

More -->

Novell's "Danaergeschenk"

Free Software Foundation Europe's George Greve writes a precise assessment on Groklaw of Novell's commitment to Microsoft's "interoperability." This takes place upon the eve of Ecma's rubber-stamping of the Microsoft XML format and its handoff to ISO and upon the eve of the announcement that Novell has inserted the Clever Age ODF translator into its patent-protected build of OpenOffice.org software.

From a naive stance, having two standards for documents may not seem so bad. But when considering that only ODF really is an Open Standard fully supported by multiple office applications and that the OpenXML format will be pushed with all the power of the dominant desktop vendor, it becomes obvious that accepting both ultimately means undoing the political efforts on Open Standards that have been undertaken in the past years.

Please! A Must-Read for CIOs, state gov't policy-makers and the File Format Cognoscenti.

George Greve | FSF Europe | Groklaw (8 Dec 2006)

IBM's Rob Weir Finds another Rusty Needle in the ECMA Hay Stack

In his recent post, "Cum Mortuis in Lingua Mortua," (With the Dead in a Dead Language) Rob asks, 'Is it better to reuse existing software standards or to use non-standards?' His careful reading of the Microsoft's 4,000-page ECMA spec reveals Microsoft's weird attempt to revive a dead standard, VML (Vector Markup Language) when SVG (Scalable Vector Graphics) -- an established W3C recommendation -- would leverage prior work and permit better resource allocation for the future.

There will undoubtedly be an engaging explanation coming from Microsoft as to why VML is superior to SVG. But it will fall on deaf ears.

Further reading of the ECMA spec will turn up examples in Microsoft's file format work which demonstrate that company's view that it is the only company qualified to make software and its surety that its customers are stupid. Stay tuned to An Antic Disposition.

IBM's Rob Weir Gets to the Point

Rob Weir's last three posts to his blog, each concerning his reading of Microsoft's file format activities, bear wide attention.

"A Game of Zendo"

Much is hidden. Because Microsoft legacy file format specs remain undocumented the ECMA spec, which claims "backward compatibility" as a goal and points into private documentation, cannot be verified to be faithfully compatible. We'll never know.

Rob asks, is this for the benefit of Office 2007 developers only? If so, it suggests that the MSECMAXML standardization process does not satisfy the requirements of a standard because it is not a collaborative process, driven by public consensus, but a consultative process that's been driven by legacy technology that's tied to single-vendor functionality.

"Lost in Transaltion"

Looking at spec documentation and performing file operations, Rob finds the ODF Translator project to be lacking some key ingredients in file conversion and having an underwhelming set of goals.

If Microsoft is "supporting" this project, why are the usual ODF dark-spots (bullets, numbered lists) still dark? It suggests that objectives for the Translator are low-fi. 

"Traduttore, Traditore (Translator, Traitor)"

Rob looks at the interface design of the suggested ODF Translator and finds that the format is not given fair billing. When using the Translator for which Microsoft claims "support", ODF a) cannot be made the default format; b) documents can not be round-tripped; c) documents are not accessible via the familiar keyboard shortcuts for opening and saving files (Control-O and Control-S); d) documents pay a performance penalty for having to be indirectly converted via Draft Office Open XML rather than via native support.

Close inspection indicates Microsoft's messaging does not match their plans & actions.

Microsoft Swallows Treadmill

Bob Sutor is comparing spec documents by page-count. MSECMAXML at the new version 1.3 weighs in at over 4,081 pages versus OpenDocument's 706 pages. It's significant because the MSECMAXML specification started last Fall at about 1,900 pages.

Now, that's actually a fair reckoning of how bas-ackwards the Microsoft's "community process" is for developing its "open" XML file format (which won't get through ISO, if ever, until late next year).

Says Sutor, in rare form:

"I compare this to going to the gym and working out to build muscle tone and bulk up a little bit. Conversely, weighing in at 4081 pages means you went to the gym and you swallowed a few treadmills."

Why does page-count matter? In this case, it reflects the sheer amount of features and the sheer number of ways the format is tied to application and operating system instructions, otherwise known as system calls, that are unique to Microsoft's stuff. The MSECMAXML format will not do the same things on other people's stuff, like with a multitude of competing applicaitons or, say, on Linux, for example.

This means that MSECMAXML breaks a few of the key definitional requirements for a format that's called an "open" standard: Thou shalt not have single-vendor features or functions. MSECMAXML, therefore, is not an open file format -- even though it has XML in it. Their great new format is not portable, as we say in the software trade. Portability is what you need for modular architectures ("SOA") which will permit you, as never before, to own the budgeting decisions on ALL THE SOFTWARE IN YOUR HOUSE.

Once your organization opts into the Vista stack and overpays handsomely for this bloated version of MS Office 2007 with its wafer-thin format (NOT!), it's a terminal decision from which you will never emerge...Microsoft's FINAL SOLUTION.

Mind your air supply on the next upgrade.

Minnesota Joins the ODF Cat & Mouse Game

PlexNex welcomes Gary Edwards, a founding member of the OASIS OpenDocument TC and also of the OpenDocument Foundation, Inc., as a guest contributor.

Courtesy of our good friend and ODF freedom fighter Andy Updegrove, we learn that in the State of Minnesota a bill was recently introduced that would require all Executive branch agencies there to:

"use open standards in situations where the other requirements of a project do not make it technically impossible to do this." ("Bill Introduced in Minnesota to Require Use of 'Open Data Formats'")

Andy goes on to say,

“On its face, the amendment is vendor neutral. It does, however, include one provision that may have been directed at Microsoft, which has at times been criticized for adding proprietary extensions to otherwise standards-compliant product features. That provision is found in the definition of an "open standard," and requires that if a standard, "allows extensions, ensures that all extensions of the data format are themselves documented and have the other characteristics of an open data format..."

This begs the question: Is MSECMAXML a kind of SOAP for the Windows-integrated stack of proprietary interfaces, protocols and messaging methods?

Some quick comments about SOAP: The SOAP protocol is often described as an XML wrapper around a content-data payload that may or may not be binary. As such, SOAP, (Simple Object Access Protocol) is also a way for programs to communicate with other programs, using XML. SOAP uses XML to encapsulate the data that needs to be sent to the remote subroutine. And, of course, XML is used to return data from the subroutine and to return notification of any error condition that might have occurred ("SOAP" - XML Cover Pages).

XML can be used to transfer data from one program to another, but the degree of interoperability still depends on the dependencies of the information within the SOAP container. Ah Hah! By using an "Open" wrapper for platform-bound and application-dependent "content," Chairman Bill gets to have his cake and eat it too.

It's strange that Microsoft blooger and co-chair of the MSECMAXML committee, Brian Jones, made a big deal out of the effort to strip MS XP Office 2003 MSXML of it's proprietary dependencies - including the infamous binary key first identified by the European Union's Valoris Report on Open Document Formats (PDF). Brian claimed that all dependencies had been removed. But what Microsoft submitted to ECMA is something else: the "ECMA Spec" is 1,900 pages of dependencies; some going as far back as the busted and highly insecure Windows 3.0 WMF implementation for rendering thumbnails in PowerPoint and Windows Explorer.

Considering the Minnsota Bill, you've got to love the term, “restricted file format,” which occurs repeatedly in this document. According to the Bill, the use of restricted file formats has to be “justified” and reviewed on a timely basis. For sure, someone (in Minnesota) has been paying attention to the cat and mouse game playing out between Microsoft and governments seeking to move to bi-modal analog/digital-capable information infrastructures based on SOA principles:

• The EU makes the move to Open Standards, Open XML technologies, and ODF.

• Microsoft counters with open standards – open XML promises.

• Massachusetts grabs the baton, and runs one of the most impressive legs in this marathon rush to computational consumer sovereignty.

• Microsoft counters with a well funded but vicious and politically corrupt personal assault and intimidation campaign.

• The Australian government comes out with the National Archives of Australia , the open source XENA Project, and the comprehensive GovDex Report.

• Microsoft has yet to respond.

• The State of California Air Resources Board offers to all other government divisions their documented and proven experiences with the many advantages of open source – open standards-based systems. (This involves expert advice, technology assistance, open architectural blueprints, proven migration methodologies, and the shared resources to make the migration possible.)

• Microsoft has yet to respond.

• Denmark announces their “Open Standards” definitions as the basis for all RFP's and systems procurement requirements.

Clearly, the governments of the world are set on using Open Standards - Open XML requirements to build migration paths to a future of highly inter-operable and open information infrastructures. Microsoft's “collective” response has been to submit a soaped up XML wrapper of proprietary Windows-integrated stack interfaces, methods and protocols to ECMA for ratification as a standard. It's not open. It's not interchangeable. It's not inter-operable. Indeed, MSECMAXML breaks the most fundamental promise of XML. But hey, it's “XML”.

And now we have the State of Minnesota countering the below-the-belt MSECMAXML counter-punch to ODF, specifically calling Redmond out exactly where they tried to side-step the Open Standards – Open XML requirements box on which so many governments agree. One thing's clear: Microsoft is at war with their customer base, and, the customer base has no intention of accepting anything short of total surrender to their demands for meaningful and truthful open standards-based systems. Microsoft has the money, the means, the corporate-wide inclination to deceive and the ruthless take-no-prisoners determination to persist: control of the file format is the key to more than half of their $40 Billion in revenues. That the State of Minnesota would step up and join this brewing blood bath is something to behold.

The stakes in the game of maintaining the incredibly enriching monopoly that is Microsoft just got higher.

~ge~

Microsoft Embrace & Extend C++

Elizabeth Montalbano (PC World) covers further the ignominious  attempts of Microsoft to get dot Net extensions of the C++ language through Ecma and ISO standards organization:

C++/CLI is a set of C++ extensions, including some of the basic technologies for Microsoft's .Net framework, that allows developers to build .Net applications in C++ without having to use an intermediary step to access the framework, according to Herb Sutter, principal architect for C++/CLI at Microsoft and chair of the ISO C++ standard committee.

Although Microsoft supports several languages for .Net programming, Sutter said the company wanted C++ developers to have the option of full and direct access to .Net programming. Microsoft built .Net into the Windows OS starting with the first service pack for Windows XP, and the next version of the OS, Windows Vista, will be built on .Net.

Microsoft has worked with both ISO and Ecma since October 2003 to make C++/CLI a standard so the technology can be used with any standard C++ compiler. Sutter said he will suggest a way to resolve the disagreement, which could include renaming the technology, at an ISO meeting in Berlin scheduled for April.

Getting C++/CLI standardized is a peculiar gambit, on which I commented earlier this week: "The Name Game". C++/CLI as a standard would result in the indirect ratification of dot Net as a standard. That's not what standards are about.

Stakeholders, managment and board members at the Ecma and ISO organizations need to look out: playing the innocent vessel to Microsoft's habitual abuse of the standards process will harm these standards bodies' ability to function successfully as true open standards proliferate. It will be alternative organizations who get the business.

UPDATE: Feb. 8, 2006 --  David Berlind adds helpfully to coverage on "Between the Lines". 

The Name Game

Pamela Jones (Groklaw) and Matt Mondok (ArsTechnica) kindly point out a rich example of Microsoft having difficulty getting a standard accepted by the Ecma / ISO one-two (which is the same approach they are taking on their XML file format). This bodes well for OpenDocument if members of Ecma and ISO are functioning with open eye: it is the responsibility of standards bodies not to proliferate multiple standards for the same job.

If you thought Microsoft's naming trick in their Office "Open" XML submission to Ecma / ISO was insincere, then look at the trouble they are having getting C++/CLI (basically C++ bindings for dot Net) past the astute UK representatives on the standard technical committee at Ecma.

"The UK request that Ecma withdraw this document from fast-track voting and if they must re-submit it to JTC1, do so under a name which does not include 'C++'."

A note at the end of this request to deny is telling:

This paper should not in any way be taken as suggesting that there is a sinister plot by Microsoft or anyone else to usurp or subvert the C++ Standard. Microsoft is an active participant in and a strong contributor to WG21. We accept that the people involved in this project are sincere in what they are trying to accomplish and do have persuasive (to them) reasons why they think these are good ideas. However, we also think they misunderstand what is important to other people.

I would call Microsoft's repeated attempts to manipulate standards an insincerity of the Aspergers variety, or Modified Insincerity. It is not necessarily cunning but evinces a disregard for pain inflicted on others which is particular to a certain mental disorder associated with Geekishness, Aspergers being a kind of Autism-Lite.

It seems Microsoft is only believed in the United States. For honest answers to this queer anomaly, see Bernard-Henri Levy's amazing book, American Vertigo (reviewed here by none other than Garrison Keillor: "On the Road Avec M. Levy" for The New York Times).

WMF & the Ecma Spec

You won't have missed the widespread reports of the Windows Metafile (WMF) vulnerability that's been painfully exploited since about Christmas through Microsoft Office and Windows software.

Notably, the Microsoft patch set took more than a week to materialize. This is its own form of PR disaster (plump with irony) & pregnant with the ugly spawn of general security implications, i.e., nothing new from The Trustworthy Computing Company.

Now, I'd like to route your attention to a further wrinkle in the WMF vulnerability story which has escaped coverage so far and which gives me pause as someone intimately involved in the OpenDocument deployment in Massachusetts (which, despite rumours to contrary, is well on course).

The WMF, itself, is a proprietary implementation of a way to render graphics in Windows. In fact, it is an obsolete service that exists in modern versions of Windows merely to maintain backward compatibility with the way the early, 16-bit, versions of Windows (Windows 3.x, 95, 98, ME, NT) rendered certain graphics (think of JPEG thumbnails in the Windows Explorer file manager or running down the left-hand margin of PowerPoint). Therefore -- apart from serving backward-compatibility -- WMF is unnecessary to the latest versions of Windows and Office, within themselves.

WMF interacts with something else in Windows, another proprietary api called GDI, the Graphical Device Interface.

This means that WMF, a proprietary segment of code, references another proprietary set of code that is unique to that single OS platform, Windows. They are, separately and together, perfect examples of PROPRIETARY SOFTWARE DEPENDENCIES, which are anathema to open architectures, where everyone (Munich, The German Ministry of the Interior, Massachusetts, The Australian National Archive, The US Library of Congress, The British Library, to name just a few modest examples) is heading.

WMF runs executable scripts without user approval (another bad habit cultivated by Microsoft engineers who were pushed by marketing to throw out good sense for convenience). This is a natural part of the design of the WMF in its quotidian task of drawing  images on your screen; however, malicious scripts have been written and propagated lately which are intended to take your system down (or do anything in particular) by setting themselves up to be called when WMF executes a thumbnail image draw.

Now, what I find shocking, penetrating & newsworthy is that there is a reference to an implementation of the WMF in the "Ecma spec" for Office "Open" XML. The reference falls in Section 14.3 of the 1900-page Ecma format specification where it discusses how a single WMF is stored in a file along with their Presentation ML code specification. This is how a file draws its embedded thumbnail images.

This is significant to me for several reasons:

1) It means that the Microsoft file format for Office 12 -- the one that is headed for Ecma & ISO approval in approximately 18 months to 2 years time -- has a significant security flaw, WMF. This means that WMF or other serious security flaws introduced into Microsoft's file format specification would endanger other applications and operating systems that also implement this specifcation (while adhering to the requirement of a fully "CONFORMING" implementation).

It means that any other product that supports the eventual XML Reference Schema will be at risk of painting a hacking target on its users' backs, given how tightly Microsoft's Ecma submission is entwined within Office and Windows. In other words, if a hacker finds a back door that's required by the Ecma standard, you would be stepping into the thicket of brambles simply by complying, as required, with Microsoft's Ecma file format specification.

It means Microsoft's falsely labelled "open" standard, as it is being rubberstamped, would be insecure and compromise the safe platforms, too.

2) It means that Microsoft's Office "Open" XML has single-vendor proprietary services embedded within it (which overtly contradicts the most reasonable, accepted criteria for open software standards). If Office "Open" XML were developed in an open and collaborative environment, the WMF vulnerabilities would not exist...would not have even made it into the Ecma spec.

3) It means that, despite vows that Office "Open" XML is open from Microsoft officials all over Beacon Hill...

Microsoft's Alan Yates on December 14th in the Massachusetts Senate Reading Room:

"We've been very gratified by the positive reception to our recent announcement of moving the Office OpenXML formats into a standards organizations, ECMA International, to make them utterly, completely, perpetually open by any measurement of openness at that point."

...that the existence of such proprietary dependencies in this allegedly "open" file format would disqualify it from meeting the general criteria for openness. It plainly contradicts such knowingly false statements as this by Alan Yates.

Conclusion

In bucking the global trend to open standards, Microsoft has chosen the odd strategy to feint or bluff the market (odd unless interpreted as a stall), to dress their new XML format, together with many old proprietary hooks (WMF is just one example), in the mantle of openness through submission to well-known standards bodies. What the WMF implementation in the Ecma spec reveals is that Microsoft officials are boldly lying about the openness of its newly "openned" XML file format, the only open aspect of which is the name.

The real significance is that they are doing so in such an obvious way which, given the increasing sophistication of enterprise customers, will not produce fruit for them in the market-place.

I add that mature observers have voiced serious concerns for the reputations of the standards bodies, ECMA International and ISO, who will find their own credibility under pressure if they rubberstamp Microsoft's corrupt file format standards initiative with no rigorous laundry list to elide the proprietary dependencies and security vulnerabilities. The standards bodies will need to adapt to the surging demand for genuinely adherent open software standards or new bodies who respect all openness criteria will simply grow up around them.

European governments, as well as organizations in the private sector there, are extremely sensitive to the correct criteria for open software standards and have been watching file format developments closely since 2001 when the early implementations of OpenDocument first became deployable in the OpenOffice.org and StarOffice software. They will not be fooled, nor will the US State CIOs who have been digesting the Wagnerian drama in Massachusetts...every lightning-bolt, measure and coda.

"Deep-Format" Leaks the Poop

Deep-Format -- who by smell could only be a Microsoft insider -- is leaking about Microsoft's botch job on the Ecma spec. This kind of poop -- which includes chapter, section and page references coming, as it were, slipped under the bathroom stall -- could only be from a disgruntled employee on the Office or  XML dev team.

According to Deep, the Ecma spec was a rush job to stall the market until Vista comes out, presently scheduled for late 2006...but slipping. Not only are there numerous dead links in the document, but the flaws in the spec are fundamental: far from amounting to only a few Microsoft-only application and OS dependencies and binary key tricks, the spec is a wholesale thicket of proprietary platform-specific system calls, interfaces and protocols.

If Deep is on the level, MS XML is the Windows Vista file format wrapped in XML; and the intention is to pass it through Ecma & ISO to make it more palatable up against the on-rushing OpenDocument format, which is 18 months to 2 years ahead of MS XML in the standards approval process. 

Deep-Format feels that Microsoft is making an unnecessarily bold gamble of the franchise by floating such a compromised file format through Ecma & ISO. Deep fears this format could eventually lose in the more knowing market-place and in an environment late this year that promises to be cautious & skeptical about Vista. It's safe to conlcude that this is why he (or she) is leaking. More to come.

Alan Yates: Agent of Disinformation

Mr Yates made several stabs at convincing the Massachusetts Senate Reading Room audience on December 14th to give his company a chance on the file format. His remarks contained contradictions, disinformation and attempts to confuse the issues which deserve to be noted. Said Mr Yates:

"What I'm really going to be talking about is Massachusetts actually opening up to more choice and more competition than the current policy has. That's, I think that's the fundamental decision that's before us. Can Massachusetts open up to more choice, additional standards, in order to enable greater value over a period of time? And by doing that, by enabling more choice over a period of time, you avoid the industry warfare that tends to jerk governments around from one month to the next month, to one debate to the next debate to the next debate." [emphasis added]

Yates here is effectively saying that a second file format standard (Microsoft's) will bring "more choice" and "greater value." In a perverted sense it brings more choice -- in a literal sense, one can say it brings more choice between COMPETING STANDARDS -- but not in the appropriate, relevant beneficial sense of competition by MULTIPLE SOFTWARE IMPLEMENTATIONS around a single standard. I posit that this is a deliberate perversion of the argument, designed to confuse the public and elected representatives.

To argue for 'two standards' in any circumstance is beyond the pale and certainly beyond common sense. It does not warrant serious consideration by mature individuals. According to our colleague, Dan Geer, to suggest 'two standards' is the equivalent of a recommendation to drive on both the left and the right sides of the road. It is not merely non-sensical but brain-dead.

Now, in addition, there are quite a few economists and IT-standards experts nearby who can argue with ease the fatuousness of Mr Yates' statements on an economic basis.  Firstly, a software standard is a single thing; you can't have two. In fact, having 'two standards,' as Mr Yates pleads, is itself an oxymoron. If you have two, neither one is standard, is it? Secondly, there is support on the business and academic record that the situation of multiple would-be standards in competition creates economic harm (or physical as in the example above); that having a standard (a single standard) is the ideal for promoting competition, choice, efficiency and so on. (Thankfully this is the case right now with ODF, the only available or prospective "open" file format standard.) 

Mr Yates' choices of the phrases & images, "industry warfare" and "jerk governments around," are patronizing (inferring victimization, shifting blame) and reflect psychological Transference. It is Microsoft's industry behavior that is bellicose, violent and incompatible with competitive conditions (see US anti-trust actions and ongoing anti-competitive rulings in the European Union). It is Microsoft who is jerking customers around in instances too numerous to list as well as through the very fact of this speech, not to mention other reprehensible tactics they have promulgated in Massachusetts. These statements reflect a circularity that is common in the language used by officials of Microsoft.

Mr Yates returns to the old argument which failed to hold up to scrutiny in the Massachusetts Senate a short while back:

"...public policy shouldn't necessarily favor one business model over another."

This too is a deliberately false statement, designed to embed & reinforce the misprission of certain elected officials who had confused 'Open Source' with 'open standards' -- and a few other things as well. It is an attempt to keep the confusion alive. Anyone who has read ETRM 3.5 -- the ITD policy at issue -- knows that the policy describes only open sofware standards and appropriately makes no comment whatsoever about vendors, software platforms or business models.

Mr Yates' self-serving and false statements are growing tiresome. This modest analysis ought to give pause to IT customers as they consider Microsoft's fitness to supply mission-critical tools, particularly tools that officials of that company call "open" while they bear only superficial resemblence to authentic open software standards.

(Dan Bricklin | Software Garden kindly provide the podcast (MP3) of the December 14th Forum from which Mr Yates' remarks are taken and Pamela Jones | Groklaw the written transcript.)

Cruel to be Kind

Making virtue of vice, Microsoft is selling the idea of its "open" file format (the one that will be ready in about 2 years) -- let's call it "MS XML" --  on the backward compatibility it will have with the legacy proprietary Microsoft file formats. This is taking semantic license, in other words, a little lie with words. While backward compatibility is theoretically a desirable goal, Microsoft's approach is to sacrifice the openness of the new format.

To achieve backward compatibility, MS XML files are designed to enclose the legacy file in its binary form within more-or-less open standard XML. (This is noted in the Ecma spec.) It's clear now that users will need a Microsoft application to access the so-called "open-formatted" file, even though it is in an XML format, because of the proprietary elements contained within it. Openness is rendered a sham.

Here's Alan Yates saying it's open while being fully aware of the proprietary Gotchas lurking throughout the two-thousand-page Ecma specification.

"...we've been very gratified by the positive reception to our recent announcement of moving the Office OpenXML formats into a standards organizations, ECMA International, to make them utterly, completely, perpetually open by any measurement of openness at that point...Finally, after years and years and years of documents being small black boxes that, you know, you really couldn't open or you might corrupt the file, you might destroy the document, you might destroy the information in it, all of a sudden, XML technology has enabled us to be able to make documents and the information in documents transparent."

This statement is impossible to believe, knowing the contents of that specification document. The design's numerous special hooks to Microsoft-only services and to binary information only accessible with Microsoft's help render the file format (as it is described today) utterly unfit to be called "open."

This is just one example of how Microsoft intends to eventually re-capture the fealty of old customers: by spitting in their faces, insulting their intelligence and sneering at their milquetoast commitments to open architectures. The company's low regard for its customers is genuinely on parade, as will be publicly evident when analysis of the Ecma specification reaches open air.

Ecma Rubber-Stamps the MS XML Proposal

Industry sources indicated Thursday that Ecma International has voted to create the Technical Committee and move ahead with submission of Microsoft's "Open"XML to that standards body. The one dissenting vote -- the lone dissenting vote -- among members of the TC was IBM's. hp abstained, which is equivalent according to Ecma rules to a "no" vote.

There are standards and there are sub-standards: facts tell which kind Microsoft is putting together. The company's lunge at Ecma is proving what many suspected even before all the details were available, that Microsoft's Ecma submission equates to only superficial change in the status quo: that Microsoft's file format for Office 2003 (and for the next version, Office "12") remains effectively proprietary.

The Terms of Reference in the Ecma submission betray a sneering measure to cloak a proprietary technology in the false mantle of collaboration and openness. Microsoft is calling their file format "open" while it will lack several important requirements that would justify the tag.

The Terms of Reference answer several of the glaring questions begged by Microsoft's Thanksgiving-week public relations extravaganza, which amounted to a Pre-Announcement of this pretend opening of their file format. Here are some of the conclusions we can now make in question & answer format:

1.    Who controls MS XML after Ecma International takes on the specification?

Microsoft only (with moral support from a list of partners & customers with no public evidence of contributions to the design, some of whom have been contributing publicly to the OpenDocument specification, too).

The Ecma submission gets the technology-to-standards body relationship promiscuously BACKWARDS. The language in the Terms of Reference,   "a.    Produce a standard which is fully compatible with the Office Open XML Formats..." [italics added], indicates that the "standard" intends to be derived from existing technology.

Appropriate standards work -- like that of the OASIS OpenDocument TC, for example -- involves public people and organizations working together to come up with technology that satisfies the requirements of a document format that will be used by an infinite number of software developers and solve a long continuum or problems proposed by anybody, collaboratively.

In glaring contrast to the empty roster of contributors to the MS XML format, OpenDocument has had many important contributors to its creation & specification though OASIS:

Vendors Who Added to the Specification

• Adobe (Framemaker, Distiller)
• Arbortext (Arbortext Enterprise Publishing System)
• Corel (WordPerfect)
• IBM (Lotus 1-2-3, Workplace)
• KDE (KOffice)
• SpeedLegal / Exari.
• Sun Microsystems / OpenOffice.org (StarOffice/OpenOffice.org)

End-Users Who Added to the Specification

• Boeing (complex large documents)
• CSW Informatics
• Drake Certivo
• Intel
• National Archives of Australia
• New York State Office of the Attorney General
• Novell
• Society of Biblical Literature
• Sony
• Stellent

2.    Who (what vendors) are extending the MS XML file format to implement it in their own software?

Cypher.

Rest assured, however, that Microsoft will inform the world press as soon as a vendor comes on board to embrace their new "open" proprietary format in its software. I don't expect any to show up, because no organization or financial institution in recent years has been willing to finance a play that competes head-to-head with Microsoft in a landscape dictated by Microsoft.

MS XML exists in the current Office 2003 product, but this is not the format that will compete with OpenDocument. The format that will compete with OpenDocument is approximately one year from public release and over 24 months from reaching OpenDocument's current level of accomplishment with respect to OpenDocument's relationship -- ratification complete -- with its respective standards body.

Please mind also that the technology of OpenDocument has been used and tested for about 5 years, well more than twice as long and with approximately twice as many users globally as have ever touched MS XML.

Conversely, thanks to the confidence behind a sincerely open process, OpenDocument has a growing list of vendors deploying its open file format:

• Abiword 2.4
• Microsoft OneNote
• Aukyla Document Management System
• Beagle search tool 0.1.2
• DocMgr 0.53.3
• docvert
• eLawOffice.it 0.9.5.2
• eZ publish 3.6
• Google Desktop Search
• Gnumeric
• IBM Workplace
• Kat Desktop Search Environment
• Knomos 1.0
• KOffice 1.4.2
• NeoOffice 1.2
• ooo-word-filter (a plugin for Microsoft Word 2003 XML to open OpenOffice XML documents)
• OpenOffice.org 1.1.5 & 2.0
• OpenOpenOffice (a plug-in for Microsoft Office so it can read and write OpenOffice files)
• Scribus
• Sun StarOffice 8
• TeX4ht
• TextMaker 2005 beta
• Visioo Writer 0.6
• Writely

(For a current list, see  Wikipedia's entry for OpenDocument. The list grows weekly.)

This list is why Microsoft blinked in Massachusetts; the list is really a reflection that the market demands a sincerely open file format now, and it reflects why Microsoft is making all appearances that they have one too. Personally, I find it comically absurd, but you should feel free to assert your own opinion. (Please do, by the way, in my Comments section, below.)

3. Who (what customers) are adopting MS XML (the relevant one that would be available in Office "12")?

There are none. The specification for Office "12" is not published yet, the software is not available and there are no use cases.

Ostensibly the customers who endorsed the Ecma/ISO concept would be among the first customers to adopt Microsoft's new phoney "open" file format, however, we have already seen that examples such as The British Library, whose esteemed name was referenced in the early public relations work, will be adopting many formats -- most prominently ODF!

Conversely, the list of actual OpenDocument adherents is now quite large and growing (many pro-active organizations have not published that they are standardizing on OpenDocument-ready office suite software...here is a partial list off the top of my head):

• Adobe
• City of Bergen, Norway
• City of Mannheim, Germany
• City of Munich, Germany
• City of Vienna, Austria
• Earnie Ball Strings
• The Executive Branch of The Commonwealth of Massachusetts
• The Gendarmerie
• Google
• HLB International (a Melbourne accountancy)
• International Business Machines
• The Library of Congress
• The Reichtag
• Scalix
  
• Sun Microsystems
• Tadpole Computer
• Telstra
  
• Verizon

Wrapping Up

The initial list of participants on Ecma's new MS XML TC includes Microsoft friends, partners & competitors, some which have asserted a significant influence also on the strict requirements of openness embodied by OpenDocument. They include:

• Apple
• Barclays Capital
• BP
• British Library
• Essilor
• IBM
• Intel Corporation
• Microsoft Corporation
• NextPage Inc.
• Statoil ASA
• Toshiba

(Thank you, Pamela Jones | Groklaw)

The MS Office XML proposal rests measurably beneath the high-water mark set by OpenDocument at OASIS for an open standard. And there -- according to new information stated as well as implied in the Terms of Reference to the Ecma submission -- it will likely remain until the market asserts its view as to its preference for either an open or a proprietary file format.