Microsoft releases FAQ on Ecma submission

Microsoft releases FAQ on Ecma submission

Summary: Already being lampooned as FUD by OASIS general council Andrew Updegrove (OASIS is the the consortium that stewards the OpenDocument Format), Microsoft has posted a FAQ (Frequently Asked Questions) that it hopes will address any of the confusion around its convenant not to sue (developers who implement its file formats in their software) as well as questions that have arisen as result of the submission of its file formats to Ecma International.

TOPICS: Microsoft

Already being lampooned as FUD by OASIS general council Andrew Updegrove (OASIS is the the consortium that stewards the OpenDocument Format), Microsoft has posted a FAQ (Frequently Asked Questions) that it hopes will address any of the confusion around its convenant not to sue (developers who implement its file formats in their software) as well as questions that have arisen as result of the submission of its file formats to Ecma International.  Last week, Ecma formed a technical committee (TC45) to steward an XML-based standard that's based on the Microsoft submission.  The FAQ also comes in advance of another important hearing (was the only link I could find that shows the schedule but doesn't editorialize) that's being held this week in Massachusetts regarding that state's effort to standardize on the electronic file formats that it will use for the storage of public documents.  The FAQ addresses one of the major questions that has been raised since the covenant not to sue was published; whether or not it will apply to the formats that were submitted to Ecma in addition to the current (and somewhat obsolete) Office formats it addresses.  Says the FAQ:

The CNS [(covenant not to sue)] currently applies to the Office 2003 specifications because they are the only ones currently available that are complete. As the up-to-date specifications are released to Ecma, they will be posted on the same Web site and we will apply the CNS to them.

At first glance (I'm currently at the Syndicate Conference in San Francisco so I'm skimming), the FAQ doesn't appear to have answered some of the questions I think are worth answering in sufficient detail.  That, by the way, isn't smoking gun evidence that Microsoft is disingenuously ducking some of the more important questions. Until Microsoft officially answers them (or refuses to answer them), it just means that they still need answering.  In my replies to comments from ZDNet's readers who responded to my blog about Ecma's procedures, I noted that it's actually in Microsoft's best interests to overcommunicate on the issue and provide as much clarity as possible. I'm still trying to get more details from the Redmond, WA-based company. Stay tuned.

Topic: Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Regrettable word choice

    I hope that those who read this article will indeed link through to my blog post, which clearly in no way "lampoons" the Microsoft
    Q&A. Instead, it tries to evaluat the Q&A objectively, giving credit where credit is due, and offering a refutation of misstatements where warranted. A careful reading will lead inevitably to that conclusion.
    Andy Updegrove
    • Lampooner

      Hi Andy,

      I don't think you can honestly write about MSXML, the MSXML Reference License, the MSXML Covenant to Sue if you get it wrong, the ECMA rubber stamp process, or the get the FUD campaign without lampooning. You simply can't write honestly about something that is inherently deceptive and dishonest without coming off as somewhat sarcastic or ridiculing. Sadly the only choice you have is to ignore the FUD, or lampoon them.

      The MS FUD sets the tone of the discussion, and there's not much you can do to change that. How do you call someone out as having intentionally misrepresented the facts and misrepresented their ?opponents? position, without also calling them a flat out liar? Well, you try to be polite, reasonable, and ?factual?. Which means you end up ?lampooning? them whether you like it or not.

      I disagree with DB on one thing however. For me the MSXML ?cough, cough? FAQ , answers all my questions. MSXML is a scam to deceive the public, and lock future generations of information workers into a Microsoft stack of bolted, er ?integrated?, software systems where a cascading entanglement of dependencies and bound interfaces ties together a sprawl of devices, desktops and server side systems. The anti trust worst nightmare come true.

      The more we learn about MSXML, the worse it gets. Some of this stuff is pretty funny. The deliciously named ?anti trust? action broadcast forever into the public mind set that Microsoft has some serious ?trust? issues. So instead of taking steps to establish some measure of public trust and respect, what do they do? They set out on a massive campaign to deceive and trick the public.

      The MSXML ?cough, cough? FAQ intentionally misrepresents the relationship between OpenDocument,, Sun, and the OASIS ODF TC. They try to portray ODF as a single vendor, single application, damn near proprietary effort. Which is to say, they try to portray ODF to be in the exact same boat as MSXML. And nothing could be further from the truth.

      Why not just tell the truth about ODF and say that Microsoft is intent on providing with MSXML an even more open, free and universally available, unencumbered, and globally participation oriented version of an XML file format that solves all the problems they have with ODF, and further services mankind's digital information needs? Or better yet, why not adopt ODF and work to improve the file format? Sadly they can't say that because to do so would have disastrous consequences to Microsoft's business objectives. Aye, there lies the rub.

      If this argument comes down to who is the better Open Standards steward, OASIS or ECMA, then OASIS will win hands down.

      If this comes down to which standard is open and unencumbered, and guaranteed to stay that way, then ODF will win hands down.

      If this argument comes down to which standard is the best implementation of Open XML technologies, then ODF will win hands down, no contest.

      This brings us to the larger question of why XML? Which in turn leads us to the next question; is this about the desktop productivity environment, or, is it about a much larger issue, the Open Internet?

      First, let's be clear. Without XML, there is no Web 2.0. There is no ?Live Web?. There is no ?next generation of collaborative computing?. XML isn't going to provide us with a better PC based desktop productivity environment. It's going to provide us with a means of meshing the desktop productivity environment with the Open Internet. XML ready desktop information engines become first class Open Internet ready participants. That's the ?why? behind this urgent and rather dramatic rush to dump our traditions of binary formats and race to XML.

      As we move the focus of discussion from the traditions of software and platform bound binary desktop productivity file formats, to that of Open Internet ready XML, the differences between ODF and MSXML become decidedly stark and clear.

      ODF is a ?wrapper? of Open XML technologies, and specifically states so in the charter. MSXML on the other hand, is a wrapper of proprietary technologies. Even if the ECMA rubber stamp effort were to become open and unencumbered with multiple vendors and users participating in the standards process, there's still the problem of all the proprietary dependencies wrapped in MSXML. For instance, where ODF implements W3C XForms, MSXML uses a WinForms ? InfoPath derivative. Where ODF implements W3C SVG, MSXML is geared to the up and coming proprietary ?sparkle?. Where ODF uses standard HTML, MSXML embraces the bastardized MSHTML. The list goes on and on, with one point becoming increasingly clear. Microsoft continues to embrace and extend open standards with proprietary enhancements designed to break both compatibility and interoperability with everything outside the XP Stack.

      Microsoft insists that the world can live with two different desktop productivity XML file format standards. The problem is that this isn't about desktop productivity. It's about the Open Internet. And who among us wants to relive the nightmare of shamelessly self serving Microsoft inspired incompatibilities?

      If this argument were about the desktop, we wouldn't be discussing XML. We would be arguing about the fidelity of file format conversions and reverse engineering success. As in, how well does OOo export and import Word documents and vice versa? (OBTW, the MSXML Reference License is designed to put an end to all reverse engineering efforts anyway).

      The minute XML entered the argument, this became about the Open Internet. The XML question is best phrased in terms of which applications are Open Internet ready? Most would agree that what makes the Open Internet so useful is that vendors faithfully implement Open Internet standards. So it makes as much sense to have two different versions of an XML file format as it does to have two different and incompatible versions of HTML. Or two different and incompatible versions of XHTML. Or two different and incompatible versions of XForms, SVG, SMiL, CSS, Java, or MP3. Yet, that is exactly the Microsoft game plan.

      What did Microsoft do to kill Netscape? They came up with a browser that could read both standard, and proprietary - bastardized versions of HTML. Then they used their monopoly power to carve up the Open Internet, greatly diminishing both Netscape's usefulness, and that of the Open Internet. All in the name of protecting their monopoly cash flow.

      And Java? Gee, Microsoft, in direct and willful violation of their Java license, tried to trick developers into implementing a bastardized version of Java filled with proprietary extension's. Same modus operandi. When they got caught, Microsoft resorted to the next best thing ? developing an alternative to Java and leveraging their monopoly power to kill Sun.

      So here we go again. Nothings changed except that this time, the public is near totally unaware that the ODF and MSXML kerfuffle is also, just like the Netscape and Java wars, all about the Open Internet. With MSXML, and near $12 Billion dollars shelled out in lawsuit settlements, Microsoft will once again try to split the Open Internet, and leverage their monopoly power to push the XP Stack down every Open Internet user and developers throat.

      In this regard, perhaps the most important area of distinction between ODF and MSXML is that ODF faithfully embraces and implements Open XML technologies as fast, and sometimes faster, than the W3C can produce them. Is there any doubt that MSXML will never, ever be able to make the same claim?

      ODF is often referred to as a universal file format. Yes, it's a beautifully conforming wrapper of Open HTML, XHTML and XML technologies. And with the current effort to create a universal metadata model based on a XML:RDF bridge, ODF promises a means of artfully combining the exceptional data modeling and messaging capabilities of XML with the extraordinary relationship modeling of RDF. In the ODF quest to become a universal file format, the desktop productivity layer is just one of three core objectives.

      The ODF universal file format trifecta may have begun with the effort to capture desktop productivity in Open XML, but the Open Internet demands much more. Even if we were to concede (which we won't) that MSXML is the better desktop productivity file format, the other two aspects of the trifecta are a show stopper for them.

      The first eighteen months of ODF TC work had very little to do with desktop applications, and whole lot to do with how legacy information systems interface with ODF. Doug Alberg, Boeing's representative on the ODF TC, coined the term ?universal transformation layer? as a means of describing how ODF could be used to connect disparate legacy information systems to Open Internet ready enterprise publication and content management systems. As it turns out, the Alberg methodology was an early forerunner describing near exactly the basics of how XML makes the extraordinary advantages of SOA possible. I would further argue that you can't do a worthwhile SOA without a capable universal transformation layer that includes desktop productivity.

      ODF knocks this aspect of our Open Internet trifecta out of the park. And here, MSXML is a no show. Lacking both the technical ability and vital legalese to perfect transparent transformations, MSXML is worthless as an SOA component.

      The third leg of the trifecta is that of a worthy successor to the HTML-XHTML Open Internet lineage. ODF does two things here that are noteworthy. First, as mentioned above, as an XML wrapper, ODF faithfully implements Open XML technologies as fast as the W3C can pump them out. As a wrapper of proprietary and encumbered technologies, MSXML is intended to break the Open Internet and throw us back into the dark days of HTML style incompatibilities.

      The second important thing ODF does is to provide a universal bridge for unstructured legacy information to be transformed into highly structured, machine ready ? Open Internet ready XML. This is one of the extraordinary advantages that came out of the ?universal transformation layer? work. You can use ODF to effectively push information throughout an SOA. Or, you can use ODF as a universal storage layer easily transformed as needed. Or, you can have it all, SOA, long time ? application independent storage, and transformation of unstructured legacy information into Open Internet ready ?structured? information.

      And then there's the universal metadata work being done on ODF. With the XML:RDF bridge, ODF will likely deliver to Google, Microsoft on a silver plater. (The discussion we should be having instead of wasting air time playing whack-a-mole with MSXML.)

      My contention is that even if MSXML were somehow proven to be a worthy application independent desktop productivity file format, they still fail miserably at the other two legs of the Open Internet trifecta. And why do XML anyway if it's not about the Open Internet? Besides, Microsoft plays cute and tricky exactly where they most need to be out there trying to establish some trust and credibility. I don't care what they do with their desktop productivity software or XP Stackware. But when it comes to the Open Internet, Microsoft is playing with something that belongs to all of us, intent once again on mucking up one of the wonders of the world.

      One last point about the MSXML Covenant to Sue. What an offensive document this is to anyone not locked into the XP Stack, nor liking the fact that Microsoft is out to own the Open Internet. By using MSXML as a wrapper for proprietary and encumbered technologies, Microsoft totally breaks the promise of XML transformation and interoperability. Now, with this truly offensive covenant, they take the ?X? out of XML.

      The ?X? in XML of course stands for eXtensibility, as in ?eXtensible Markup Language?. The covenant effectively crosses out the eXtensibility option, and mandates that the only way you can implement MSXML and not get sued, is to do so ?eXactly? as specified. Heaven help you if you make a mistake. Or worse, fall into the trap of thinking this is Open XML, being both scalable and eXtensible. The advice Microsoft seems to be giving is that we all need brigades of well armed lawyers standing at the ready if ever we were to eXtend MSXML to meet specific implementation needs. Thanks for the warning. This isn't Open XML.

      Microsoft would no doubt argue that this covenant to sue anyone who dares eXtend MSXML is a good way to insure conforming and transparent interoperability. It's also a good way to insure that Microsoft is the only vendor able to make use of MSXML. For sure it means that you better get express permission with a legally binding agreement from Microsoft before you risk even breathing wrong on MSXML.

      Ask yourself this, ?Would the terms and conditions ECMA accepted for the governance of MSXML be acceptable to the W3C??

      I think not. For me, that says it all.

  • A key difference

    between the creation of the ODF standard and the ECMA effort is that while both efforts start with a pre-existing format, the format was merely the starting point for ODF whereas the Microsoft formats are pre-defined to be the end result. That's a *major* difference.

    The members of the ODF TC examined the OOo format and then *changed* it. Those changes were not at the sole discretion of SUN either. Many were proposed by others. The ODF standard was supposed serve everyone's interests, not just a single vendor. Everyone's input was welcome and encouraged. Many accepted changes were proposed the KDE prepresentative, David Faure. The KDE implementation of ODF is original and NOT based on code.

    The ECMA TC, however, is mandated from the start to "create" a standard that is 100% compatible with the pre-existing format of a single vendor, Microsoft. Microsoft points out in their FAQ that that their format is designed to support Microsoft customers. There doesn't appear to have been any consideration for anyone else's interests at all.

    The FAQ disparages the ODF TC for not taking Microsoft customers in account during the creation of ODF. Of course, they don't say that Microsoft itself could have easily have supported such interests since they actually had an observer on the comittee, but choose only to watch, not contribute.

    The notion that the ODF TC didn't consider user's of Microsoft products is false. Many of the TC members where Microsoft customers. I am sure that they looked after their own interests. No one on the committee was unaware of the market share that the existing Microsoft formats have. They also understood that many people would want to convert documents in Microsoft formats to ODF without loss of information.
    • Exactly!

      The original ODF TC that worked eighteen months on phase I, included some of the worlds most experienced and accomplished MS Office reverse engineering experts known. Corel and - StarOffice couldn't exist without this reverse engineering expertise able to reach back through decades of the Microsoft binary file format maze. But some of these experts, like Phil Boutros of Stellent, were simply amazing. Quite beyond ?knowledgeable?.

      The depths of his knowledge and understanding of the endless nuances and arbitrary differences in these many generations of MS Officeware file formats always left me wondering if Microsoft had any engineers currently working who could represent their interest as knowledgeably as Phil Boutros? I came to the conclusion that Microsoft had already decided that Phil Boutros would do a better job representing the legacy of MS binary file formats than anyone Microsoft could provide, so they sat on the side lines and let him carry the ball. And carry it he did! In a room full of reverse engineering experts, many of whom had dedicated their lives to studying MS binaries, Phil gave a virtuoso performance.

      It's also interesting to note that Microsoft held off on MSXML until the ODF TC completion of phase I. Makes you wonder who reversed engineered who?

  • Maybe I'm stupid

    It is stated on the MS fac:
    [i]The Microsoft OpenXML formats have had a number of unique design requirements, including the following:
    ? Backward compatibility with billions of documents produced over decades.
    ? Intrinsic support for integrating customer-defined XML data. This enables new levels of innovation as documents generate and transport information in unique XML styles not defined by Microsoft or the document standard, but defined by the business processes of an organization.
    ? High performance. The Microsoft OpenXML formats put a high priority on the speed of opening, closing, and working with documents, to roughly reflect or improve upon the performance of the past binary formats, rather than degrade the performance due to parsing XML.
    ? Robust Testing. The OpenXML formats for Microsoft Word and Excel have been part of Office 2003 and have undergone extensive real-world testing and usage, by customers and developers. [/i]

    How in heavens name can OfficeXML be compliant with previous versions of office? All of these are in a binary format. You can only put them into the new format with usage of office and then converting them or hoping that MS will provide a mass conversion tool. What i read between the lines actually is: if you want to use your old formats, you need to use software that can read the binaries. [b]This has nothing to do with the OpenXML format.[/b]

    The second statement doesn't mean a thing. Whether I use OfficeXML or ODF i can put in my own enhancements and extra XML. So this is not a differentiator between the two.

    The third statement is more or less dependant on the translation engine used. The fact that MS used shorter tags will hardly provide any improvement. That they will build an engine that probably will be proprietary however could provide an improvement in performance but i guess they're betting on binary xml :)

    The last statement i don't know about actually. I've never encountered anybody using the officeXML format of 2003 as it is slower than the binary format so why use it. I see this as deducted evidence (don't know English legal language enough ;) ). It's something like saying we have a million cows so we can produce more milk (actually this depends on the food provided and the amount of bulls you can find without bulls no milk ;) )

    As the other part in this remark about that ODF didn't take into account the "millions" of MS customers I have only one thing to remark. [b]I as a customer would expect from MS that they look after my requirements, especially as they are a member of OASIS and were invited to participate!!!![/b]

    But enough said about this, as they say here in the Netherlands. "Ze kunnen de pot op met hun office pakket".